Organisation de la zone développement

[sly]

Le mot clé que j'utilise pour une proposition pour laquelle on est d'accord et qui n'attends que quelqu'un pour coder est "mc proposition"

Bien sûr, chacun peut utiliser celui qu'il veut, mais vu celui que tu as utilisé, je l'aurais perdu à coup sûr d'ici 6 mois

[Dominique]

ps: le mot clé que j'utilise pour une proposition pour laquelle on est d'accord et qui n'attends que quelqu'un pour coder est "mc proposition"

Va pour "mc proposition" mais il faudra probablement me le rappeler la prochaine fois
C'est un peu compliqué, mais quid d'un forum "dev en cours" par opposition à "dev soldé" et on déplace le fil quand c'est soldé ?
Comme ça, quand on n'a rien à faire, on peut piocher dedans.

A moins de déplacer ces fils dans un trac sur github, mais je ne sais pas comment ça marche et on n'aurait pas la même audience.

[sly]

-- 2 forums --
Ça doit aussi marcher avec 2 sous-forums. La question étant juste quelle solution est la plus simple, sachant qu'un forum n'est de toute façon pas ce qu'il y a de mieux pour du suivi de bug.
Initialement, j'avais inventé cette histoire de mots clé pour retrouver des thèmes important, je me suis donc dit, faisons pareil avec les bugs et les suggestions en pensant qu'on pourrait avoir comme "catégorie" :
bugs en cours
propositions en cours
bugs invalides
bugs en double
bugs résolus
propositions réalisées
propositions abandonnées

et donc mieux avec des mots clés que 1 par forum pour chaque !
Mais dans les faits, je ne m'en sers que de 3 : les bugs et les propositions en cours, et le reste, donc la justification initiale ne tient plus. Alors comparons :

Avantages de 2 forums par rapport aux mots clés :
- séparation plus claire et évidente, c'est soit à faire (forum "todo") soit fait (forum terminé+flag [fait]), soit abandonné (forum terminé + flag [raison])
- Accès au "todo" en 1 clic, alors que par mots clé il faut rechercher par mot clé, qu'il faut connaître (mc bug mc proposition)
- le mécanisme étant plus simple, tout le monde comprend vite où il doit déclarer son "bug" contrairement aux mots clés

Inconvénients de 2 forums par rapport aux mots clés :
- Seuls les modérateurs peuvent clore ou ré-ouvrir un bug (là ou celui qui l'ouvre initialement peut changer le mot clé dans le titre)
- si on fini par avoir disons 50 propositions et 2 bugs, ça devient plus difficile de débusquer les 2 bugs

J'en vois pas d'autre... 3 avantages à 2 en faveurs des 2 sous-forums, y'a qu'a plus qu'a ! Au pire, il sera facile de revenir en arrière ;-)

-- issues github --
L'option des "issues" sur github est évidement plus adapté car fait pour et je l'utilise un peu et léo l'utilise beaucoup :
https://github.com/sletuffe/www.refuges.info/issues
Mais de fait, on la garde plutôt pour les trucs incompréhensibles pour le simple utilisateur qui sont du domaine de l'organisation interne du code et qui ne ferait que gêner à être ici.
Et inversement, demander aux utilisateurs de wri d'aller créer un compte sur github, se battre avec des notions bien compliquées en anglais de Milestone, enhancement, tags, flags, labels, pull request et autres termes barbares ne me semble pas la meilleure méthode pour encourager la participation et donc, comme tu dis : "changer d'audience"

De plus, je me méfie (je suis parano ?) de github, autant le code et l'historique git est en copie chez nous donc no problème, on change quand on veut de crémerie, autant les issues/bugs ne sont pas exportables et si demain github nous demande du fric, coule, vire l'historique ou que sais-je, on perd ça.

Quoi qu'il en soit, sur github, tu es le bien venu si tu as le courage pour les questions "code interne"