Je suis sur le point de publier un projet comme source ouverte et j'aimerais vraiment des commentaires sur deux choses: P>
Le code est assez propre mais l'historique de contrôle de la version n'est pas. Erreurs, code de débogage, Code peut-être inapproprié, etc. Devrais-je éliminer l'histoire avant de publier ou l'importer de toute façon au référentiel public? P> LI>
devrais-je donner la priorité à faire un didacticiel, des explications de fonctionnalités ou une documentation API? p> li>
Autres pensées qui rendent un nouveau projet facile pour les gens d'entrer? p> li> ol>
3 Réponses :
Dans mon très humble avis: P>
1) Si vous êtes défini sur Open Source, soyez fier de votre code. Nous savons tous qu'il y a des erreurs et des bugs en cours de route. Il y aura aussi plus, alors ne vous sentez pas comme si vous ne pouvez pas afficher ceux-ci publiquement. Vous pouvez! P>
2) définitivement. Probablement dans cela, commandez également parce que c'est l'ordre que les personnes utilisant votre produit vont les lire. Ils devront utiliser votre logiciel avant de décider de travailler dessus. P>
3) Le meilleur conseil que je puisse donner est d'avoir des instructions de construction claires, espérons-le avec des scripts pour aider les personnes à configurer l'environnement. Une peste commune avec un logiciel open source nécessite de nouveaux développeurs de télécharger des tonnes de bibliothèques et de configurer leur boîte pour fonctionner juste à droite em> afin de pouvoir construire le logiciel. Cela, pour moi, est très frustrant et peut me mettre très vite. P>
bonne chance! p>
totalement votre choix, à moins que vous n'ayez utilisé de code protégé par le droit d'auteur pour lequel vous n'avez pas de droits de distribution ou s'il y a une question impliquant la redistribution, le crédit, quoi que ce soit. p> li>
difficile à dire sans savoir ce que c'est. Quels auriez-vous besoin pour l'utiliser? Que voudriez-vous voir en premier? (Probablement le tutoriel ...) p> li>
peut-être un exemple de start-to-finition, y compris l'installation. Peut-être devriez-vous aller au problème de l'exécution d'un environnement virtuel ou d'une nouvelle installation de système d'exploitation, vous êtes donc sûr que vos instructions d'installation traitent de tout. P> li> ol>
Je ne suis pas d'accord avec "la communauté écrira des tutoriels pour toi." Je pense que vous devriez au moins écrire un didacticiel destiné aux développeurs, ce qui signifie sauter sur beaucoup de choses très courantes - des choses telles que "nous utilisons le système de construction GNU (./configure && make && faire installer)" au lieu de devoir expliquer le GNU Construire le système à une personne qui peut être inconnu avec elle. Je pense qu'il est important de disposer d'un didacticiel de base prêt à aider les développeurs à plonger, plutôt que de simplement écrire un code bien documenté et propre et à la laisser à quelqu'un d'autre pour écrire les documents.
Oh, je faisais appelé des tutoriels d'utilisation. Pour les développeurs, la construction des instructions est définitivement nécessaire.
Une question très pertinente pour moi, je suis content que vous ayez demandé.