Un ancien lien de dépôt GitHub peut cesser de rediriger vers le propriétaire d'origine

Ce que la redirection protège réellement

Lorsqu'un compte est renommé, GitHub assure une continuité pour certains types de liens et pas pour d'autres, et les règles diffèrent selon le type de lien. Les liens de profil sont les plus fragiles : l'adresse du profil précédent cesse de fonctionner au lieu de rediriger. Les liens de dépôt et de gist ont un comportement de continuité différent. Le point pratique est qu'un seul ancien lien ne constitue pas une preuve durable de qui possède un projet aujourd'hui, car le résultat dépend du type de lien que vous avez enregistré et de ce qui est arrivé à l'ancien nom ensuite. [GitHub Docs : changements de nom d'utilisateur]

• Notez de quel type de lien il s'agit : profil, dépôt ou gist.
• Considérez un lien de profil comme la forme de continuité la moins fiable.

La collision entre ancien espace de noms et nom identique

La défaillance spécifique est une collision entre un espace de noms libéré et un nom de dépôt réutilisé. Un changement de nom d'utilisateur libère l'ancien nom. Les liens de dépôt redirigent normalement, mais un nouveau propriétaire de ce nom d'utilisateur libéré peut créer un dépôt portant le même nom que l'ancien, et ce nouveau dépôt écrase la redirection. Deux projets sans rapport peuvent donc partager une adresse d'apparence identique, l'un ancien et l'autre nouveau. Rien dans l'adresse elle-même ne vous indique quel projet vous consultez, il faut donc vérifier la destination plutôt que de la supposer. [GitHub Docs : changements de nom d'utilisateur]

Pourquoi l'attribution à un contact de rencontre est risquée

Un projet qui apparaît à une adresse familière n'établit pas que la personne qui vous écrit l'a écrit, le possède ou y est même liée. La même limite s'applique à un affichage d'interface obsolète : GitHub Mobile peut continuer à afficher un ancien nom d'utilisateur jusqu'à ce que le compte se déconnecte, donc un nom visible n'est pas une preuve de l'identité actuelle. Traitez tout artefact technique unique comme un signal étroit. Il ne confirme ni une biographie de rencontre, ni une intention, ni un caractère, et il ne doit pas servir à accuser ou confronter qui que ce soit. [GitHub Docs : changements de nom d'utilisateur]

Vérifier une destination actuelle partagée volontairement

La voie la plus sûre est une destination actuelle que le propriétaire du projet choisit de partager, plutôt qu'un ancien lien enregistré. Demandez l'emplacement canonique du projet et comparez-le avec la description publique, les notes de version ou l'historique du README du projet, de manière calme et sans accusation. Si le contrôle documenté ou l'artefact public n'est pas disponible, notez qu'il est indisponible et arrêtez-vous à la limite d'accès. Utilisez la documentation d'aide officielle actuelle, ou demandez simplement un lien actuel volontaire, au lieu de deviner vers quoi une adresse pointe désormais.

Gardez le signal à sa juste proportion

Séparez ce que vous avez observé de ce qu'il peut étayer et de ce que vous décidez de faire. Observation : un lien se résout vers une page de projet. Limite : la page peut ne pas être le projet d'origine, et sa présence ne dit rien de fiable sur un correspondant. Décision : considérez le projet comme non vérifié aux fins d'attribution et évaluez la relation sur la conversation elle-même. Si l'inquiétude persiste, ralentissez et fiez-vous à des informations volontaires et actuelles plutôt qu'à des artefacts publics qui n'ont jamais été destinés à répondre à des questions sur l'honnêteté d'une personne.

• Écrivez une phrase pour chacun : ce que vous avez vu, ce que cela ne peut pas prouver et ce que vous ferez ensuite.
• Préférez les questions sur la relation aux enquêtes sur du code public.

Encore quelques questions