le journal aurait proposé une contribution (temps, argent, etc.),
J'ai vraiment du mal avec cette reponse.
Ca donne l'impression qu'il suffit qu'"on" donne de l'argent (combien?) a "quelqu'un" et ca va devenir merveilleux d'un coup.
Desole, mais non. C'est pas un probleme de ressource d'ingienerie, c'est un probleme de produit.
La super feature que tu vas financer s'integre dans un produit et un design. Le produit, c'est un tout coherent, pas un frankenstein de feature demandees au hasard par n'importe qui. C'est aussi l'art de prendre des decisions pas facile, de refuser de resoudre un probleme juge non pertinent, et ce genre de choses. Ecrire le code, c'est certes pas trivial, mais ca sert pas a grand chose si ya pas une vision tres claire de ce qu'est cense faire le produit.
Tant que le desktop linux sera gere a l'arrache sans aucune vision, en rajoutant des bouts a droite a gauche au ptit bonheur la chance, ca restera la meme merde.
Product manager, c'est pas un boulot facile. Faut avoir de bonnes idees, les valider, savoir ne garder que les meilleurs, apprendre a ecouter les utilisateurs (dont la premiere regle est de ne surtout pas faire ce qu'ils demandent, mais comprendre pourquoi ils le demandent, determiner le probleme et ensuite seulement resoudre ledit probleme).
Typiquement, la demande de creer un evenement depuis le jour de la barre de menu/dock. C'est probablement tres utile pour cette personne, je n'en doute pas une seconde. Mais c'est pas forcement utile pour un grand nombre de personne (en gros ceux qui recoivent des invitations, plutot que ceux qui les envoient), et ajoute de la complexite qui potentiellement ne sert pas a grand chose. Ca prend du temps qui n'est pas passe a resoudre un autre probleme potentiellement plus important (genre la resolution des conflits quand on prepare un meeting, par exemple).
Bref, il faut quelqu'un familier avec les usages courants d'un calendrier, identifier les groupes d'utilisateurs les plus importants, peser le pour et le contre etc. Et c'est pas quelque chose qu'on trouve generalement chez les developeurs du libre. Ni meme les developeurs tout court, qui tendent a etre des uber geeks obsedes par des power features dont 90% des gens se foutent (serieux, faites du hallway testing, ou lancez des tests sur usertesting.com, c'est impressionant le gouffre entre la sphere high tech et le reste du monde).
Quand aux contributions, qu'elles soient financieres ou en temps, faut pouvoir les gerer. Les donations, c'est une plaie d'un point de vue fiscal, et ca pose aussi le probleme que si t'acceptes la thune pour faire qqchose, tu peux pas l'utiliser pour autre chose (genre le don pour feature a sexy mais pas utile ne peut pas etre utilise pour feature b moins visible mais beaucoup plus importante).
[^] # Re: éternel problème de la contribution
Posté par groumly . En réponse au journal Ce que Linux aurait du devenir ces 15 dernières années.... Évalué à 8.
J'ai vraiment du mal avec cette reponse.
Ca donne l'impression qu'il suffit qu'"on" donne de l'argent (combien?) a "quelqu'un" et ca va devenir merveilleux d'un coup.
Desole, mais non. C'est pas un probleme de ressource d'ingienerie, c'est un probleme de produit.
La super feature que tu vas financer s'integre dans un produit et un design. Le produit, c'est un tout coherent, pas un frankenstein de feature demandees au hasard par n'importe qui. C'est aussi l'art de prendre des decisions pas facile, de refuser de resoudre un probleme juge non pertinent, et ce genre de choses. Ecrire le code, c'est certes pas trivial, mais ca sert pas a grand chose si ya pas une vision tres claire de ce qu'est cense faire le produit.
Tant que le desktop linux sera gere a l'arrache sans aucune vision, en rajoutant des bouts a droite a gauche au ptit bonheur la chance, ca restera la meme merde.
Product manager, c'est pas un boulot facile. Faut avoir de bonnes idees, les valider, savoir ne garder que les meilleurs, apprendre a ecouter les utilisateurs (dont la premiere regle est de ne surtout pas faire ce qu'ils demandent, mais comprendre pourquoi ils le demandent, determiner le probleme et ensuite seulement resoudre ledit probleme).
Typiquement, la demande de creer un evenement depuis le jour de la barre de menu/dock. C'est probablement tres utile pour cette personne, je n'en doute pas une seconde. Mais c'est pas forcement utile pour un grand nombre de personne (en gros ceux qui recoivent des invitations, plutot que ceux qui les envoient), et ajoute de la complexite qui potentiellement ne sert pas a grand chose. Ca prend du temps qui n'est pas passe a resoudre un autre probleme potentiellement plus important (genre la resolution des conflits quand on prepare un meeting, par exemple).
Bref, il faut quelqu'un familier avec les usages courants d'un calendrier, identifier les groupes d'utilisateurs les plus importants, peser le pour et le contre etc. Et c'est pas quelque chose qu'on trouve generalement chez les developeurs du libre. Ni meme les developeurs tout court, qui tendent a etre des uber geeks obsedes par des power features dont 90% des gens se foutent (serieux, faites du hallway testing, ou lancez des tests sur usertesting.com, c'est impressionant le gouffre entre la sphere high tech et le reste du monde).
Quand aux contributions, qu'elles soient financieres ou en temps, faut pouvoir les gerer. Les donations, c'est une plaie d'un point de vue fiscal, et ca pose aussi le probleme que si t'acceptes la thune pour faire qqchose, tu peux pas l'utiliser pour autre chose (genre le don pour feature a sexy mais pas utile ne peut pas etre utilise pour feature b moins visible mais beaucoup plus importante).