Le bot « lien permanent » de GitHub a silencieusement ruiné le sens de mon post

Contribuer Fonctionnalité
1

Il y a environ un an, j’avais publié un message sur l’instance Discourse de GitHub contenant plusieurs URLs de la forme « https://github.com/OWNER/REPO/tree/BRANCH/path » afin de discuter de la façon dont GitHub.com traite ces URLs. Mon message a rapidement reçu une modification générée automatiquement par le système avec le message « Le lien GitHub a été remplacé par un lien permanent », ce qui semble provenir du plugin discourse-github. Bien que le remplacement du nom de branche par un lien permanent vers l’ID du commit actuel puisse être une fonctionnalité utile dans le cas courant où un message cite un code spécifique, dans le cas particulier d’une discussion sur le traitement des URLs GitHub, cette modification a détruit le sens de mon message. J’ai eu la chance de remarquer immédiatement l’édition du bot et, après plusieurs échanges avec lui, j’ai fini par trouver une solution de contournement consistant à ajouter une balise pour empêcher le motif du bot de correspondre, comme ceci :

https://github.com/OWNER/REPO/tree/<span>BRANCH</span>/PATH

Mais d’autres auteurs pourraient ne pas remarquer l’édition du bot et se retrouver avec un message qui confondrait les lecteurs.

Quelle est la meilleure solution pour éviter les modifications indésirées de liens permanents GitHub sur un message particulier ? En général, je pense qu’il est erroné que des bots effectuent des modifications automatiques risquant de ruiner un message. Il serait plus sûr de (1) demander à l’auteur, lors de l’enregistrement du message, si les liens doivent être modifiés, ou (2) que le bot ajoute un lien permanent sans supprimer le lien original. (Je me souviens avoir vu certains bots sur d’autres sites web, peut-être Reddit, qui ajoutent des informations sans supprimer les informations existantes.) Si les mainteneurs de Discourse jugent ces options trop peu élégantes ou trop coûteuses à mettre en œuvre pour un cas d’usage rare, d’autres options pourraient être de (3) afficher un avertissement après l’enregistrement du message, avec un lien vers des informations expliquant comment l’auteur peut éviter ces modifications si nécessaire, soit (a) sous forme d’une bannière dédiée dans l’interface utilisateur, soit (b) simplement une ligne de texte ajoutée par le bot à la fin du message.

Je ne suis pas certain de savoir quelle serait la conception la plus raisonnable pour permettre à l’auteur de se désengager de ces modifications. Les paramètres d’exclusion à l’échelle du site du plugin discourse-github, basés sur la cible du lien, ne semblent pas bien adaptés à cet usage. Peut-être que ma solution de contournement actuelle avec la balise est suffisante. Même si aucune modification n’est apportée à Discourse, j’espère que ce message rendra la solution de contournement plus facile à découvrir pour les auteurs qui remarquent le problème.

Note : J’avais précédemment soulevé ce problème sur le forum de GitHub car je supposais que le bot « lien permanent » était spécifique à l’instance de GitHub, mais un commentateur m’a signalé qu’il s’agit d’une fonctionnalité générale de Discourse, c’est pourquoi je soulève le problème ici.

Merci pour votre attention !

2 « J'aime »
2

Je pense que c’est une bonne fonctionnalité, car les gens collent souvent des liens vers master, qui deviennent presque toujours obsolètes avec le temps. Cependant, il devrait toujours être possible de coller intentionnellement un lien vers une branche, car il existe de nombreuses raisons valables pour le faire. De plus, cette fonctionnalité semble généralement un peu défaillante : elle réécrit des éléments qu’elle ne devrait pas et ne parvient pas à analyser ceux qu’elle devrait probablement traiter.

Voici quelques exemples qui pourraient servir de cas de test pour la corriger :

  1. Lien brut obtenu simplement en collant une URL. Je m’attendrais à ce qu’il soit réécrit, ce qui est le cas : subdomain-static/forums-enhancements.js at master · ClassicPress/subdomain-static · GitHub
  2. Lien Markdown de la forme [url](url). Je m’attendrais à ce que ce lien ne soit pas réécrit, car j’ai explicitement spécifié à la fois le texte et l’URL. Or, c’est le texte du lien qui est réécrit, tandis que l’URL du lien ne l’est pas. C’est incorrect : https://github.com/ClassicPress/subdomain-static/blob/master/forums-enhancements.js
  3. URL entourée de accents graves. Il ne s’agit pas d’un lien et elle ne devrait pas être réécrite, mais elle l’est : https://github.com/ClassicPress/subdomain-static/blob/master/forums-enhancements.js
  4. URL dans un bloc de code délimité par trois accents graves. Il ne s’agit pas d’un lien et elle ne devrait pas être réécrite, mais elle l’est :
    https://github.com/ClassicPress/subdomain-static/blob/master/forums-enhancements.js

Je pense que seul le cas (1) ci-dessus devrait être réécrit. Cela rendrait le comportement plus prévisible et ne modifierait que les liens « bruts ». Les liens pour lesquels une structure Markdown spécifique a été utilisée (ce qui peut être considéré comme une manière d’exprimer une intention précise) devraient être laissés tels quels.

