Pourquoi ne pas activer le bugtracker ? Tu pourrais suivre tes propres idées d'amélioration, et avoir d'autres bugs avec un tag spécifique pour les contributions faciles. En son absence, un étudiant peut se dire "tiens, je vais envoyer ça, on verra si ça rentre". Si tu as des listes de contributions possibles, ou acceptes des demandes d'évolution, cela donne une ligne directrice, leur évitant de s'éparpiller. Certes, tu peux te retrouver à fermer des bugs plutôt que des pull requests (voire en plus des pull requests), c'est un risque. Tu peux aussi laisser juste un bug ouvert avec un titre explicite pour dire que le logiciel est complet et n'a pas besoin d'évoluer et n'a pas de bugs (ce qui est à mon avis faux et sonne un peu pédant, mais a le mérite d'être clair).
Le bugtracker c'est le premier réflexe je pense quand tu t'intéresses à l'amélioration d'un logiciel. Il t'aidera à envoyer bouler ce qui sont venus pour la gloire et trouver l'aiguille dans la meule de foin : la personne qui aura un vrai besoin, ou une vraie idée. Tu me diras que tu as déjà ça via les PR, et tu as peut être raison, mais à ta place, je tenterais l'expérience pour voir si cela améliore les choses. Je ne pense pas que les PR ont pour vocation de servir de point d'entrée.
Au pire, ajoute un CONTRIBUTING.md, ou une section de contribution au README.md, mais je ne pense pas que les étudiants en question le liront, j'ai un peu plus d'espoir du côté du bugtracker... Un peu plus de chances avec une table des matières (genre générée avec md-toc) pour voir en un clin d'œil qu'il y a une section de contribution sans avoir à faire défiler tout le fichier.
# Prendre le contre pied
Posté par liberforce (site web personnel, Mastodon) . En réponse au journal Doctoshotgun pris d'assaut par le variant étudiant. Évalué à 0.
Pourquoi ne pas activer le bugtracker ? Tu pourrais suivre tes propres idées d'amélioration, et avoir d'autres bugs avec un tag spécifique pour les contributions faciles. En son absence, un étudiant peut se dire "tiens, je vais envoyer ça, on verra si ça rentre". Si tu as des listes de contributions possibles, ou acceptes des demandes d'évolution, cela donne une ligne directrice, leur évitant de s'éparpiller. Certes, tu peux te retrouver à fermer des bugs plutôt que des pull requests (voire en plus des pull requests), c'est un risque. Tu peux aussi laisser juste un bug ouvert avec un titre explicite pour dire que le logiciel est complet et n'a pas besoin d'évoluer et n'a pas de bugs (ce qui est à mon avis faux et sonne un peu pédant, mais a le mérite d'être clair).
Le bugtracker c'est le premier réflexe je pense quand tu t'intéresses à l'amélioration d'un logiciel. Il t'aidera à envoyer bouler ce qui sont venus pour la gloire et trouver l'aiguille dans la meule de foin : la personne qui aura un vrai besoin, ou une vraie idée. Tu me diras que tu as déjà ça via les PR, et tu as peut être raison, mais à ta place, je tenterais l'expérience pour voir si cela améliore les choses. Je ne pense pas que les PR ont pour vocation de servir de point d'entrée.
Au pire, ajoute un CONTRIBUTING.md, ou une section de contribution au README.md, mais je ne pense pas que les étudiants en question le liront, j'ai un peu plus d'espoir du côté du bugtracker... Un peu plus de chances avec une table des matières (genre générée avec
md-toc) pour voir en un clin d'œil qu'il y a une section de contribution sans avoir à faire défiler tout le fichier.