Talk pages consultation 2019/Phase 2 report/de

Die Konsultation zu Diskussionsseiten 2019 (engl. talk page consultation, TPC) hat das Ende der Phase 2 erreicht, der letzten Phase der globalen Konsultation der Wikimedia-Stiftung.

In der Phase 1 hatten wir die Autoren gefragt, wie sie Diskussionsseiten nutzen, und welche Probleme sie dabei haben. Der Bericht der Phase 1 erschien im Mai, brachte für das neue Projekt eine Produktausrichtung, und stellte spezifische Fragen für die Phase 2. Dieser Bericht nun erschien im August und fasst die Beiträge der Leute in Phase 2 zusammen, und was wir daraus gelernt haben, und er erläutert unsere Pläne für das nächste Jahr.
 * Vom TPC-Team: Danny Horn, Benoît Evellin, Sherry Snyder, Thomas Meadows, Peter Pelberg

Introduction
In Phase 1 der Konsultation hatten wir zwei wesentliche Themen erkannt:


 * Klares Design und passende Werkzeuge : Im Moment ähneln sich Artikelseiten und Diskussionsseiten stark in Aussehen und Bedienung. Die Ähnlichkeit ist irreführend und erschwert es den Leuten, die Diskussionsseiten richtig zu benutzen.
 * Features vs. Flexibilität : Nicht nur Neulinge wünschen sich verbesserte Diskussionsseiten. Tatsächlich wissen gerade die erfahrenen Autoren am besten, wie ungeeignet die bestehenden Werkzeuge wirklich sind. Erfahrene Benutzer möchten einem einzelnen Thread auf einer vielbenutzten Diskussionsseite folgen, und Threads schnell und leicht auch dann finden, wenn sie schon archiviert sind. Um das zu erreichen, muss das System eine Diskussion erkennen können - dass dieser bestimmte Teil der Seite eine einzelne Diskussion darstellt im Unterschied zu anderen Edits auf derselben Seite. Dafür sind vielleicht Änderungen nötig, die die unbegrenzte Flexibilität einer offenen Wikitextseite einschränken.

Vor diesem Hintergrund haben wir folgende Produktausrichtung empfohlen, an der das Bearbeitungsteam der Stiftung arbeiten soll:

Die Wikitext-Diskussionsseiten sollen verbessert werden, nicht ersetzt.

Wir werden ein neues Design über die Wikitext-Diskussionsseiten legen, das ihr Standardaussehen ändert und wichtige Werkzeuge anbietet. Das neue Design soll dem Benutzer zeigen, dass dies keine Artikelseite ist, und ihm bei der Anwendung der Werkzeuge helfen. Er sollte klar angezeigt bekommen, wie man ein neues Gespräch eröffnet, und wie man auf ein laufendes Gespräch oder auf einen bestimmten Beitrag darin antwortet. Es sollte die Signatur automatisch ergänzen und den Beitrag richtig einrücken.

Zur Konsistenz mit den bestehenden Werkzeugen wird das neue Standarddesign für bestehende Benutzer abwählbar sein. Benutzer sollten die gewohnte Ansicht beibehalten und weiter mit dem Wikitext arbeiten können anstelle mit den neuen Tools.

Aber um die Werkzeuge für erfahrene Benutzers bauen zu können, müssen wir vielleicht einige kleine bis mittlere Änderungen in die Wikitext-Konventionen und -praktiken einführen. Unsere Intention ist, solche Änderungen nur vorzunehmen, wenn sie mit einem Feature verbunden sind, das die Autoren nützlich finden.

In Phase 2 haben wir eine Reihe von Fragen gestellt, um verschiedene Aspekte dieses Ansatzes zu prüfen; kurz gesagt haben wir gefragt: was könnte bei diesem Projekt schiefgehen? Wir hatten dazu Diskussionen auf 12 Wikis: neun Wikipedia-Sprachversionen - Chinesisch, Deutsch, Englisch, Französisch, Niederländisch, Polnisch, Russisch, Tschechisch, und Thai - plus Wikidata, Meta, und der englischen Wikisource. Einzelne haben auch in diesem Wiki unter Talk pages consultation 2019/Individual feedback kommentiert. Du kannst die Zusammenfassungen von 7 dieser Community-Seiten nachlesen (in englischer Sprache).

