GitHub "permanenter Link"-Bot hat die Bedeutung meines Posts stillschweigend ruiniert

Beitragen Merkmal
1

Vor etwa einem Jahr habe ich einen Beitrag auf der Discourse-Instanz von GitHub veröffentlicht, der eine Reihe von URLs der Form „https://github.com/OWNER/REPO/tree/BRANCH/path" enthielt, um zu diskutieren, wie GitHub.com solche URLs verarbeitet. Mein Beitrag erhielt prompt eine systemgenerierte Bearbeitung mit der Meldung „Github link was replaced by a permanent link", die offenbar vom discourse-github-Plugin stammt. Während das Ersetzen des Branch-Namens durch einen Permanentlink zur aktuellen Commit-ID im allgemeinen Fall eines Beitrags, der auf bestimmten Code verweist, eine nützliche Funktion sein mag, hat diese Bearbeitung in dem speziellen Fall einer Diskussion über die URL-Verarbeitung bei GitHub die Bedeutung meines Beitrags zerstört. Ich hatte das Glück, die Bot-Bearbeitung sofort zu bemerken, und nach mehreren Runden des „Kampfes" mit dem Bot fand ich schließlich einen Workaround, indem ich ein <span>-Tag hinzufügte, um zu verhindern, dass das Muster des Bots matcht, wie hier:

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

Andere Autoren könnten die Bot-Bearbeitung jedoch möglicherweise nicht bemerken und würden mit einem Beitrag zurückgelassen, der Leser verwirren würde.

Was ist die beste Lösung, um unerwünschte Bearbeitungen von GitHub-Permanentlinks in einem bestimmten Beitrag zu vermeiden? Im Allgemeinen finde ich es falsch, dass Bots automatische Bearbeitungen vornehmen, die den Beitrag ruinieren könnten. Sicherer wäre es, (1) den Autor beim Speichern eines Beitrags zu fragen, ob die Links bearbeitet werden sollen, oder (2) den Bot einen Permanentlink hinzufügen zu lassen, ohne den ursprünglichen Link zu entfernen. (Ich erinnere mich vage daran, Bots auf anderen Websites, vielleicht Reddit, gesehen zu haben, die Informationen hinzufügen, ohne die bestehenden Informationen zu löschen.) Falls die Discourse-Maintainer diese Optionen als zu unansehnlich oder zu aufwendig erachten, um einen seltenen Anwendungsfall zu berücksichtigen, könnten andere Optionen sein: (3) nach dem Speichern des Beitrags eine Benachrichtigung mit einem Link zu Informationen anzuzeigen, wie der Autor die Bearbeitungen bei Bedarf vermeiden kann – entweder als (a) ein dedizierter Banner in der Benutzeroberfläche oder (b) einfach eine Textzeile, die vom Bot am Ende des Beitrags hinzugefügt wird.

Ich bin mir nicht sicher, welches Design am sinnvollsten wäre, damit sich Autoren gegen die Bearbeitungen entscheiden können. Die plattformweiten Ausschlusseinstellungen des discourse-github-Plugins, die auf dem Linkziel basieren, scheinen für diesen Zweck nicht gut geeignet. Vielleicht ist mein aktueller Workaround mit dem <span>-Tag ausreichend. Selbst wenn keine Änderung an Discourse vorgenommen wird, hoffe ich, dass dieser Beitrag den Workaround für Autoren, die das Problem bemerken, leichter auffindbar macht.

Hinweis: Ich habe dieses Problem zuvor im Forum von GitHub angesprochen, da ich annahm, der „Permanent Link"-Bot sei spezifisch für die GitHub-Instanz. Ein Kommentator dort wies mich jedoch darauf hin, dass es sich um eine allgemeine Discourse-Funktion handelt, weshalb ich das Problem hier anspreche.

Vielen Dank für Ihre Aufmerksamkeit!

2 „Gefällt mir“
2

Ich halte dies für eine gute Funktion, da Nutzer häufig Links zum master-Branch einfügen, die mit der Zeit fast immer veralten. Dennoch sollte es möglich sein, absichtlich einen Link zu einem Branch einzufügen, da es dafür viele valide Gründe gibt. Insgesamt scheint diese Funktion jedoch etwas fehlerhaft zu sein: Sie ändert Dinge, die sie nicht ändern sollte, und erkennt Dinge nicht, die sie wahrscheinlich erkennen müsste.

Hier sind einige Beispiele, die als Testfälle zur Behebung dienen könnten:

  1. Einfacher Link durch direktes Einfügen einer URL. Ich erwarte, dass dieser umgeschrieben wird, und das ist er auch: subdomain-static/forums-enhancements.js at master · ClassicPress/subdomain-static · GitHub
  2. Markdown-Link im Format [url](url). Ich erwarte, dass dieser Link nicht umgeschrieben wird, da ich sowohl den Text als auch die URL explizit angegeben habe. Stattdessen wird der Link-Text umgeschrieben, während die Link-URL unverändert bleibt. Das ist fehlerhaft: https://github.com/ClassicPress/subdomain-static/blob/master/forums-enhancements.js
  3. URL in Rückwärts-Backticks. Dies ist kein Link und sollte nicht umgeschrieben werden, wird es aber dennoch: https://github.com/ClassicPress/subdomain-static/blob/master/forums-enhancements.js
  4. URL in einem Code-Block mit drei Backticks. Dies ist kein Link und sollte nicht umgeschrieben werden, wird es aber dennoch:
    https://github.com/ClassicPress/subdomain-static/blob/master/forums-enhancements.js

