J'ai la même approche que toi sur mes projets libres.
Quand je recois une demande de fonctionnalité sans rien d'autre derrière.
Si c'est facile à faire et justifié, je le fais et puis basta.
Si c'est moins facile, je le mets dans ma todo-list et je le ferai quand j'aurai le temps/l'envie.
Si je veux pas le faire, je dis non et j'explique pourquoi.
J'implique le demandeur pour m'assurer que la nouvelle version répond bien à sa demande.
Quand je recois un patch/une pull request, je regarde ce que ca apporte, et comment c'est codé.
Si ca ne sert à rien, je dis non merci et je dis pourquoi.
Si c'est un patch du genre if (mon_exception_rien_qu_a_moi) { faire_un_truc_hyper_spécifique(); }, je dis non merci également et j'essaie de trouver une solution pour résoudre le problème initial tout en évitant de modifier mon code de cette manière.
Si c'est pas propre ou doit être amélioré, je demande des corrections.
Enfin, si c'est fusionnable et correspond à mes critères de qualité, je m'assure de bien comprendre tout le nouveau code parce que je pars justement du principe que le contributeur va disparaître après, donc je veux maîtriser la contribution.
Je n'ai aucun état d'âme à refuser et fermer une pull request quand je ne la veux pas ou que je n'arrive pas à m'entendre avec la personne qui propose. J'argumente toujours avant et après ma décision, mais je ne souhaite pas faire de compromis là dessus, car au final, c'est moi qui maintient et fait évoluer le projet dans son ensemble.
Cela dit, mes projets sont suffisamment petits pour que je puisse les maintenir tout seul, donc je me permets de faire comme ca.
[^] # Re: Oui : contactez-moi d'abord
Posté par Babelouest (site web personnel) . En réponse au journal Forker ou ne pas forker ?. Évalué à 6.
J'ai la même approche que toi sur mes projets libres.
Quand je recois une demande de fonctionnalité sans rien d'autre derrière.
Si c'est facile à faire et justifié, je le fais et puis basta.
Si c'est moins facile, je le mets dans ma todo-list et je le ferai quand j'aurai le temps/l'envie.
Si je veux pas le faire, je dis non et j'explique pourquoi.
J'implique le demandeur pour m'assurer que la nouvelle version répond bien à sa demande.
Quand je recois un patch/une pull request, je regarde ce que ca apporte, et comment c'est codé.
Si ca ne sert à rien, je dis non merci et je dis pourquoi.
Si c'est un patch du genre
if (mon_exception_rien_qu_a_moi) { faire_un_truc_hyper_spécifique(); }, je dis non merci également et j'essaie de trouver une solution pour résoudre le problème initial tout en évitant de modifier mon code de cette manière.Si c'est pas propre ou doit être amélioré, je demande des corrections.
Enfin, si c'est fusionnable et correspond à mes critères de qualité, je m'assure de bien comprendre tout le nouveau code parce que je pars justement du principe que le contributeur va disparaître après, donc je veux maîtriser la contribution.
Je n'ai aucun état d'âme à refuser et fermer une pull request quand je ne la veux pas ou que je n'arrive pas à m'entendre avec la personne qui propose. J'argumente toujours avant et après ma décision, mais je ne souhaite pas faire de compromis là dessus, car au final, c'est moi qui maintient et fait évoluer le projet dans son ensemble.
Cela dit, mes projets sont suffisamment petits pour que je puisse les maintenir tout seul, donc je me permets de faire comme ca.