Die erhaltenen Antworten haben uns geholfen, potentielle Rückschläge zu erkennen, und einen Satz von wichtigen Grundsätzen zusammenzustellen, die wir beherzigen müssen. Unten folgt eine Zusammenfassung unserer Erkenntnisse, einschliesslich der fünf Haupteinwände, die man uns mitgeteilt hat, und wie diese Bedenken unsere Vorstellung vom Projekt geformt haben.

Zusammenfassung der Erkenntnisse
Was Zustimmung und Ablehnung zu der vorgeschlagenen Produktausrichtung angeht: Man kann sich eine Linie vorstellen, die die Ansichten repräsentiert, die Leute zu Änderungen an den Diskussionsseiten haben. An einem Ende dieser Linie meinen einige Leute, dass die Diskussionsseiten perfekt sind genau so, wie sie sind. Alle damit verbundenen Probleme könnten gelöst werden, wenn die anderen einfach nur die Regeln verstehen und befolgen würden. Am anderen Ende sagen die Leute, dass statische Wikiseiten nicht als Forumsoftware arbeiten sollten. Sie meinen, dass wir einfach zu einem Diskussionsforumsystem wechseln sollten, wo wir dann neue Gewohnheiten und bessere Arbeitsabläufe ausbilden können.

Die vorgeschlagene Produktausrichtung ist ein Kompromiss zwischen diesen beiden Positionen. Erwartungsgemäß haben die Leute verschieden reagiert. Es gab eine Minderheit, die die Diskussionsseiten völlig unverändert belassen will:

und eine Minderheit, die Wikitext-Diskussionsseiten komplett durch ein anderes System ersetzen will:

Die meisten Antworten lagen in der Mitte. Es gab breite Zustimmung für den hybriden Ansatz, den wir empfohlen hatten:

Es gab weitgehende Übereinstimmung darüber, dass das bestehende Diskussionsseitensystem für neue Benutzer schwierig ist. Einfache Funktionen wie Antworten, Signieren, und den Beitrag passend einzurücken sollten leichter werden.

Starke Zustimmung gab es auch für die Möglichkeit, dass erfahrene Benutzer das neue Design und die Tools abwählen, und weiter wie gewohnt arbeiten können.

There was a wider range of opinions about the possibility of changes to wikitext conventions, which is understandable. It's hard for people to agree with changes that haven't been defined yet. There were many comments along these lines:

Wir wurden gebeten zu verstehen, wie wichtig Kontinuität für die Mechaniken der Pflege und Moderation ist. Zum Beispiel sollte jede Änderung in den Versionsgeschichten mit einem Diff repräsentiert sein. Ebenso in der Beitragsliste des Benutzers. Admins und Oversighter müssen jede individuelle Änderung einzeln revertieren, löschen, oder verstecken können.

Abgesehen vom erwartungsgemäß hohen Interesse an automatischem Einrücken und Signieren, gab es auch viel Interesse daran, bestimmte Sektionen (Gespräche) beobachten zu können und informiert zu werden, wenn jemand in dieser Sektion antwortet.

Es gab etwas Interesse an der Versionsgeschichte einzelner Sektionen, aber nicht zum Preis, dafür die ganze Seite und ihre Versionsgeschichte nicht mehr sehen zu können.

Teilnehmer aus der russischen Wikipedia wiesen auf ein Userskript hin, welches viele der vorgeschlagenen Dinge schon kann:

Das Bequeme-Diskussionen-Gadget von Jack who built the house ist ein tolles Modell. Es inspiriert die neue Produktausrichtung wesentlich. Dieses zuschaltbare Skript bringt eine große Zahl neuer Features mit, die das Lesen und die Teilnahme an Wiki-Diskussionseiten erleichtern, etwa Antworten-Links, Einrücken, Kennzeichnen der zusammengehörigen Edits, und Beobachten einzelner Gespräche. Im Moment gibt es das Tool nur in der russischen Wikipedia.

