Les différentes fondations sont pas ouvertes à tous. Par exemple, apache a un processus spécifique avant d'être accepté, qui requiert d'avoir des commiteurs de sociétés différentes, qui impose de suivre une gouvernance et un processus à part, etc.
Ça impose aussi la license parfois, ou le sujet. Et je pense que la fondation décide ou va l'argent, pas toi.
Sur la traduction via des fichiers .po, tu oublies des points. D'une part, installer un éditeur n'est pas extrêmement compliqué, c'est pas le truc le plus bloquant. Les éditeurs sont globalement pas si mauvais à mon gout, et je pense que le plus gros souci, c'est de trouver le fichier ( ie, utiliser un vcs ) et le workflow. Et surtout de l'utiliser sur le soft existant ( ie, compile depuis git, ou déploiement en cas d'application web ).
Ensuite, il faut pas "juste aller sur un site et voila", il y a aussi tout un travail de prise en compte du vocabulaire, suivre un glossaire pour la consistance ( proxy vs mandataire ), décider pour les raccourcis claviers, comprendre les soucis de pluriels et de substitutions de chaines. Et il faut quelqu'un pour relire ( an kas de fotes ), valider. IE, bien que ça soit ouvert à tous pour commencer, il faut des compétences pour faire une traduction de qualités. Deja, prendre conscience que la traduction, c'est pas simple permet de se rappeler que ç'est une compétence comme une autre qui s'acquiert, et dire "c'est simple sur transifex", c'est un peu nier l'existence des compétences et pas vraiment sympa pour les traducteurs.
Quand à écrire de la documentation, c'est pareil. C'est pas simple d'écrire de façon claire. Tu as des problématiques amusantes comme avoir un truc visible mais ou tu perds les informations sémantiques ( genre marqué un titre "titre" vs "mettre un titre en gras et en police X ) ou avoir un truc structuré qui permet pas de variation dans le style.
Je suis plus en accord avec la problématique des rapports de bugs, c'est un excellent exemple. Oui, bugzilla est pas idéal ( on va retirer les soucis sur le fait qu'un autre BTS serait mieux et se concentrer sur les cas ou un autre mode complet d'interaction est mieux ). Mais on l'utilise car on a une préférence pour les codeurs. Ce que les gens veulent, c'est pas rapporter des bugs, c'est communiquer avec le projet pour donner du feedback. Ensuite, que le feedback débouche sur des bugs, c'est autre chose. Et tout ça, c'est un domaine que les boites connaissent, le "service aux consommateurs". Sauf que c'est pas du tout comme ça qu'on le conçoit dans le libre. Tu mets des listes des discussions d'utilisateurs ( par oppositions aux devs, ce qui grave quand même bien la distinction dans l'esprit des gens ), des forums, etc. Mais y a pas de rôles désignés pour s'occuper de ça. Tu as tout au plus des modérateurs de forums, qui sont là pour bloquer les débordements, et qui ont le mauvais goût d'attirer les gens avides de pouvoir et parfois d'attiser les conflits ( cf la charte de freenode ).
En fait, ça me rappelle cet article ( http://www.laurenbacon.com/women-tech-empathy-work/ ), Les comportements de certains gens dans le libre et certaines startups ont parfois des points en communs, en partie parce que les premiers débouchent sur les seconds.
Mais oui, faudrait sans doute des nouveaux outils. mais pas que. Il faut aussi revoir l'approche et la perception de la contribution dans le libre en général.
[^] # Re: Super mais seulement 1M ?
Posté par Misc (site web personnel) . En réponse au journal Freebsd reçoit une peu de thunes.. Évalué à 8. Dernière modification le 18 novembre 2014 à 23:30.
Les différentes fondations sont pas ouvertes à tous. Par exemple, apache a un processus spécifique avant d'être accepté, qui requiert d'avoir des commiteurs de sociétés différentes, qui impose de suivre une gouvernance et un processus à part, etc.
Ça impose aussi la license parfois, ou le sujet. Et je pense que la fondation décide ou va l'argent, pas toi.
Sur la traduction via des fichiers .po, tu oublies des points. D'une part, installer un éditeur n'est pas extrêmement compliqué, c'est pas le truc le plus bloquant. Les éditeurs sont globalement pas si mauvais à mon gout, et je pense que le plus gros souci, c'est de trouver le fichier ( ie, utiliser un vcs ) et le workflow. Et surtout de l'utiliser sur le soft existant ( ie, compile depuis git, ou déploiement en cas d'application web ).
Ensuite, il faut pas "juste aller sur un site et voila", il y a aussi tout un travail de prise en compte du vocabulaire, suivre un glossaire pour la consistance ( proxy vs mandataire ), décider pour les raccourcis claviers, comprendre les soucis de pluriels et de substitutions de chaines. Et il faut quelqu'un pour relire ( an kas de fotes ), valider. IE, bien que ça soit ouvert à tous pour commencer, il faut des compétences pour faire une traduction de qualités. Deja, prendre conscience que la traduction, c'est pas simple permet de se rappeler que ç'est une compétence comme une autre qui s'acquiert, et dire "c'est simple sur transifex", c'est un peu nier l'existence des compétences et pas vraiment sympa pour les traducteurs.
Quand à écrire de la documentation, c'est pareil. C'est pas simple d'écrire de façon claire. Tu as des problématiques amusantes comme avoir un truc visible mais ou tu perds les informations sémantiques ( genre marqué un titre "titre" vs "mettre un titre en gras et en police X ) ou avoir un truc structuré qui permet pas de variation dans le style.
Je suis plus en accord avec la problématique des rapports de bugs, c'est un excellent exemple. Oui, bugzilla est pas idéal ( on va retirer les soucis sur le fait qu'un autre BTS serait mieux et se concentrer sur les cas ou un autre mode complet d'interaction est mieux ). Mais on l'utilise car on a une préférence pour les codeurs. Ce que les gens veulent, c'est pas rapporter des bugs, c'est communiquer avec le projet pour donner du feedback. Ensuite, que le feedback débouche sur des bugs, c'est autre chose. Et tout ça, c'est un domaine que les boites connaissent, le "service aux consommateurs". Sauf que c'est pas du tout comme ça qu'on le conçoit dans le libre. Tu mets des listes des discussions d'utilisateurs ( par oppositions aux devs, ce qui grave quand même bien la distinction dans l'esprit des gens ), des forums, etc. Mais y a pas de rôles désignés pour s'occuper de ça. Tu as tout au plus des modérateurs de forums, qui sont là pour bloquer les débordements, et qui ont le mauvais goût d'attirer les gens avides de pouvoir et parfois d'attiser les conflits ( cf la charte de freenode ).
En fait, ça me rappelle cet article ( http://www.laurenbacon.com/women-tech-empathy-work/ ), Les comportements de certains gens dans le libre et certaines startups ont parfois des points en communs, en partie parce que les premiers débouchent sur les seconds.
Mais oui, faudrait sans doute des nouveaux outils. mais pas que. Il faut aussi revoir l'approche et la perception de la contribution dans le libre en général.