1 points par sjh9714 49 분 전 | Aucun commentaire pour le moment. | Partager sur WhatsApp

GitHub a lancé le 17 juin une fonctionnalité qui limite le nombre de PR ouvertes simultanément pour les utilisateurs sans droits d’écriture. Elle est arrivée après de nombreuses plaintes de mainteneurs épuisés par le flot de PR de mauvaise qualité générées par l’IA, et c’était aussi une demande formulée depuis 2016.

J’ai donc mesuré ce que cela filtre réellement dans des files de dépôts réelles. En excluant les bots et en ne comptant que les PR ouvertes par des auteurs sans droits d’écriture, j’ai calculé combien auraient été retardées avec une limite fixée à 3.

  • huggingface/transformers — 55 PR ouvertes / 49 auteurs / 1 PR aurait été retardée avec une limite à 3
  • typescript-eslint — 28 / 24 / 1
  • DIYgod/RSSHub — 26 / 23 / 1
  • django/django — 79 / 59 / 7
  • caddyserver/caddy — 58 / 43 / 7
  • coollabsio/coolify — 86 / 68 / 11

Cela représente 2 à 13 %.

La raison tient à la forme de la file. Pour transformers, les 55 PR ouvertes viennent de 49 auteurs. Pour coolify, 86 PR viennent de 68 personnes. Ce n’est pas un schéma de spam où une seule personne en ouvre trente, mais plutôt trente personnes qui en ouvrent une chacune. La limite a été conçue pour le premier cas, alors que les files réelles ressemblent au second.

Cela ne veut pas dire que la fonctionnalité est inutile. Il existe bien des dépôts où un seul compte inonde la file, et auparavant il n’y avait aucun moyen de s’en défendre. En revanche, le volume qui atteint les relecteurs reste presque inchangé, et il faut toujours décider quoi lire en priorité.

Autre mesure faite en parallèle. J’ai examiné 167 dépôts ayant installé une action qui ferme automatiquement les PR de mauvaise qualité : dans les 30 dépôts où la file était encore active, pull_request_creation_policy était all partout. C’est la valeur par défaut, donc cela veut simplement dire que personne ne l’a changée, mais aussi que le groupe ayant la motivation la plus forte pour limiter les PR n’a pas fermé la porte — il a seulement ajouté un filtre.

Et parmi ces 167 dépôts, 126 (75 %) avaient moins de 4 PR ouvertes. Autrement dit, il ne faut pas lire « N dépôts ont installé un filtre anti-slop » comme « N dépôts subissent une inondation ». Moi aussi, je l’avais d’abord compris ainsi, puis je l’ai corrigé après avoir mesuré.

La méthode de mesure et ses limites figurent dans le document lié. La limite à 3 est une hypothèse de ma part (chaque dépôt la configure différemment), et comme il s’agit d’un instantané de file ouverte, les PR qui n’ont jamais pu être ouvertes à cause de la limite n’apparaissent pas — ce qui est d’ailleurs l’un des points clés de la fonctionnalité. Toute personne disposant d’une liste publique de PR peut reproduire la mesure.

(Divulgation : cette mesure provient du checker de triage de PR que j’ai créé. Il y a donc un conflit d’intérêts à garder en tête, mais les chiffres sont directement reproductibles à partir des listes publiques de PR de chaque dépôt.)

Aucun commentaire pour le moment.

Aucun commentaire pour le moment.