Posté par BAud (site web personnel) .
En réponse à la dépêche cloonix-15.
Évalué à 3.
Dernière modification le 01 août 2012 à 00:43.
je veux juste des utilisateurs qui donneraient des idées de spécifications
Sans moyen de contact facile, idéalement public - ce pourquoi je propose au mini une ML publique - ça ne va pas être facile :/ (cf. plus bas).
Merci de l'effort de lecture de ma doc et de rédaction des conseils
Ta doc' m'a interpellé car bien rédigée et présentée, en anglais il est vrai, au contraire de ta dépêche dans sa forme initiale.
En tant que modérateurs, nous avons aussi réécrit ta prose initiale :) La prochaine fois pour ta dépêche, tu peux passer par http://linuxfr.org/redaction pour de la rédaction collaborative (et mobiliser d'autres personnes qui seraient intéressées pour t'aider). Pour te donner un retour d'expérience : sur eagle-usb quand je suis arrivé nous avions des développeurs très motivés pour développer (et rapidement en plus) mais pas de mainteneur du site web, ni de packageur, ni vraiment de support à l'install' / mise en œuvre et correction des dysfonctionnements mais une mailing-list qui fonctionnait bien pour avoir de l'aide (entre développeurs principalement) ; j'ai essayé à l'époque de développer les points manquants et de respecter le release early, release often en ajoutant le package often, en respectant la distinction discussions développeurs / utilisateurs, et ça a bien fonctionné àmha (surtout le forum utilisateur où j'étais très présent et réussissais même à faire venir les développeurs sur des sujets particuliers).
Vu que tu abordes des sujets très spécifiques, une ML est amplement suffisante pour ceux qui veulent simplement suivre ce qui se passe et des retours éventuels sur des cas d'utilisation auxquels ils n'auraient pas pensé. Cela vous permettra d'avoir des relais ponctuellement sur des sujets spécifiques au besoin àmha. Pas forcément besoin de sortir l'armada forum + bugtracker si vous ne souhaitez pas vous en occuper (et comme indiqué l'administration du gestionnaire de version peut être déléguée tant que vous n'avez pas des volumétries trop grosses et vous contentez de vos scripts d'intégration, sans forker systématiquement l'upstream).
[^] # Re: changelog
Posté par BAud (site web personnel) . En réponse à la dépêche cloonix-15. Évalué à 3. Dernière modification le 01 août 2012 à 00:43.
Sans moyen de contact facile, idéalement public - ce pourquoi je propose au mini une ML publique - ça ne va pas être facile :/ (cf. plus bas).
Ta doc' m'a interpellé car bien rédigée et présentée, en anglais il est vrai, au contraire de ta dépêche dans sa forme initiale.
En tant que modérateurs, nous avons aussi réécrit ta prose initiale :) La prochaine fois pour ta dépêche, tu peux passer par http://linuxfr.org/redaction pour de la rédaction collaborative (et mobiliser d'autres personnes qui seraient intéressées pour t'aider). Pour te donner un retour d'expérience : sur eagle-usb quand je suis arrivé nous avions des développeurs très motivés pour développer (et rapidement en plus) mais pas de mainteneur du site web, ni de packageur, ni vraiment de support à l'install' / mise en œuvre et correction des dysfonctionnements mais une mailing-list qui fonctionnait bien pour avoir de l'aide (entre développeurs principalement) ; j'ai essayé à l'époque de développer les points manquants et de respecter le release early, release often en ajoutant le package often, en respectant la distinction discussions développeurs / utilisateurs, et ça a bien fonctionné àmha (surtout le forum utilisateur où j'étais très présent et réussissais même à faire venir les développeurs sur des sujets particuliers).
Vu que tu abordes des sujets très spécifiques, une ML est amplement suffisante pour ceux qui veulent simplement suivre ce qui se passe et des retours éventuels sur des cas d'utilisation auxquels ils n'auraient pas pensé. Cela vous permettra d'avoir des relais ponctuellement sur des sujets spécifiques au besoin àmha. Pas forcément besoin de sortir l'armada forum + bugtracker si vous ne souhaitez pas vous en occuper (et comme indiqué l'administration du gestionnaire de version peut être déléguée tant que vous n'avez pas des volumétries trop grosses et vous contentez de vos scripts d'intégration, sans forker systématiquement l'upstream).