Ich bin der Meinung, dass nur Fall (1) umgeschrieben werden sollte. Dies würde das Verhalten vorhersehbarer machen und ausschließlich „einfache" Links umschreiben. Bei Links, bei denen eine spezifische Markdown-Struktur verwendet wurde (was als Ausdruck einer bestimmten Absicht betrachtet werden kann), sollte nichts verändert werden.

1 „Gefällt mir“
3

Diese Funktion scheint auf meta.discourse.org nicht aktiviert zu sein?

4

FWIW, ich stimme nicht zu: Ich denke, im allgemeinen Fall von [text](URL) (nennen wir es (2a)), sollte die Link-URL genauso umgeschrieben werden wie (1). (Ich stimme zu, dass das aktuelle Verhalten, den Text und nicht die URL umzuschreiben, völlig fehlerhaft ist.) Ich entscheide zwischen dem Schreiben von (1) und (2a) danach, ob ich es für nützlich oder ablenkend halte, dass die URL für den Leser sichtbar ist, nicht basierend auf einer Absicht, ob der Link auf die Version des Codes zum Zeitpunkt des Schreibens oder zum Zeitpunkt des Lesens zeigen soll. Natürlich bin ich mir des Permanent-Link-Problems bewusst, daher erstelle ich selbst einen Permanent-Link, wann immer ich einen möchte. Aber allgemeiner gesagt, wenn ein Discourse-Administrator beschließt, den Permanent-Link-Bot zu aktivieren, dann wahrscheinlich, weil er denkt, dass die meisten seiner Benutzer sich des Risikos nicht bewusst sind, dass Branch-Name-basierte Links verrotten können, und ich glaube nicht, dass die Verwendung der Markdown-Link-Syntax ein großes Signal dafür ist, dass ein bestimmter Benutzer sich des Problems bewusst ist, aber von dieser speziellen Link-Umschreibung absehen möchte.

Aber ich denke, wir spekulieren hier beide nur. Als fortgeschrittener Benutzer ist mir die Standardeinstellung egal, solange ich sie bei Bedarf überschreiben kann.

5

Ja, genau. Derzeit gibt es keine Möglichkeit, dies zu überschreiben. Das Schreiben von [url](url) (Linktext und URL sind exakt gleich) wäre definitiv eine Möglichkeit, dem Bot zu signalisieren, dass dieser Link nicht neu geschrieben werden sollte, da es keinen anderen Grund gibt, ihn auf diese Weise zu schreiben.

6

Das ist der Fall, wenn Sie dem Link einen eigenen Titel geben möchten, anstatt ihn aus der Ziel-URL abzuleiten, d. h. [Titel](URL). Dem Link einen Titel zu geben, würde keine Präferenz für das Umschreiben von URLs anzeigen, daher stimme ich @mattmccutchen zu, dass 1 und 2 sich beim Umschreiben von URLs konsistent verhalten sollten.

Es könnte argumentiert werden, dass der Titel, der genau mit der URL übereinstimmt, ein Hinweis darauf ist, dass er nicht umgeschrieben werden sollte, aber was ist, wenn ein Benutzer einen Titel angeben möchte und möchte, dass die URL nicht umgeschrieben wird? Dafür muss es eine andere Methode geben.

Mir fällt ein Suffix für den Titel ein, ähnlich wie bei der Größenänderung von eingebetteten Bildern, obwohl ich nicht sicher bin, wie ein Benutzer das entdecken würde.

Ein eingebettetes Bild kann wie folgt dimensioniert werden:
![Titel|100x200](URL)

Daher könnte das discourse-github-Plugin (vermutlich) so etwas suchen:
[Titel|github-no-rewrite](URL)

7

Ah, es war mir nicht klar, dass sich Ihr (2) nur auf den Sonderfall bezog, bei dem Text und URL gleich sind. Meine Aussage galt dem allgemeinen Fall, bei dem Text und URL nicht gleich sein können; nennen wir das jetzt (2a).

In Fall (2) stimme ich zu, dass es seltsam ist, die URL und nicht den Text neu zu schreiben, wodurch sie inkonsistent bleiben, aber meiner Meinung nach könnte man genauso gut argumentieren, dass, wenn wir die Inkonsistenz vermeiden wollen, der beste Weg darin besteht, sowohl die URL als auch den Text neu zu schreiben und nicht beide. Daher finde ich das Argument, (2) als Opt-out zu behandeln, nicht überzeugend. Da wir einen Opt-out haben sollten, der für (2a) funktioniert, würde ich dazu neigen, Benutzer einfach denselben Opt-out für (2) verwenden zu lassen und das Design nicht zu verkomplizieren. (Ich glaube, das war auch Simons Mannings Idee?)

8

Ich bin mir nicht sicher, ob ich das richtig verstehe (oder ob es möglich ist), aber könnten Sie die Leerzeichen-Maskierung wie in Inline PDF Previews - #45 by Johani verwenden? Dann würde [ text]( url) weder den Text noch die URL umschreiben, und alles andere würde automatisch geändert werden?

9

Diese Version sollte so bleiben, wie sie ist und nicht neu geschrieben werden, lassen Sie mich sehen:

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

geschrieben als:

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

Kein gültiger Test, da das Rewriting von GitHub-Permalinks auf dieser Discourse-Instanz vollständig deaktiviert ist. (Ich frage mich, was das über diese Funktion aussagt, wenn sie auf der „offiziellen“ Instanz deaktiviert ist :upside_down_face:)

Wenn Sie dieses Beispiel stattdessen als Testfall für replace_github_non_permalinks.rb / replace_github_non_permalinks_spec.rb schreiben würden, dann denke ich, dass Sie feststellen würden, dass auch dieser Link umgeschrieben wird.

1 „Gefällt mir“