Das Bearbeitungsteam wird definitiv viel von Benutzer:Jack lernen, der die Fleißarbeit vollbracht hat. Wenn du mehr über das Tool lesen möchtest, haben wir eine Seite mit Notizen zu "Bequeme Diskussionen" in englischer Sprache auf Mediawiki.org, mit einigen Screenshots und Informationen.

Wichtige Einwände und Kernfragen
Es war schön zu sehen, dass die vorgeschlagene Produktausrichtung allgemeine Zustimmung fand. Aber wir erwarteten von der Phase 2 nicht nur die Bestätigung unserer Beschlüsse. Wir wollten auch Kritik und Einwände hören und daraus lernen. Dieser Abschnitt behandelt die häufigsten und schwerwiegendsten Bedenken aus allen Diskussionen. Wir erläutern auch, wie diese Einwände unsere Herangehensweise beeinflusst haben.

Forum oder Werkstatt
Diskussionsseiten existieren in verschiedenen Namensräumen der Wikis. Jeder Kontext hat einen anderen Zweck, den die Autoren mit der Zeit entwickelt und konsentiert haben. In der Phase 2 haben Teilnehmer diese Unterschiede betont.

Teilnehmer unterstrichen insbesondere die Aufgaben der Artikeldiskussionen. Dort arbeiten die Autoren zusammen und besprechen Änderungen der zugehörigen Artikel. Diese Seiten sind keine allgemeinen Chatforen zum jeweiligen Artikelgegenstand, und sollen es auch nicht werden. Diese Sorge gab es oft, wenn es darum ging, die Diskussionsseiten für gelegentliche Benutzer sichtbarer und leichter erreichbar zu machen; die so angelockten Leute könnten eigene Erwartungen zum Seitenzweck mitbringen:

Solche Kommentare zeigen eine grundlegende Eigenschaft der Artikeldiskussionsseiten: es sind Werkstätten. Sie dienen dazu, dass Autoren dort gemeinsam den Artikel verbessern. Das Team erkennt an, dass die Software diese produktive Verwendung fördern muss. Darum werden wir die Auswirkung unserer Neuerungen auf die Benutzung der Diskussionsseiten beobachten, vor allem wenn mehr Unerfahrene sie nutzen. Es ist eine Sache, Dinge zu "vereinfachen" (etwa Antworten, Einrücken, Unterschreiben), aber es ist eine andere Sache sicherzustellen, dass es den Autoren auch zu effektiverer Zusammenarbeit verhilft. Wir werden weiter unten und im Talk pages project einige erste Ideen besprechen, um diese Auswirkung zu beurteilen.

Eine Wikiseite ist eine Wikiseite
In der Phase 2 wurde auch die Frage angesprochen, was Einfachheit und Komplexität bedeuten. Einige Leute meinten, dieses Projekt werde in die Einfachheit der Wiki-Software eingreifen. Dafür kam der Ausdruck auf "eine Wikiseite ist eine Wikiseite". Jede Seite beginnt gleich, wie ein leeres Blatt Papier, egal ob dort ein Artikel entstehen soll, eine Diskussion, oder eine Liste mit Anweisungen. Wer schon weiss, wie man Artikel bearbeitet, braucht für das Diskutieren keine neuen Softwaretools zu lernen.

