Tu mentionnes cette sombre connerie de Spamtoberfest dans ton journal, sache que suite à la grogne de nombreux projets, github a implémenté les Temporary interaction limits. Ces réglages permettent de bloquer les contributions (issues, PR, commentaires) d'utilisateurs n'ayant pas déjà contribué au repo (ou n'étant pas membre du repo). Tu pourras l'activer si cela arrive à nouveau au prochain semestre.
Comme PostgreSQL, la plupart des projets sont limités par le temps de reviewer / mainteneur, pas le temps de développeur, donc le sujet des contributeurs inexpérimentés est difficile : leurs contributions peuvent faire perdre plus de temps qu'elles n'en font gagner, sur des sujets pas forcément prioritaires pour le projet.
Pour canaliser les nouveaux contributeurs, les projets KDE publient une liste de junior jobs. Si un nouveau contributeur se manifeste sur un de ces jobs, il peut s'attendre à avoir de l'aide (design, review et merge), car un contributeur existant a déjà manifesté son intérêt pour le sujet. En tant que nouveau contributeur, c'est un tag similaire que je chercherai dans le bug tracker, pour m'acclimater avec la base de code avant de proposer de "gros" changements. C'est aussi ce que j'ai vu dans plusieurs société (des tâches libellées "ramp-up" qu'on donne aux nouveaux employés). Le Summer of Code est un autre bon exemple pour structurer les interactions entre étudiants et projets.
# Le temps de mainteneur est la ressource la plus limitée de la plupart des projets
Posté par Xavier Vello . En réponse au journal Doctoshotgun pris d'assaut par le variant étudiant. Évalué à 10.
Tu mentionnes cette sombre connerie de Spamtoberfest dans ton journal, sache que suite à la grogne de nombreux projets, github a implémenté les Temporary interaction limits. Ces réglages permettent de bloquer les contributions (issues, PR, commentaires) d'utilisateurs n'ayant pas déjà contribué au repo (ou n'étant pas membre du repo). Tu pourras l'activer si cela arrive à nouveau au prochain semestre.
Comme PostgreSQL, la plupart des projets sont limités par le temps de reviewer / mainteneur, pas le temps de développeur, donc le sujet des contributeurs inexpérimentés est difficile : leurs contributions peuvent faire perdre plus de temps qu'elles n'en font gagner, sur des sujets pas forcément prioritaires pour le projet.
Pour canaliser les nouveaux contributeurs, les projets KDE publient une liste de junior jobs. Si un nouveau contributeur se manifeste sur un de ces jobs, il peut s'attendre à avoir de l'aide (design, review et merge), car un contributeur existant a déjà manifesté son intérêt pour le sujet. En tant que nouveau contributeur, c'est un tag similaire que je chercherai dans le bug tracker, pour m'acclimater avec la base de code avant de proposer de "gros" changements. C'est aussi ce que j'ai vu dans plusieurs société (des tâches libellées "ramp-up" qu'on donne aux nouveaux employés). Le Summer of Code est un autre bon exemple pour structurer les interactions entre étudiants et projets.