Je peux voir un problème avec l'approche mentionnée ici: les fonctionnalités les plus demandées ne sont pas nécessairement bénéfiques pour le projet en lui même.

Ce qui peut sembler bon à la majorité des gens / utilisateurs ne l'est pas nécessairement pour le projet en lui même ! On peut souhaiter privilégier un code lisible / compréhensible / simple, ou tout simplement vouloir accomplir une certaine "vision", dans laquelle certaines fonctionnalités n'auraient pas leur place.

Si l'auteur du logiciel ne souhaite pas la mort de son projet, une des manières qui s'est révélée efficace (en tout cas jusqu'à présent) est de créer une organisation et de donner peu à peu du pouvoir aux personnes les plus impliquées, bien sur sur la base de la confiance. Il s'agit ni plus ni moins que d'une méritocratie.

Bien sur, cela n’empêche pas l'auteur de vouloir regarder les "pull requests" et les commits, mais celui-ci n'est plus nécessaire à la vie du projet.

Ceci-dit, j'aime beaucoup l'approche de vote (si on lui enlève la partie "merge automatique") puisqu'elle permet de prendre la température sur les fonctionnalités souhaitées par la communauté. En pratique cela se passe déjà (même si la forme est différente): les intéressés commentent sur les bugs / pull requests au lieu de voter, ce qui à d'ailleurs l'incidence de provoquer des conversations plus pertinentes que des "+1, -1".