"Einfach" wird hier in der Art definiert, dass ein System einfach ist, wenn man in ein leeres Editfenster tippen kann mit möglichst wenig Links, Knöpfen, Klicks und Karteireitern. Wenn du eine Diskussion umstellen willst, öffnest du das Editfenster, markierst den Quelltext, schneidest in aus, fügst ihn woanders ein, und drückst den -Knopf. Für erfahrene Benutzer ist das wirklich einfach, weil es genauso funktioniert wie bei Artikeln, uwo sie es schon vielhundertmal gemacht haben. Sie haben den Ablauf schon im Kopf. Wenn das System sich ändert, wenn man jetzt neben dem zu bewegenden Abschnitt einen Link klicken und dann ein kleines Popup-Formular mit dem Verschiebeziel ausfüllen soll, würde das den Prozeß komplizierter machen. Das neue Tool haben sie noch nicht im Kopf. If you want to rearrange a discussion, you open the edit window, select the wikitext, cut it, paste it in a different place, and hit the button. For experienced contributors, this is indeed simple, because it's the same way that it works on article pages, and they've done it hundreds of times before. How to do this is already inside their heads. If the system changes so that you have to click a link next to the section you want to move, and then type into a little pop-up form to say where you want it to go, that would be adding extra complexity to the process. How to use the new tool is not already inside their heads.

In einem geöffneten Wikitextfeld muss man die ganze Benutzung im Kopf haben, denn die Software gibt einem nicht viele Signale zu der Interaktion. Für weniger Erfahrene ist ein leeres Wikitextfeld ganz und gar nicht einfach. Und es ist wichtig zu verstehen, was auf einer Diskussionsseite verlangt wird, weil es zwischen einem Artikel und einer Diskussionsseite es einen Haufen Unterschiede gibt.

Stell dir vor, was passieren würde, wenn jemand in einem Artikel den typischen Diskussionsregeln folgen würde:


 * Füge neue Abschnitte immer am Seitenende an.
 * Unterschreibe deine Beiträge.
 * Verändere nicht die Beiträge anderer Benutzer, außer unter besonderen Umständen.
 * Verändere nicht, was du schon veröffentlicht hast. Für Erläuterungen oder Korrekturen solltest du einen neuen Absatz machen.
 * Wenn du mit jemandem nicht einverstanden bist, schreib deine Einwände und Fragen direkt unter seinen Beitrag, und trenne die Beiträge optisch durch einen Doppelpunkt.
 * Aus einem langen Artikel mit sehr vielen Abschnitten kannst du alte Abschnitte in eine Unterseite archivieren.

Erfahrene Benutzer kämen nie auf den Gedanken, sich in Artikeln so zu verhalten, obwohl die Software sie daran technisch nicht hindern würde. Jedermann muss die kulturellen Gebote und Tabus lernen, oft über eigene Fehler und folgend empörte Reaktionen von irgendjemandem, der glaubt es wäre einfach.

Wer Wikipedia-Artikel zu bearbeiten gelernt hat, kann noch lange nicht erfolgreich an einer Diskussionsseite teilnehmen. Man muss dieselbe Software anders bedienen. Die gegenwärtige Software hilft nicht zum Verständnis. Wir zwingen die Benutzer, die Regeln "im Kopf" zu haben, anstelle sie einfach in der Software einzubauen. Das kann frustrieren und abschrecken. Eine Wikiseite ist keine Wikiseite, wenn man ihre Bedienung zweimal lernen muss.

Allerdings steht hinter dem "Wikiseite ist Wikiseite"-Konzept ein sehr wichtiger Einwand, über den wir im folgenden Abschnitt sprechen: man muss die Arbeit auch schaffen können.

Meisterschaft und Feinsteuerung
Für altgediente Teilnehmer ist es befriedigend, Wissen und Fachkunde im Kopf zu haben. Fachkunde ist nützlich, wenn man etwas Ungewöhnliches oder Kompliziertes auf einer Diskussionsseite zu tun hat. Ein typischer Autor nutzt gelegentlich Diskussionsseiten, macht aber dort nichts Ausgefallenes. Admins oder Leute mit Moderationsaufgaben müssen dagegen viele spezielle Dinge verrichten: eine Diskussion schliessen und zusammenfassen, Unterseiten in eine Meldeseite einbinden, Schiedsgerichtsfälle mit Abschnitten für jeden Beteiligten vorbereiten, oder einfach nur einen Fehler auf der Seite reparieren.