1 « J'aime »
3

Cette fonctionnalité semble n’être pas activée sur meta.discourse.org ?

4

Quoi qu’il en soit, je ne suis pas d’accord : je pense que dans (2) edit : le cas général de [texte](URL) (appelons-le (2a)), l’URL du lien devrait être réécrite de la même manière que (1). (Je suis d’accord que le comportement actuel consistant à réécrire le texte et non l’URL est complètement erroné.) Je prends la décision entre écrire (1) et (2a) en fonction de si je pense qu’il est utile ou distrayant que l’URL soit visible par le lecteur, et non en fonction d’une intention quant à savoir si le lien doit pointer vers la version du code telle qu’écrite ou telle qu’elle sera lue. Bien sûr, je suis conscient du problème des liens permanents, donc j’en crée moi-même un chaque fois que j’en ai besoin. Mais plus généralement, si un administrateur Discourse décide d’activer le bot de liens permanents, c’est probablement parce qu’il pense que la plupart de ses utilisateurs ne sont pas conscients du risque que les liens basés sur le nom de branche puissent se dégrader, et je ne pense pas que l’utilisation de la syntaxe de lien Markdown soit un signal suffisant qu’un utilisateur donné est conscient du problème mais souhaite se désengager de la réécriture de ce lien particulier.

Mais je pense que nous spéculons tous les deux ici. En tant qu’utilisateur avancé, je me soucie peu de la valeur par défaut tant que je peux la remplacer au besoin.

5

Oui, exactement. Actuellement, il n’y a aucun moyen de le remplacer. Écrire [url](url) (le texte du lien et l’URL sont exactement les mêmes) serait certainement un moyen de signaler au bot que ce lien ne doit pas être réécrit, car il n’y a aucune autre raison de l’écrire de cette façon.

6

Il y en a une si vous voulez donner à votre lien son propre titre plutôt que de le laisser être déduit de l’URL cible, c’est-à-dire [titre](url). Donner un titre au lien n’indiquerait aucune préférence pour la réécriture d’URL, donc je suis d’accord avec @mattmccutchen sur le fait que 1 et 2 devraient se comporter de manière cohérente pour la réécriture d’URL.

On pourrait soutenir que le titre correspondant exactement à l’URL est une indication qu’elle ne devrait pas être réécrite, mais que faire si un utilisateur veut fournir un titre et veut que l’URL ne soit pas réécrite ? Il doit y avoir une autre méthode pour spécifier cela.

Quelque chose qui vient à l’esprit serait un suffixe de titre similaire à la taille des images intégrées, bien que je ne sois pas sûr de la façon dont un utilisateur le découvrirait.

Une image intégrée peut être redimensionnée comme ceci :
![titre|100x200](url)

Ainsi, le plugin discourse-github pourrait (vraisemblablement) être fait pour rechercher quelque chose comme ceci :
[titre|github-no-rewrite](url)

7

Ah, il n’était pas clair pour moi que votre (2) faisait référence uniquement au cas spécial où le texte et l’URL sont identiques. Ma déclaration concernait le cas général où le texte et l’URL peuvent être différents ; appelons cela (2a) maintenant.

Dans le cas (2), je suis d’accord qu’il est étrange de réécrire l’URL et non le texte, les laissant incohérents, mais il me semble qu’on pourrait tout aussi bien soutenir que si nous voulons éviter l’incohérence, le meilleur moyen d’y parvenir est de réécrire à la fois l’URL et le texte plutôt que ni l’un ni l’autre. Je ne trouve donc pas l’argument de traiter (2) comme un refus convaincant. Étant donné que nous devrions avoir un refus qui fonctionne pour (2a), je serais enclin à laisser les utilisateurs utiliser le même refus pour (2) et à ne pas compliquer la conception. (Je pense que c’était peut-être aussi l’idée de Simon Manning ?)

8

Je ne suis pas sûr de suivre correctement (ou si c’est possible), mais pourriez-vous utiliser l’échappement d’espace comme dans le lien Inline PDF Previews - #45 by Johani ? Ainsi, [ texte]( url) ne réécrirait ni le texte ni l’url, et tout le reste serait automatiquement modifié ?

9

Cette version devrait rester telle quelle et ne pas être réécrite, laissez-moi voir :

https://github.com/correctcomputation/checkedc-clang/blob/master-post-microsoft/clang/docs/checkedc/Setup-and-Build.md

écrit comme :

<https://github.com/correctcomputation/checkedc-clang/blob/master-post-microsoft/clang/docs/checkedc/Setup-and-Build.md>
10

Pas un test valide car la réécriture des permaliens GitHub est entièrement désactivée sur cette instance Discourse. (Je me demande ce que cela dit de cette fonctionnalité si elle est désactivée sur l’instance « officielle » :upside_down_face:)

Si vous deviez écrire cet exemple comme cas de test pour replace_github_non_permalinks.rb / replace_github_non_permalinks_spec.rb à la place, alors je pense que vous trouveriez que ce lien serait également réécrit.

1 « J'aime »