Diese Moderationsaufgaben setzen erhebliche Feinkontrolle über den Seiteninhalt voraus. Ein "vereinfachtes" Tool benutzen zu müssen, wäre hinderlich. Wer das gegenwärtige System gemeistert hat, weiss schon genau, wie er mit den Aufgaben fertig wird. Man geht in den Quelltext und erledigt sie. Die Leute wollen nicht an komplizierten Tätigkeiten gehindert werden, damit die Dinge für Andere einfacher werden. Sie würden ihre Arbeit dann nicht schaffen.

Diese Idee muss für unsere Arbeit am Diskussionsseitenprojekt ein Kernprinzip sein. Wenn wir etwas ändern, muss jemand, der das System gemeistert hat, die nötige Feinkontrolle behalten, um seine Arbeit schaffen zu können.

Vorlagen, Einbindung, und Bots
In Phase 2 wurde die Vorsicht angesprochen, die man walten lassen muss, um nicht Hilfskonstruktionen kaputtzumachen, die die Gemeinschaften mühsam entwickelt haben.

Die Gemeinschaften haben solche komplizierten Hacks und Hilfskonstruktionen erfunden, weil die Mediawiki-Software die benötigten Funktionen nicht aufweist. Von der Community betriebene Bots sind ein Symptom für schwache Software. Sie sind nicht unbedingt die beste Lösung dafür.

Nichtsdestotrotz ist es wichtig, dass unser Team die Funktion der Bots, Vorlagen, und anderer Konstruktionen respektiert. Diese Dinge machen viele Abläufe erst möglich, und wir werden sie nicht rauswerfen. Wir wollen keine existierenden Lösungen stören, solange wir dafür noch keinen Ersatz bieten können, der zumindest Ähnliches leistet.

Zugangsschwellen senken
Zuletzt gab es einige Bedenken, ob die vorgeschlagenen Änderungen wohl aussichtsreiche Neuautoren anlocken würden.

Der Vorschlag, wir sollten absichtlich ein verwirrendes Interface behalten, um Leuten die Mitarbeit an Wikipedia und anderen Projekten zu verleiden, ist eine recht radikale Idee. Sie widerspricht sowohl den Designgrundsätzen für gute Software, als auch den Grundregeln unserer Bewegung.

Neue User investieren mehr Anstrengung in das Erlernen eines Systems, wenn ihre Mitarbeit Wertschätzung erfährt. Wenn sie frühzeitig auf frustrierende oder verwirrende Blockaden stoßen, während sie sich noch kaum engagiert haben, dann geben sie viel leichter auf. Ein verwirrendes Diskussionsseitendesign sortiert wahrscheinlich Leute aus, die Wertvolles hätten ergänzen können. Solche Menschen finden viele Möglichkeiten, anderswo ihre Zeit nützlich zu verbringen, anstelle mit unserem Interface zu ringen.

Aber diese Kommentare beleuchten ein wichtiges Prinzip, dem wir zustimmen: wir wollen kein Diskussionsseitensystem bauen, das sinnloses Geschwätz erzeugt und die Produktivität der Autoren schädigt. Ziel des Teams kann nicht einfach "mehr Konversation" sein, mit der Anzahl von Diskussionsteilnehmern oder Beiträgen als Maßstab. Wir müssen auch auf die Qualität und den Nutzen der Gespräche achten. Eine Möglichkeit wäre zu messen, wie viele Threads Antworten erhalten. Oder man schaut, ob eine Konversation "die ganze Runde schafft": Person #1 stellt eine Frage, Person #2 antwortet, Person #1 liest die Antwort und verbessert den Artikel. Man könnte auch die Revert- und Löschrate auf den Diskussionsseiten verfolgen. Wir werden verschiedene Tests machen und Rückmeldungen sammeln müssen, um sicherzustellen, dass wir ein System bauen, das nützliche Beiträge fördert.

Schlussfolgerung und nächste Schritte
Im Bericht folgen nun die Fragen, die wir in Phase 2 gestellt haben. Vorher möchten wir aber noch erklären, wie es im Diskussionsseitenprojekt weitergeht.

Die TPC 2019 ist hiermit beendet. Wir haben eine Ausrichtung für das Produkt, und einen Satz Grundsätze, um die Arbeit zu leiten. Das Projekt wird vom Bearbeitungsteam der Wikimedia-Stiftung fortgeführt. Es gibt viel zu tun: einen technischen Ansatz finden, an der Benutzerschnittstelle arbeiten, Features priorisieren, die Usability testen, Abläufe untersuchen, die in der Befragung aufgetaucht sind, Erfolgsparameter auswählen - und natürlich mit allen interessierten Teilnehmern reden und kollaborieren.

Es ist für unser Team sehr wichtig, unsere Arbeit transparent und offen zu machen. Wir haben viele Fragen und Ideen, über die wir mit dir reden wollen. Die Hauptprojektseite wird auf Mediawiki.org unter Talk pages project liegen. Wir regen an, dass du Talk pages project auf deine Beobachtungsliste nimmst, damit du die Updates und Ideen der kommenden Monate siehst.

Wir schätzen die Aufmerksamkeit und Überlegungen hoch ein, die ihr alle dieser Befragung gewidmet habt. Wir haben aus diesem Prozess viel gelernt, und wir freuen uns auf die fortgesetzten Gespräche und Zusammenarbeit mit euch.

Frage #2: Separate Gesprächsfäden kennzeichnen
Frage #2 drehte sich darum, schärfer zu definieren, was zu einem einzelnen Diskussionsfaden gehört, damit man solche Threads individuell beobachten kann. Es würde auch Benachrichtigungen, Archivieren und Suchen verbessern. Man könnte dafür die Wikitext-Konventionen ändern, beispielsweise die Abschnittsüberschriften auf Diskussionsseiten im Wikitext anders auszeichnen. Oder man muss einen neuen Link klicken, um einen Thread anzulegen, umzubenennen, oder aufzuteilen.

Viele Leute haben sich schon lange gewünscht, individuelle Threads beobachten zu können. Verbesserungen fanden allgemeines Interesse.

Aber das ist eine schwierige Aufgabe, weil die Leute den Quelltext auf Diskussionsseiten unterschiedlich einsetzen:

Einige Leute waren besorgt, dass es insgesamt weniger Mitarbeit gibt, wenn man individuelle Abschnitte beobachten kann:

Einige Leute waren dieser Idee gegenüber skeptisch:

Das Bearbeitungsteam wird sich die vielen verschiedenen Vorschläge aus dem Kreis der Teilnehmer anschauen. Hier sind zwei der Vorschläge:

Mehrere Leute meinten, dieses Konzept werde auf einigen Wikis schon benutzt, unter Verwendung von Einbindungen:

Dieser Kommentar empfiehlt, lesbare Links zu behalten:

Frage #3: Neulingen helfen, die Diskussionsseiten zu finden
Frage 3 handelte davon, die Diskussionsseiten sichtbarer zu machen, damit Neulinge merken, dass es sie gibt. In den Usertests für diese Konsultation baten wir 10 potentielle Autoren, die Diskussion zum Artikel zu suchen. Nur eine Person bemerkte den Diskussionsreiter.

Die Reaktionen auf eine möglichen Verlegung des Diskussionslinks anderswohin waren lau. Viele Leute betonten, dass die "Artikel-" und ""-Karteireiter verschiedene Seiten repräsentieren, während die ""-, ""-, und ""-Karteireiter für Aktionen stehen, die man auf diesen Seiten ausführen kann. Many people pointed out that the "Article" and "" tabs represent different pages, while the "", "", and "" tabs represent actions that you can take on those pages.

Es gab etwas Interesse an einem Anmerkungs-ähnlichen Feature, um eine Konversation mit dem relevanten Artikelteil zu verbinden. Dies ist kein Feature, auf das wir uns jetzt konzentrieren werden, aber vielleicht eine interessante Idee für später.

Frage #4: Wo sollen die Diskussionstools angezeigt werden (Namensräume)
Frage #4 erfragte, in welchen Namensräumen Diskussionen stattfinden. Viele Wikis haben Gemeinschaftsdiskussionen im Projektnamensraum ( oder  ) anstelle in einem Diskussionsnamensraum (  oder  ). Treffpunkte/Cafés, Melde- und Funktionsseiten wie etwa die Löschkandidaten liegen oft im Projektnamensraum. Das System wird wissen müssen, auf welchen Seiten es die neuen Tools anzeigen muss. Eine Möglichkeit wäre, alle Diskussionen in einen Diskussions-Namensraum zu verlagern. Oder man könnte die Features in anderen Namensräumen mit einem magischen Wort einschalten.

Manche waren dagegen, alle Diskussionen in einen Diskussions-Namensraum zu verlagern, weil die Projektseiten manchmal auch eine Seite brauchen, auf der man über den Ablauf selbst sprechen kann.

Diese Antwort fasst die Schwierigkeiten gut zusammen:

Eine Konversation bezeichnete ein Problem mit den magischen Wörtern, und einige mögliche Lösungen:

Ein anderer durchdachter Beitrag auf diese Frage:

Frage #5: Zielkonflikt bei der Versionsgeschichte
Frage #5 fragte nach der Bedeutung der Versionsgeschichte einer ganzen Seite verglichen mit der Versionsgeschichte eines bestimmten Threads. Unstrukturierte Wikitext-Diskussionsseiten stellen die Versionsgeschichte der ganzen Seite bereit. Flow zeigt Versionsgeschichten jedes Threads, und eine eingeschränkte Versionsgeschichte jeder Seite. Ideal wäre es, wenn wir auf unstrukturierten Wikitextseiten beides anbieten könnten, aber das können wir nicht umsetzen. Vor der Entscheidung müssen wir die Vor- und Nachteile verstehen.

Es wurde gesagt, komplette Versionsgeschichten seien hilfreich, um einen groben Überblick uber die Änderungen zu bekommen. Das sei vor allem für's Moderieren nützlich:

Andere hielten die Versionsgeschichte der ganzen Seite in manchen Fällen für notwendig:

Fokussierung war einer der am stärksten wahrgenommenen Vorteile für Thread-spezifische Versionsgeschichten. Leute mochten die Vorstellung, ein bestimmtes Gespräch anstrengungslos verfolgen zu können:

Andererseits geben die meisten Leute der Versionsgeschichte der kompletten Seite den Vorzug, wenn sie zwischen den beiden Ansätzen entscheiden müssen:

Diese Person zeigt den Zielkonflikt genauer, indem sie beleuchtet, auf welche möglichen Arbeitsweisen wir Rücksicht nehmen müssen, wenn wir Tools bauen, die solche Edits auf Diskussionsseiten vermitteln und verfolgen sollen:

Frage #6: Position der Metadaten
Frage #6 betraf die Bausteine, die manche Wikis oben auf Artikeldiskussionen platzieren. Sie können Anweisungen, Warnungen, oder FAQs enthalten. Sie können die Seitenqualität beschreiben, relevante WikiProjekte verlinken, oder vergangene Aktivitäten kennzeichnen. Viele Neubenutzer verwirrt es, wenn sie oben auf der Artikeldiskussion diskussionsfremdes Material finden. Besser wäre es, diese Inhalte ganz oder teilweise woandershin auf derselben Seite oder auf eine andere Karteikarte zu schieben. Wir haben erfragt, welche Bausteine unbedingt auf der Diskussionsseite gezeigt werden müssen, und welche woanders hin könnten.

Der Umfang der Metadaten auf Diskussionsseiten variiert signifikant je nach Wiki. Die Stärke des "Rauschens" war beunruhigend, vor allem in den Wikis, die ausgiebig Metadaten auf der Diskussionsseite speichern. Allerdings gehört nicht alles im Seitenkopf zu den Metadaten. Es gibt auch nützliche Informationen für die Seitenbenutzer.

Die beliebtesten Empfehlungen waren, für die Metadaten einen anderen Tab anzubieten oder sie standardmäßig einzuklappen. Oder man könnte in den Mediawiki-Kern eine echte Metadaten-Unterstützung einbauen, wie es früher schon vorgeschlagen wurde (T55508).