Wikipedia Diskussion:Erzwungene Zusammenfassung

Von Wikipedia Diskussion:Projektneuheiten, Forcesummary durch Missbrauchsfilter ersetzen

Diese Diskussion wurde von Wikipedia Diskussion:Projektneuheiten hierher verschoben

Am 13. Juli wurde die im Februar mit deutlicher Mehrheit beschlossene Option forcesummary aufgrund einer Bugmeldung deaktiviert, die verspricht: „A better alternative utilizing AbuseFilter has been written and is ready to replace 'missingsummary'“. Am 14. Juli beginnt die tatsächliche Diskussion zu jenem Missbrauchsfilter, dann plötzlich mit ganz anderen Konfigurationsvorstellungen (neben der zwar per MB nicht abgesegneten, aber mutmaßlich doch allgemein befürworteten Einschränkung auf den ANR ist das des Initiators Wunsch „Bearbeitungen die weniger als X Zeichen am Text ändern, nicht zu berücksichtigen“, mit der Folge, dass z.B. unbelegte Zahlenänderungen, etc., seinerzeit einer der Hauptanlässe für das MB, nicht mehr berücksichtigt würden). Bis heute ist der Missbrauchsfilter nicht aktiv – und das obwohl die forcesummary-Option ohne weitere Ankündigung sogar für diejenigen deaktiviert wurde, die sie schon vor dem MB für sich eingestellt hatten. Zumal: wenn ich das richtig im Kopf habe wurde schon bei der Umsetzung des MBs, entgegen dem Wortlaut der siegenden Option 2, die Einstellung für bereits existierende Benutzeraccounts nicht aktiviert (das „Rückgängigmachen“ des Beschlusses war also weit umfangreicher als er selbst). Was lief da schief, was hab ich falsch verstanden, und wann kommt ein brauchbarer Zusammenfassungshinweis für alle? --YMS 12:56, 18. Jul. 2009 (CEST)

Ich kann nur aus technischer Sicht sagen, das verändern von Benutzereinstellungen von angemeldeten Benutzern wird nicht vorgenommen, da es eine Bevormundung darstellt. Daher war dieser Punkt des Meinungsbildes nicht umsetzbar. Es ist nur möglich, die Standardeinstellungen für nicht-angemeldete Benutzer zu ändern. Diese Einstellungen werden dann auch bei anlage eines Benutzerkontos berücksichtigt. Ich kann mir beim Punkt "für diejenigen deaktiviert wurde, die sie schon vor dem MB für sich eingestellt hatten" nicht vorstellen, das es wirklich so ist, da es eine gleiche Bevormudung darstellt. Falls es doch der Fall gewesen ist, dann ist es ein Bug und sollte gemeldet werden.

Die Tatsache, das die Diskussion zum Missbrauchsfilter erst nach der deaktivierung von forceeditsummary angefangen hat, ist wahrscheinlich einer schlechten Kommunikation zu entnehmen. Da man nie weiß, wann Bugs umgesetzt werden ist es schwierig die Diskussion vorher anzufangen, wenn es noch kein Bedarf gibt (was aber ein allgemeines Problem hier ist). Sicher wäre es schöner gewesen, man hätte es lückenlos machen können, aber nicht alles ist möglich. Der Umherirrende 13:07, 18. Jul. 2009 (CEST)

Raymond hatte damals in der dem MB vorhergehenden Diskussion die Möglichkeit erwähnt, Benutzereinstellungen nachträglich zu ändern: „Theoretisch ließe sich über ein Wartungsskript durch die Serveradmins diese Option zwangsweise für alle Benutzer einschalten“. Er hatte bezüglich des „theoretisch“ Bedenken wegen Benutzerbeschwerden - aber genau in diese Richtung, nämlich alle statt neue Benutzer, wurde das MB noch kurz vor Start geändert, und genau diese Option hat dann auch gewonnen. Aber darum geht's mir hier gar nicht, sondern bei mir ist es so, dass ich diese Option schon lange vor dem MB aktiviert hatte, und seit Kurzem nicht mehr habe. Ich kann mich beim besten Willen nicht erinnern, wann oder warum ich das abgeschaltet haben sollte.

Und was die Missbrauchsfilter-Diskussion angeht, kann ich nur mein Zitat aus Church of emacs' Bugreport vom 15. Juni wiederholen: „A better alternative utilizing AbuseFilter has been written and is ready to replace 'missingsummary'“, und unter dieser Promisse wurde der Report dann wohl auch umgesetzt. Aus dem „has been written and is ready“ wurde einen Monat später „sollten wir nun ein Filter entwickeln“. --YMS 13:51, 18. Jul. 2009 (CEST)

Ich hatte ja bei Wikipedia:Missbrauchsfilter/Anträge#Fehlende_Zusammenfassung eine JavaScript-Alternative vorgeschlagen. Kann man so aus dem Vorschauzwang von zhwiki übernehmen mit einer kleinen Ergänzung, dass beim Tippen in der Zusammenfassung der Button auch wieder aktiv wird. Merlissimo 14:01, 18. Jul. 2009 (CEST)

a) Ich finde das „A better alternative utilizing AbuseFilter has been written and is ready to replace 'missingsummary'“ auch … irritierend.

b) Der Vorschauzwang ist etwas anderes als die Aufforderung, die Zusammenfassungszeile auszufüllen. Man kann ja auch beides realisieren, wobei ich eine ausgefüllte Zusammenfassungszeile für deutlich wichtiger halte. — Raymond ^{Disk. Bew.} 14:23, 18. Jul. 2009 (CEST)

Das die Option jetzt bei dir (YMS) deaktiviert ist und du sicher bist, dass du es nicht selber warst, irritiert mich, aber ich habe mit den Konfigurationssachen keine Ahnung, daher müsste sich das jemand anders anschauen. Ich sehe es eher als Bug und nicht als Feature, aber vielleicht wurde es von Brion falsch verstanden und er hat alle Einstellungen geändert. JavaScript hat immer den Nachteil, das man es Browser unabhängig hinbekommen muss und man es deaktivieren kann. Wenn JavaScript, dann sollte es aber so sein, das der Button aktiv wird, wenn etwas in der Zusammenfassung steht (und wieder deaktiviert, wenn nichts drin steht)

Vielleicht hat Church of emacs gedacht, der aktuelle Filter, der die Aktion loggt, reicht aus und müsste nur aktiviert werden. Der Umherirrende 14:29, 18. Jul. 2009 (CEST)

@Raymond Ich wollte keinen Vorschauzwang haben, aber die Button-Deaktivieren-Funktion bleibt die gleiche inkl. der ganzen Ausnahmen bei undo usw. (da brauch man sich dann keine Gedanken mehr zu machen). Man muss nur noch den Button beim Tippen in der Zusammenfassung wieder aktivieren, und schon hat man das Script vom Vorschauzwang in einen Zwang zur Zusammenfassungszeile umgeschrieben - mehr meinte ich nicht. Merlissimo 15:10, 18. Jul. 2009 (CEST)

Ah, dann hatte ich das falsch verstanden. Danke für die Aufklärung.— Raymond ^{Disk. Bew.} 15:36, 18. Jul. 2009 (CEST)

Ich habe mal unter Wikipedia:Missbrauchsfilter/Anträge#JavaScript-Lösung ein Vorschlag gemacht. --Der Umherirrende 17:17, 18. Jul. 2009 (CEST)

Bei mir war die Option wie bei YMS auch deaktiviert. Das hängt ziemlich sicher nicht mit der allgemeinen Deaktivierung zusammen, da es grundverschiedene Dinge sind, ob eine Konfigurationszeile gelöscht wird oder ob ein Wartungsskript läuft, das bei vorhandenen Benutzern die Einstellung löscht. Letzteres ist zu 99,99 % nicht gelaufen, da ich dazu keinen Eintrag im Server-Admin-Logbuch finde. Ich tippe eher auf einen Bug im Zuge der Umstellung des ganzen Preferenzen-Systems vor einigen Wochen. — Raymond ^{Disk. Bew.} 15:36, 18. Jul. 2009 (CEST)

Ich kann YMS und Raymond bestätigen. Auch bei mir ist das Häkchen in den pers. Einstellungen ohne mein Zutun verschwunden. --Stepro 16:28, 18. Jul. 2009 (CEST)

Ist das Häkchen seit dem 15. Juni weg? Dann könnte es ein Bug in zusammenhang mit der Umgestaltung des Preference-System handeln. Der Umherirrende 17:17, 18. Jul. 2009 (CEST)

Den Filter gibt es schon seit Ewigkeiten; mein Eindruck war, dass seine Aktivierung bislang nur deswegen nicht vorgenommen wurde, weil Forcesummary immer noch aktiv war (beide Lösungen gleichzeitig live zu schalten wäre natürlich vollkommen inakzeptabel). Dass die Obergrenze von 5% überschritten wurde, war ein Ereignis dass fast zeitgleich mit meinem Bugreport eintrat (vgl. Zeitpunkt von [1]), ich kann mich nicht daran erinnern, dass mir diese Tatsache zum Zeitpunkt des Bugreports bewusst war. Übrigens ist es richtig dass der Filter an sich funktioniert ist, wie es aussieht, war es einfach eine Fehlentscheidung die Filter-Grenze auf 5% zu setzen. Es bleiben mehrere Alternativen:

1. Forcesummary wieder aktivieren lassen (Pro: ?; Contra: Dauert lange, Umsetzung und Usability ist sehr schlecht)
2. Filter einsetzen: (Pro: Namensraumspezifisch; Contra: Usability schlecht)
   1. Anhebung der 5%-Grenze erwirken (Pro: Löst das Problem dauerhaft; Contra: Dauert lange)
   2. Irgendein Hack, mit dem man die 5%-Grenze austrickst (Pro: dürfte recht schnell umsetzbar sein; Contra: Hacks sind keine Dauerlösung)
3. Javascript-Lösung (Pro: in angemessener Zeit umsetzbar, NS-spezifisch, Usability ist besser; Contra: Möglicherweise gibt es Inkompatibilitäten mit manchen Browsern, muss vorher gut getestet werden)

---

Meiner Ansicht nach spricht viel für eine Javascript-Lösung. Was meint ihr? --Church of emacs D B 18:27, 18. Jul. 2009 (CEST)

Und was machen die, die kein Javascript einsetzen (können/wollen)? Siehe auch Wikipedia:Barrierefreiheit. -- Chaddy · D·B - DÜP 20:36, 18. Jul. 2009 (CEST)

Das ist kein Problem. Wer Javascript deaktiviert hat, der kann Seiten ganz normal abspeichern. Bei Bedarf kann man zusätzlich zur Javascript-Lösung noch einen Missbrauchsfilter einsetzen, so dass Benutzer ohne Javascript durch den Missbrauchsfilter auf die ZuQ hingewiesen werden. --Church of emacs D B 21:31, 18. Jul. 2009 (CEST)

Was ist mit den Leuten, die JavaScript für ihre Monobooks et al. nutzen wollen, aber sich nicht in den JavaScript-Zusammenfassungszwang begeben wollen? Grüße, —DerHexer (Disk., Bew.) 21:36, 18. Jul. 2009 (CEST)

Die kriegen eine JS-Lösung gegen den Zwang. Nicht schwer, mir stellt sich bloß noch die Frage, ob ich die automatische Zusammenfassung dann pseudozufällig aus ganz Unicode, [A-Za-z ]+ oder 'nem Dictionary erwürfele. Viele Grüße, —mnh·∇· 00:48, 19. Jul. 2009 (CEST)

Von Wikipedia:Missbrauchsfilter/Anträge, Fehlende Zusammenfassung

Diese Diskussion wurde von Wikipedia:Missbrauchsfilter/Anträge hierher verschoben

Was meint ihr? Gruß, --Church of emacs D B 13:32, 14. Jul. 2009 (CEST)

Bin ja immer noch für die Deaktivierung des wp-Save Button per Javascript für (new String(wgUserGroups)).indexOf("autoconfirmed")==-1 || (document.editform.wpSection.value=="new" && document.getElementById('cannot-submit')). Code könnte man aus dem Preview-Zwang von zhwiki übernehmen. Merlissimo 14:09, 14. Jul. 2009 (CEST)

Mit einer Javascript-Lösung wäre ich auch einverstanden. Aber bitte so, dass Benutzer ohne Javascript weiterhin editieren können. --Church of emacs D B 14:50, 14. Jul. 2009 (CEST)

Logik: Deaktivierung des wp-Save Button per Javascript funktioniert ja nur, wenn JavaScript aktiviert ist. Ansonsten bleibt er ja immer aktiv. Merlissimo 14:55, 14. Jul. 2009 (CEST)

Ja, das habe ich durchaus so verstanden, mein Hinweis bezog sich generell auf alle Javascript-Ansätze, nicht nur auf diese spezielle Lösung. --Church of emacs D B 20:14, 14. Jul. 2009 (CEST)

Als Text kann man auch MediaWiki:Missingsummary übernehmen. Der passt auf jeden Fall, da er auch jetzt schon nur für den Artikelnamensraum geschrieben wurde. Es ist aber dann anzunehmen, das dieser Filter für wirklich alle ist? Keine Ausnahme für irgendeine Benutzergruppe, wäre wünschenswert und ich denke nicht, das es bei irgendeiner (Aufräum-)Arbeit stören sollte. Der Umherirrende 20:53, 14. Jul. 2009 (CEST)

Wer nur einen kleinen Rechtschreibfehler entfernt, sollte keine ZuQ angeben müssen (X=50 wäre mein konkreter Vorschlag). Da halte ich nichts von. Gerade Zahlenänderungen, Namensänderungen/ergänzungen usw. sind nur wenige Byte groß und sollten auf jeden Fall per Zusammenfassung kommentiert werden. — Raymond ^{Disk. Bew.} 14:14, 14. Jul. 2009 (CEST)

Man kann auch große Umräumaktion im Artikel machen, wo dann die Differenz gering ist (mit etwas Glück), aber Vandalimus vorhanden ist. Der Umherirrende 20:53, 14. Jul. 2009 (CEST)

gudn tach!

welchen nachteil haette die js-methode (gegenueber dem AF)? ein kleiner js-vorteil waere, dass unsere server entlastet wuerden. -- seth 21:58, 15. Jul. 2009 (CEST)

Ohne jetzt diese konkrete Javascript-Funktion ausprobiert zu haben: Ich stelle mir vor, dass man dadurch einen Seitenaufruf spart. Zum Beispiel könnte der Button „Seite speichern“ so lange deaktiviert sein, bis man eine Zusammenfassung eingibt (solange keine ZuQ eingegeben ist, wird die Zeile farbig hervorgehoben). Die Usability wäre sehr viel besser im Vergleich zu einer Lösung mit dem AF oder dem MediaWiki-Core-Feature. --Church of emacs D B 16:20, 16. Jul. 2009 (CEST)

Jepp, so war es gedacht. Die bedenken, dass jemand nicht merkt, dass die Seite nicht gespeichert wurde würden damit auch wegfallen. Es bleiben nur ein paar Fragen:

• welche Namenräume (ANR, VNR, Kat?)
• welche Benutzergruppen
• Seite leeren könnte man auch mit verhindern, aber erschwert IMO nur die Vandalismuserkennung

Nachteil ist, dass man es mit deaktivierten JavaScript umgehen kann. Aber Vandalenprofies finden eh immer einen Weg. Merlissimo 16:48, 16. Jul. 2009 (CEST)

Kleiner Hinweis, falls sich jemand dazu äußern möchte: Ich habe die Ersetzung von forceeditsummary durch einen Missbrauchsfilter (weniger dessen konkrete Ausgestaltung oder Alternativen dazu, um die es hier geht, als viel eher die Vorgehensweise dazu) bei den Projektneuheiten thematisiert.
Und wenn ich hier schon schreibe, dann auch noch eine Anmerkung zu einer JavaScript-Lösung: Die würde aus dem eventuellen (und ignorier- und abschaltbaren) Hinweis zu einer fehlenden Zusammenfassung einen tatsächlichen Zusammenfassungszwang machen. Mich persönlich würde das nicht stören, aber ich kann mir gut vorstellen, dass das andere anders sehen. --YMS 14:13, 18. Jul. 2009 (CEST)

Ich denke es ist vollig in Ordnung, wenn man es von allem verlangt, die Zusammenfassung zu nutzen und es keine Möglichkeit gibt, sie zu ignorieren. Das kann man auch für andere Namensräume verlangen. Ein einfaches "K" ist meist auch nicht aussagekräftig, daher wäre ein weiters Wort vorteilhaft und das "K" nutzt man dann nur zum Filter der Beobachtungsliste oder der Letzten Änderungen. Ich würde daher vorschlagen, man macht beide Möglichkeiten. Die Java-Script-Lösung als erste Vorhut, die das meiste sicher abhalten wird und den AbuseFilter dann für die ganz vernatischen, da man den AbuseFilter ja nicht umgehen kann (wenn er richtig eingestellt ist). Der Umherirrende 20:46, 18. Jul. 2009 (CEST)

JavaScript-Lösung

Ich habe mir mal Gedanken zu einer JavaScript-Lösung gemacht (mit IE7 - ohne Gewähr und ohne Support)

if ( wgNamespaceNumber == 0     /* ANR        */
  || wgNamespaceNumber == 6     /* Datei:     */
  || wgNamespaceNumber == 8     /* MediaWiki: */
  || wgNamespaceNumber == 10    /* Vorlage:   */
  || wgNamespaceNumber == 12    /* Hilfe:     */
  || wgNamespaceNumber == 14    /* Kategorie: */
   ) {
    var wpSummary  = document.getElementById( 'wpSummary' );
    var wpSave     = document.getElementById( 'wpSave' );
    var wpTextbox1 = document.getElementById( 'wpTextbox1' );
    if( wpSummary && wpSave ) {
        var wpSaveTitle = wpSave.title;
        var wpSaveTitleDisabled = 'Bitte Zusammenfassung angeben.';
        var keyFunction = function () {
            var wpSave = document.getElementById( 'wpSave' );
            var wpSummary = document.getElementById( 'wpSummary' );
            var wpTextbox1 = document.getElementById( 'wpTextbox1' );
            if( wpSave && wpSummary ) {
                var disable = wpSave.disabled;
                if( wpSummary.value.match( /^\s*(?:\/\*.*\*\/)?\s*$/ ) ) {
                    disable = true;
                } else {
                    disable = false;
                }
                if ( wpTextbox1 && wpTextbox1.value.match( /^\s*#(?:WEITERLEITUNG|REDIRECT)/i ) ) {
                    disable = false;
                }
                if( disable ) {
                    wpSave.disabled = 'disabled';
                    wpSave.title = wpSaveTitleDisabled;
                } else {
                    wpSave.disabled = '';
                    wpSave.title = wpSaveTitle;
                }
            }
        };
        keyFunction();
        wpSummary.onkeydown  = keyFunction;
        wpSummary.onkeypress = keyFunction;
        wpSummary.onkeyup    = keyFunction;
        if( wpTextbox1 ) {
            wpTextbox1.onkeydown  = keyFunction;
            wpTextbox1.onkeypress = keyFunction;
            wpTextbox1.onkeyup    = keyFunction;
        }
    }
}

Es wäre nett, wenn einige drüber schauen könnten und auch andere Browser getestet werden. Es kann gerne geändert werden. Zusätzlich sollte man aber trotzdem ein AbuseFilter schalten um auch alle zu erwischen. Mit einer JavaScript-Lösung kann man die Anzahl der Treffer aber deutlich reduzieren, sodass vielleicht der Filter sich nicht selber deaktiviert. --Der Umherirrende 17:06, 18. Jul. 2009 (CEST)

Moin, zwei Fragen: weshalb nicht auch Hilfe und Mediawiki? Wieso bei allen drei Events, reicht nicht Prüfung bei keyup am Schluß? (Mag sein, dass ich was Offensichtliches übersehe, Fieber und Code harmonieren nicht gut. Elende Rüsselpest. :( )Viele Grüße, —mnh·∇· 17:53, 18. Jul. 2009 (CEST)

Die Namensräume habe ich nur beispielhaft gemacht, habe die beiden aber ergänzt, macht ja Sinn. Zur zweiten Frage: Ich programmiere JavaScript eher mit Try and Error als das ich viel davon weiß (http://de.selfhtml.org hilft gut dabei). Daher weiß ich nicht, wann ein Browser welches Event auslöst. Ich habe mir nur gedacht, um eine möglichst akutelle Anzeige zu ermöglichen, sollten alle key-Events abgedeckt werden. Das Problem war, wenn ich beim Löschen von Zeichen, die Rücktaste lange gedrückt halte und keine Zeichen mehr da waren, war der Button immer noch aktiv, daher wählt ich up und down. Wahrscheinlich gibt es auch noch unterschiede zwischen den Browsern, wie sie die Events abarbeiten, davon habe ich aber keine Ahnung, wenn ich programmiere, bin ich froh, wenn es in meinem Browser (IE7) funktioniert und das gewünschte Ergebnis bringt. Ich denke aber, hier lesen einige Leute mit, die das besser beherschen. Ich wollte nur einen Ansatz geben, da hier immer davon gesprochen wurde, aber keine tatsächliche Umsetzung genannt wurde. Falls jemand das anders machen möchte und es besser funktioniert, habe ich kein Problem damit, wenn meins verfällt. --Der Umherirrende 18:07, 18. Jul. 2009 (CEST)

Ich habe das mal unter MediaWiki:Forcesummary.js abgelegt. Leider funktioniert das Skript bei mir (bzw. meinem Testaccount) nicht (es gibt keine Veränderung), habe ich es vielleicht falsch eingebunden? Getestet unter FF3 und Konqueror. Keine Fehler in der Error Console --Church of emacs D B 17:56, 18. Jul. 2009 (CEST)

Nein, das ist falsch eingebunden. Es fehlt ein addOnloadHook();

addOnloadHook(function() {
<!-- hier den Quelltext hinkopieren -->
});

Das einfache einfügen von der Skriptseite hilft in diesem Fall nichts, da es nicht in einer Funktion steht, soll ja nur Beispielquelltext sein. --Der Umherirrende 18:07, 18. Jul. 2009 (CEST)

Namespace 8 mit reinzunehmen, ist doch Unsinn: Da können so oder so nur Admins arbeiten, will man auch denen vorschreiben, wie sie wann wo was kommentieren sollen? Grüße. —DerHexer (Disk., Bew.) 20:41, 18. Jul. 2009 (CEST)

Ja, wenn man versucht die Änderungen zu verfolgen ist es immer hilfreich, wenn dort etwas steht, finde ich und finde es nicht unsinnig, meist erspart es eine Nachfrage beim Admin, wenn man die eigentliche Bedeutung der Änderung nicht aus der Änderung selber entdecken kann. --Der Umherirrende 20:46, 18. Jul. 2009 (CEST)

Was ist geplant, um dieses JavaScript einfach abschalten zu können, wenn man das Denken noch selbst übernehmen will? Laut Meinungsbild soll dies mit einem Klick funktionieren (und eigentlich auch kein JavaScript sein … die Vorgaben, die zu erfüllen sind, sind eigentlich deutlich und bieten wenig Spielraum zur Interpretation). Grüße, —DerHexer (Disk., Bew.) 21:06, 18. Jul. 2009 (CEST)

Bist jetzt garnichts, und von meiner Seite muss auch nichts gemacht werden, da es keine (für mich erkennbaren) Nachteile in der Ausfüllung der Zusammenfassung gibt. Der Zeitfaktor kann es nicht sein, da im nachhinein mehr Zeit verbraucht wird, als der einzelne für das Ausfüllen braucht. Zur Option des Meinungsbildes: Es soll hier nicht das Core-Feature nachgebildet werden, so habe ich es verstanden. Daher habe ich darüber nicht nachgedacht. Der Umherirrende 21:25, 18. Jul. 2009 (CEST)

Pardon, wofür haben wir denn bitte jetzt eine Option zum Ausschalten? Das Meinungsbild drückt sich eindeutig aus: Wer diese Funktion nicht nutzen will, kann sie abschalten. Wenn dies das JavaScript nicht anbietet, erfüllt es die Bedingungen eben dieser Abstimmung nicht und sollte nicht eingebunden werden. Schon schlimm genug, dass tausende Bearbeitungen wegen solch eines Zwanges nicht gespeichert wurden, Benutzer aus formalen Gründen von der Mitarbeit abgeschreckt wurden. Nunja, anderes Thema … Grüße, —DerHexer (Disk., Bew.) 21:34, 18. Jul. 2009 (CEST)

Könnte man nicht die Abschaltbarkeit über ein Gadget realisieren?
Zum Javascript: Meinungsbilder sind keine Gesetze an die wir uns ohne nachzudenken halten müssen. Die Verteidigung von forcesummary mit Berufung auf das Meinungsbild ist aus zwei Gründen fraglich: Erstens war zum Zeitpunkt des MBs wohl wenigen Benutzern bewusst wie schlecht die Usability wirklich ist, zweitens hat sich inzwischen herausgestellt, dass forcesummary dafür sorgt, dass sehr viele (auch konstruktive) Bearbeitungen abgebrochen werden. Die Tatsache, dass vor Einführung von forcesummary ein Konsens bestand, bedeutet nicht, dass dieser immer noch besteht. (Ich selbst habe mich bei dem Meinungsbild enthalten, inzwischen bin ich davon überzeugt, dass diese Softwarefunktion mehr Schaden anrichtet als nützt).
Was hier vorgeschlagen wird ist ja auch nicht eine ersatzlose Abschaffung von der ursprünglich vorgeschlagenen Lösung, sondern eine Änderung auf ein in vielerlei Hinsicht besser geeigneten Verfahrens, vgl. die hier genannten Vorteile. Gemäß WP:IAR und WP:SM halte ich eine Änderung der technischen Umsetzung ohne neues MB für problemlos durchführbar, insbesondere weil im MB die inhaltliche Forderung nach einem solchen Mechanismus im Vordergrund stand, und nicht die konkrete technische Lösung. Gruß, --Church of emacs D B 21:47, 18. Jul. 2009 (CEST)

gudn tach!

dopplete maskierung (\\s statt \s) ausserhalb von strings ist nicht noetig, oder? hab sie deshalb entfernt. ausserdem schlage ich einen punkt "." statt "[^\/]" vor, da slashes auch in ueberschriften vorkommen koennen, aber vermutlich niemand mit "*/" seinen kommentar beendet. alternativ koennte man mit zero-width look-ahead-assertions arbeiten. die allerdings sind iirc bei aelteren browsern nicht immer implementiert.

uebrigens: statt den string zu ersetzen und anschliessend zu vergleichen koennte man das auch in einem rtusch tun, indem man einfach prueft, ob der string von (/^\s*(?:\/\*.*\*\/)?\s*$/ gematcht wird. -- seth 20:48, 18. Jul. 2009 (CEST)

Da liegst du falsch. Ich bin dort innerhalb eines Strings, da ich die Funktion aus einem String erzeuge. Vielleicht keine überliche Vorgehensweise, aber es funktioniert (erkennbar am highlighting). Mir kam es immer so vor, das bei einem Punkt nicht richtig gemachted wird, da das nachfolgende Zeichen ja im Punkt selber enthalten ist, aber wenn es funktioniert, habe ich damit kein Problem. Mit assert kenne ich mich nicht aus, aber du nennst ja selber schon deine Einschränkung: Es soll so viele Browser wie möglich einschließen.

Ich habe mein RegEx dafür angepasst, damit auch nur Leerzeichen erwischt werden sollen. Da ich von assert keine Ahnung hab. Der Umherirrende 21:25, 18. Jul. 2009 (CEST)

ach verflucht; hab den auesseren string ueberhaupt nicht beachtet, sondern mich reflexartig nur auf den regexp gestuerzt. sorry!

was meinst du mit Mir kam es immer so vor, das bei einem Punkt nicht richtig gemachted wird, da das nachfolgende Zeichen ja im Punkt selber enthalten ist[...]?

.*\*\/ ist greedy und matcht hier alles bis zum letzten vorkommnis von '*/'.

mit look-ahead assertion waere es/^\s*(?:\/\*(?:.(?! \*\/))*. \*\/)?\s*$. damit wuerde bis zum ersten vorkommnis von "*/" gematcht.

hab noch mal gestoebert; look-ahead scheint keine probleme unter js zu bereiten und ist schon 1999 im ecma-standard verzeichnet (look-behind jedoch nicht). -- seth 01:33, 19. Jul. 2009 (CEST), 22:06, 21. Jul. 2009 (CEST)

Ein anderes Problem mit Assertions: sie sind vollkommen unverständlich für jeden, der (wie ich) nur die POSIX-Syntax kennt. Nicht gut für die Wartung, imo nur sinnvoll, wenn's wirklich keine Alternativen gibt. Was ist eigentlich das Problem bei /^(.*\\*\\/)?[:space:]*$/ (lies: Falls nur Whitespace nach */ oder nur Whitespace)? Ich hab glaub ich noch nie gesehen, dass ein Benutzer "/* foo */ bar baz */" schreibt, wenn falsch, dann schreiben die /* foo bar */. Viele Grüße, —mnh·∇· 02:18, 19. Jul. 2009 (CEST)

naja, PCRE ist in weiten teilen, gerade was das www betrifft, nicht nur maechtiger als POSIX, sondern afaik auch verbreiteter; nicht zuletzt, da im php-manual suggeriert wird, dass PCRE die bessere wahl sei und dies in allen moeglichen foren und im usenet verbreitet wurde und wird. in regexps wie /^(?:.*\*\/)?[:space:]*$/ sehe ich spontan auch kein problem, habe ja oben selbst einen POSIX-kompatiblen aehnlichen ausdruck genannt. bloss sehe ich bei so was eben ein etwaiges, grundsaetzliches, verstecktes problem, naemlich dass man nur vermuten (aber nicht so genau wissen) kann, wie inflationaer "*/" gebraucht wird, und was alles vorm threadtitel stehen kann. meiner erfahrung nach ist es bei regexps grundsaetzlich am besten, wenn man moeglichst viel wissen/praemissen hineinsteckt, um die menge an false positives moeglichst gering zu halten. -- seth 22:53, 19. Jul. 2009 (CEST)

Ich glaube deine Erklärung, das es bis zum letzen Vorkommen matched, ist das was mir dabei nicht passte. Ich brauchte wenn dann immer bis zum nächsten Zeichen der Art und nicht alle. Der Parser matched nicht bis zum letzten sondern nur bis zum ersten, wenn man es also nachbilden möchte, wäre natürlich jetztige Variante vorzusiehen. Dein look-ahead-Beispiel ist aber nicht umbedingt einfacher zu erkennen, als der aktuelle Regex, würde ich sagen. Ich musste den String aber auflösen, da auch in JavaScript ein String nur innerhalb einer Zeile sein darf. Daher konnte ich den RegEx wieder entmaskieren und eine wahrscheinlich üblichere Variante nutzen. --Der Umherirrende 19:57, 19. Jul. 2009 (CEST)

gudn tach!

wie ich bereits oben sagte, koennen slashes auch in ueberschriften vorkommen:

/^\s*(\/\*[^\/]*\*\/)?\s*$/ wuerde z.b. im beim string "/* dies/jenes */ " nicht matchen, da die negierte zeichenklasse sich von nur einem zeichen, dem slash, aus der bahn werfen laesst. deswegen sehe ich die assertion-variante als die zuverlaessigere an. -- seth 22:53, 19. Jul. 2009 (CEST)

Das stimmt, da habe ich nicht dran gedacht. Werde ich mir die nächsten Tage anschauen, wenn es keiner vorher macht. Der Umherirrende 19:00, 20. Jul. 2009 (CEST)

Ich habe mal einen Punkt gesetzt. Ich kann nur den RegEx von MediaWiki noch nicht nachvollziehen, warum dort nicht auf einen weiteres '*/' gemachted wird: Linker.php, function formatAutocomments. Aber ich denke, so sollte es reichen. --Der Umherirrende 20:13, 21. Jul. 2009 (CEST)

gudn tach!

wo meinst du? formatAutocomments? da wird mittels !(.*)/\*\s*(.*?)\s*\*/(.*)! recht aehnlich vorgegangen wie bei uns mit /^\s*(?:\/\*.*\*\/)?\s*$/; mit einem unterschied: durch den non-greedy quantifier *? wird dort das erste(!) vorkommnis von " */" gematcht. bei uns wuerde das aber so nicht funktionieren, da wir expliziter den string nach dem "*/" vorgeben. (iow: in unserem fall wuerde gelten: greedy=non-greedy. und deshalb machte ich ja den vorschlag mit der assertion.) -- seth 21:23, 21. Jul. 2009 (CEST)

Ich sollte doch besser gucken. Ich habe das Fragezeichen außerhalb der Klammern gesehen, daher passte es bei mir nicht. Die Assertion steht dir frei, ich bin da nicht so der Freund von. Ich hatte übrigens mit der Antwort auch einen Punkt im RegEx gesetzt. Der Umherirrende 21:29, 21. Jul. 2009 (CEST)

gudn tach!

jau, das mit dem punkt habe ich gesehen. ich habe ausserdem nun in dem obigen code-schnipsel auf non-capturing umgestellt.

die assertions finde ich hier zwar sehr angebracht, mir fehlt aber die zeit, um den ausdruck

/^\s*(?:\/\*(?:.(?! \*\/))*. \*\/)?\s*$/

zu testen. und blackboxtesten sollte man einen regulaeren ausdruck immer, nachdem man sich ihn ueberlegt hat. wie mnh schon sagte, sollte das mehrfache vorkommen von "*/" eigentlich keine relevante rolle spielen. -- seth 22:06, 21. Jul. 2009 (CEST)

Andere JavaScript-Lösung: Hervorhebung der Zusammenfassungszeile

Ich habe mir mal Gedanken zu den Kommenateren gemacht und mir gedacht, man könnte es ja auch versuchen, wenn man das Speichern weiterhin erlaubt, aber die Zusammenfassungszeile besser hervorhebt. Ich habe das Anfangsskript adaptiert. Bei rausgekommen ist: (mit IE7 - ohne Gewähr und ohne Support)

if ( wgNamespaceNumber == 0     /* ANR        */
  || wgNamespaceNumber == 6     /* Datei:     */
  || wgNamespaceNumber == 8     /* MediaWiki: */
  || wgNamespaceNumber == 10    /* Vorlage:   */
  || wgNamespaceNumber == 12    /* Hilfe:     */
  || wgNamespaceNumber == 14    /* Kategorie: */
   ) {
    var wpSummary = document.getElementById( 'wpSummary' );
    var wpSave    = document.getElementById( 'wpSave' );
    if( wpSummary && wpSave ) {
        var wpSaveTitle = wpSave.title;
        var wpSaveTitleDisabled = 'Bitte gebe in dem rot-hinterlegten Textfeld ein Bearbeitungskommentar ein.';
        var wpSummaryTitle      = 'Bitte gebe hier ein Bearbeitungskommentar ein.';
        var keyFunction = function () {
            var wpSave = document.getElementById( 'wpSave' );
            var wpSummary = document.getElementById( 'wpSummary' );
            if( wpSave && wpSummary ) {
                if( wpSummary.value.match( /^\s*(\/\*.*\*\/)?\s*$/ ) ) {
                    wpSave.title = wpSaveTitleDisabled;
                    wpSave.style.color = 'red';
                    wpSummary.title = wpSummaryTitle;
                    wpSummary.style.backgroundColor = '#FF6A6A';
                } else {
                    wpSave.title = wpSaveTitle;
                    wpSave.style.color = 'black';
                    wpSummary.title = '';
                    wpSummary.style.backgroundColor = 'white';
                }
            }
        };
        keyFunction();
        wpSummary.onkeydown  = keyFunction;
        wpSummary.onkeypress = keyFunction;
        wpSummary.onkeyup    = keyFunction;
    }
}

Den eigentlichen Vandalen ist es egal. Die Leute die aber ab und an mal hier sind, werden darauf (erstmalig?) aufmerksam und füllen sie aus.
Solange noch nichts in der Zusammenfassungszeile steht, ist sie rot hinterlegt. Der Text des Speicherbutton ist rot und das title-Attribut enthält einen Hinweis (den man als Tooltip angezeigt bekommt). Sofern man etwas einträgt, verschwindet das rot und alles wird wie es bis jetzt gewöhnt ist.
Ich weiß nicht, ob es überhaupt irgendeinen nennenswerten Effekt hat, da ich mich mit der Eingangskontrolle und den Verhalten von anderen Benutzern nicht so beschäftige. Der Umherirrende 23:23, 18. Jul. 2009 (CEST)

Das halte ich für die beste Lösung. --Church of emacs D B 13:43, 19. Jul. 2009 (CEST)

Kleinigkeit am Rande: Wie sieht das mit Rot/Grün-Sehschwäche aus, ist das kontrastreich genug? Viele Grüße, —mnh·∇· 14:04, 19. Jul. 2009 (CEST)

Sollte auf jeden Fall vorher ein Benutzer mit entsprechender Sehschwäche oder dieser Software ausprobieren --Church of emacs D B 17:14, 19. Jul. 2009 (CEST)

Die Software ist ein Java-Programm und leicht ausgeführt. Zum testen muss der obrigen Quelltext in folgendes Konstrukt eingefügt werden:

addOnloadHook(function() {
<!-- hier den Quelltext hinkopieren -->
});

Das ganze auf einer beliebige (nicht umbedingt vorhandende) Unterseite seines Benutzernamensraum, die mit .js endet kopieren und auf Vorschau klicken. Danach ist das Resultat nachvollziehbar. Das ganze muss nicht gespeichert werden. Der Umherirrende 19:47, 19. Jul. 2009 (CEST)

Sorry, so sah die Entscheidung des MBs keinesfalls aus. Wenn das auch nicht beabsichtigt war, kann davon das die standardmäßige Aktivierung von 'forceeditsummary' keinen Einfluss auf Vandalismus hatte keineswegs die Rede sein. Wenn es Möglichkeiten gibt 'forceeditsummary' auf den Hauptnamensraum zu beschränken, sind diese Willkommen. Mit einer farblichen Hervorhebung der Zusammenfassungszeile ist es aber nicht getan. Am Rande: Seit 'forceeditsummary' deaktiviert wurde, ist ein (vermutlich signifikanter) Anstieg der Vandalismusreverts zu beobachten: Datei:ParaDox - Diagramm - Artikel-Sichtungen und Artikel-Entwürfe - 2009-02.svg, der wohl stärker ausgefallen wäre, wenn gerade nicht fast überall Sommerferien wären. --Septembermorgen 17:27, 19. Jul. 2009 (CEST)

Dass der Kollateralschaden von forcesummary nicht nur konstruktive Bearbeitungen sondern auch ein paar destruktive verhindert, ist klar. Ziel von forcesummary war aber nie (auch nicht in dem MB) Vandalismus zu verhindern/erschweren, sondern die Verwendung der ZuQ zu erfordern und somit für eine bessere Nachvollziehbarkeit zu sorgen.
Nicht ganz unrecht hast du damit, dass das MB nicht genau mit dieser Lösung übereinstimmt. Dadurch stellt sich die Frage, ob wir ein neues Meinungsbild benötigen oder nicht. Meiner Ansicht nach bräuchten wir das nicht: Die hier vorgeschlagene Lösung ist ein vernünftiger Kompromiss, der die Vorteile von Forcesummary im Großteil enthält, nicht aber seine Nachteile. Da im Meinungsbild keine besonders große Mehrheit für forcesummary gestimmt hat (und diese Softwarefunktion inzwischen wahrscheinlich noch weniger Akzeptanz in der Community findet), glaube ich, dass dieser Kompromissvorschlag für alle Beteiligten akzeptabel ist. Falls ich damit falsch liege, muss man wohl den mühsamen Weg eines neuen Meinungsbildes wählen. --Church of emacs D B 19:16, 19. Jul. 2009 (CEST)

Die mögliche Umsetzung des Meinungsbildes ist an technischen Hürden gescheitert. Dies ist nur ein Versuch ein Kompromiss zu schaffen und etwas die Zusammenfassungszeile zu fördern. Man muss sich in diesem Fall etwas lösen, würde ich als Außenstehender sagen und sehe daher das Meinungsbild nicht verletzt, da es anders nicht Möglich ist. Die (technische) Möglichkeit 'forceeditsummary' für einzelne Namensräume ist gefordert, aber wann oder ob es umgesetzt wird, weiß keiner. Der Umherirrende 19:47, 19. Jul. 2009 (CEST)

Test beginnt: WP:FzW#Hervorhebung der Zusammenfassungszeile - JavaScript-Tester gesucht (der Quelltext dort ist der gleiche wie hier, nur fehlt die Namensraumabfrage. --Der Umherirrende 18:47, 5. Sep. 2009 (CEST)

Man sollte in der endgültigen Version noch eine Möglichkeit zur Abschaltung einbauen (z. B. eine Zeile in der eigenen skin.js). Damit kann man auch eventuelle Probleme mit Farbschwächen umgehen können und es soll ja auch Benutzer geben, die nicht die Standardfarbe für die Zusammenfassungszeile benutzen --Steef ³⁸⁹ 23:20, 5. Sep. 2009 (CEST)

Das lässt sich sicher noch einbauen (Namensvorschlag willkommen). Man kann es auch so einbauen, dass die vorherige Farbe wieder kommt, wenn man eine erlaubte Zusammenfassungszeile angegeben hat. Der Umherirrende 00:29, 6. Sep. 2009 (CEST)

Wie wärs mit highlight_summary? --Steef ³⁸⁹ 09:21, 6. Sep. 2009 (CEST)

Ja, soetwas in die richtig könnte man nehmen. Ich würde aber noch ein "no" einfügen, damit man auch erkennt, das es abgestellt wird. noSummaryHighlighting? Mein englisch ist nicht so gut. --Der Umherirrende 10:44, 6. Sep. 2009 (CEST)

Das könnte man auf MediaWiki:Onlyifediting.js einbauen. Dann wird es nur im Bearbeitungsfenster geladen, ich bin mir nur unschlüssig, ob sich das dann nicht zu sehr vermischt, da die Seite aktuell nur für die Edittoolbar zuständig ist, aber der Namen ist da irgendwie irre führend. Der Umherirrende 10:21, 12. Sep. 2009 (CEST)

Wann ist mit einer technischen Alternative zu rechnen?

Wann ist mit einer technischen Alternative, die sich auf den ANR beschränkt, zu rechnen? Meine Lust und die anderer RCler/Sichter die zahlreichen zusätzlichen unbequellten Änderungen zumindest auf Plausibiltät zu überprüfen hält sich nämlich in Grenzen. --Septembermorgen 23:29, 1. Aug. 2009 (CEST)

Und deswegen sollen die sinnvollen, zunächst vielleicht nicht einsichtig bequellten Änderungen verworfen werden? Grüße, —DerHexer (Disk., Bew.) 23:52, 1. Aug. 2009 (CEST)

Meine Frage war, wann mit einer technischen Alternative, die der Community-Entscheidung des MBs nicht widerspricht, zu rechnen ist? Wobei die Frage ist, ob nicht bequellte und ungeeignet bequellte Änderungen überhaupt sinnvoll sind. Man könnte zudem auf den Gedanken kommen, dass es der Community obliegt eine Community-Entscheidung wieder aufzuheben. --Septembermorgen 14:45, 2. Aug. 2009 (CEST)

Solange die technische Alternative nicht wieder sinnvolle, zunächst vielleicht nicht einsichtig bequellte Änderungen verwirft, kann sie gerne kommen; alles andere widerspricht den Grundsätzen, die uns die Foundation auferlegt (m:Founding principles, Punkt 2) – und da können wir noch so oft mit Meinungsbildern dagegen abstimmen. Vgl. hier. Nach meiner Auslegung der Policys sollten alle Änderungen ohne ausgefüllte Zusammenfassungszeile (zunächst nicht sichtbar; so wie im Missbrauchsfilter) gespeichert werden, dann überprüft, gegebenenfalls korrigiert und freigeschaltet werden. Ein Verlust von Versionen aufgrund technischer Spielereien widerspricht in allen Punkten dem Wiki- und Wikipediaprinzip; von Usability und Plausibilität für Neueinsteiger bei z. B. Evidenz mal ganz zu schweigen. Grüße, —DerHexer (Disk., Bew.) 15:18, 2. Aug. 2009 (CEST)

Ich wüsste nicht, dass aktiviertes 'forcesummary' eine Registrierung/Anmeldung erfordert. Und selbst wenn das MB gegen Grundprinzipien verstoßen würde, wäre hierbei nicht Deine persönliche Meinung ausschlaggebend dies festzustellen und noch weniger geeignet eine Community-Entscheidung auszuhebeln. --Septembermorgen 17:14, 2. Aug. 2009 (CEST)

Wir brauchen eine Lösung. Edits wie dieser häufen sich seit dem 13. Juli wieder (der Edit ist OK, aber mit einer halbwegs vernünftigen Zusammenfassung hätte ein Außenstehender das viel schneller verstanden). Ich bin sicher, Neulinge übersehen regelmäßig schlicht das Feld „Zusammenfassung und Quellen“ – und das Übersehen müssen wir so gut wire möglich verhindern. Machen wir das Feld eben optisch auffälliger, mit rotem Rahmen o. ä., wenn wirklich Bedenken über die Vereinbarkeit des ggf. zusätzlichen Klicks mit unseren Grundprinzipien bestehen. Ich würde es aber ebenso als Grundprinzip eines Wikis sehen, dass die Gründe für Änderungen eines Bearbeiters leicht für die anderen leicht nachvollziehbar sein sollen. Ich sag’s mal direkt: Wer nicht in der Lage ist, dem aus dem Zusammenfassungshinweis folgenden zusätzlichen Bearbeitungsschritt zu folgen, der ist auch nicht in der Lage, unsere Prinzipien wie WP:TF, WP:Q, WP:RK etc. zu verstehen. Ohne Grundwissen darüber kann man bei WP höchstens Tippfehler- und ähnliche Korrekturen betreiben, und wenn davon ein paar verloren gehen, können wir das IMHO wirklich verschmerzen. Das entgegen dem Meinungsbild jetzt wieder die Null-Lösung implementiert ist, ist jedenfalls IMHO nicht akzeptabel. --dealerofsalvation 05:27, 6. Aug. 2009 (CEST)

Als einer der aktiveren Sichter kann ich dem nur zustimmen. Oft bleibt nichts anderes übrig, als zu revertieren, weil die Änderung nicht nachvollziehbar ist. Meist betrifft dies Lebensdaten und andere Zahlenwerte. Da frage ich mich doch: Was ist näher am Wikiprinzip und vor allem weniger frustrierend für IP-Nutzer: Aufgefordert zu werden, eine Zusammenfassungszeile auszufüllen oder ihre Edits wieder revertiert zu sehen? --Stepro 06:59, 6. Aug. 2009 (CEST)

Ich vermute mal, dass die Mehrheit es als erwünscht ansieht, zweifelhafte inhaltliche Änderungen, die keine Quellenangabe haben, zu revertieren. Ich habe dieses Vorgehen jedenfalls von einigen Gegnern der Forcesummary als Abhilfevorschlag gehört. Was die Bedeutung von „zweifelhaft“ angeht, bin ich im Vergleich zu manchen anderen relativ großzügig im Sinne von WP:AGF, andere revertieren grundsätzlich jede inhaltliche Änderung ohne Quellenangabe. Trotzdem habe ich in den letzten 3 Wochen oft revertiert mit einem Hinweise wie „Änderung bitte begründen und ggf. belegen, z. B. im Feld Zusammenfassung und Quellen“. Und ich habe das Gefühl, das noch viel öfter machen zu müssen, aber irgendwann geht die Lust darauf verloren. Jedenfalls, wenn jetzt einer auf einen zusammenfassungslosen Edit nach einer Woche einen Revert bekommt, und eine Woche ist schon recht optimistisch, dann ist das doch für alle Beteiligten viel schlechter, als wenn er unmittelbar auf seinen Edit hin von der Software einen entsprechenden Hinweis bekommt. Im letzteren Fall wird er eher Einsehen zeigen und weiter mitmachen – in ersterem Fall, wenn er nach einer Woche nochmal reinschaut, eher sich frustriert von unserem Projekt abwenden. Bitte, wir haben von der Benutzeroberfläche gesehen eine der einfachsten Webseiten zum Mitmachen, die es gibt, aber mit den wahrscheinlich einem der kompliziertesten inhaltlichen Regelwerke. Das kann man doch mal von beiden Richtungen her in ein besseres Verhältnis bringen. Wir können von Leuten, die in einer Enzyklopädie mitmachen wollen, verlangen, in einem Web-Formular zwei Felder auszufüllen. Bitte hier mal pragmatisch denken, auch pragmatisches Denken kann die Verwirklichung unserer Grundsätze voranbringen. Verschärfend dazu, dass die Forcesummary ausgeschaltet ist, kommt übrigens, dass aus dem Hinweis unterhalb des Edit-Feldes der lange Zeit vorhandene Hinweis „Bitte gib deine Quellen an“ entfernt wurde, mit der Begründung, es gäbe ja Forcesummary. Das Thema werde ich an geeigneter Stelle voranbringen, wenn die Forcesummary hier nicht weiter kommt. --dealerofsalvation 07:34, 6. Aug. 2009 (CEST)

Full ack. Auch ich winke oft mit einer Überdosis AGF Dinge durch, von denen ich keine Ahnung habe ob sie stimmen oder nicht. Vor allem Fußballergebnisse und solche Dinge werden massenweise von IPs ohne jeden Kommentar eingetragen. Selbst Änderungen an exzellenten Artikeln hatte ich gestern, die seit 3 Wochen (!) ungesichtet waren. Diese dürften genug Nutzer auf der Beo haben, aber offensichtlich konnte oder wollte keiner Einschätzen, ob die Änderung richtig ist oder nicht. Konsequenz: Nach 3 Wochen immer noch ungesichtet. Das kann doch wirklich nicht der Sinn des Projekts sein. Welcher Nutzer ohne Sichtungsrecht bekommt denn nach 3 Wochen überhaupt noch mit, dass seine Eintragung revertiert wurde? Wenn in der Zus.zeile irgendeine Angabe steht, kann man eher davon ausgehen, dass der Editor sich seine Angaben nicht ausgedacht hat. Wenn diese leer ist, kann man die ernsthaften Absichten leider nicht von den doch recht oft vorkommendenen Kindereien unterscheiden, die mal eben aus Spaß das Geburtsjahr ändern. Eine baldige Lösung ist dringend notwendig, sonst bleiben die Änderungen demnächst noch länger ungesichtet. Und wenn nach einem Monat die Änderung einer IP immer noch nicht im Artikel zu sehen ist, dürfte wohl erst Recht Frust aufkommen. --Stepro 19:29, 6. Aug. 2009 (CEST)

Der jetztige Zustand ist allenthalben eine Verschlechterung, weil sehr viel mehr Zeit aufgebracht werden muss, die beleglosen Änderungen nachzurecherchieren als Änderungen anhand, selbst ungenau angegebenen Belegen, auf Richtigkeit nachzuprüfen. Dieser Aufwand kann aber in der RC nicht im notwendigen Umfang geleistet werde, weshalb unbelegte und nicht einfach zu prüfende Änderungen einfach zurückgesetzt werden. Dass jeglicher Hinweis auf Belegpflicht rausgekickt wurde, ist schon eine mittlere Katastrophe. Selbst mit dem kritisierten Forcesummary hätte man die Benutzerführung so verbessern können, dass (fast) keine sinnvollen Änderungen (und ich zähle hier nur jene Änderungen dazu, die belegt sind) verloren gehen. Es hätte ausgereicht, wenn man zusätzlich zu Forcesummary nach Abspeicherungsversuch mit nicht ausgefüllter Z&Q einen deutlichen Hinweis auf Z&Q beim Öffnen des Bearbeitungsfensters gesetzt hätte und Forcesummary erst dann abzuschalten, wenn eine bessere Alternative zur Verfügung steht. Vielleicht melden sich ja mal diejenigen zu Wort, die meinten sie müssten eine Community-Entscheidung ohne weitere Diskussion übergehen. --Septembermorgen 10:27, 9. Aug. 2009 (CEST)

Die MediaWiki-Vorlagen kann man ja ändern, das ist ja nicht das Problem. Wie die forcesummary rausgenommen wurde, war linkisch, das ist wohl war. Dennoch war es nötig, sie in dieser Funktionalität und mit diesen Folgen herauszunehmen und zu verbessern.

„Ohne Grundwissen darüber kann man bei WP höchstens Tippfehler- und ähnliche Korrekturen betreiben, und wenn davon ein paar verloren gehen, können wir das IMHO wirklich verschmerzen.“ stimmt mich sehr betrübt. Wo ist das Wikiprinzip hin, wo das Projekt, in dem jeder Benutzer annähernd gleichberechtigt ohne technische Verkomplizierungen mitarbeiten konnte? Das gleiche gilt schon für die Sichtungen, die hier als Argument angeführt werden. Auch diese schränken die Mitarbeit im Projekt ein, mit dem kleinen, aber in der Konsequenz großen Unterschied, dass dabei keine Änderungen verloren gehen. Sie werden aufgeschoben. Was hier während der Aktivierung der forcesummary passiert ist, waren Verluste von tausenden Bearbeitungen; unter diesen tausenden Bearbeitungen waren nicht Vandalismen, sondern eben auch diese wichtigen Tippfehlerkorrekturen oder aber andere noch substantiellere Änderungen.

Damit hat sich die Prämisse des damaligen Meinungsbildes drastisch verschoben: Diese war damals, zum Wohle des Projektes Mitarbeiter zu motivieren, treffende Zusammenfassungen zu formulieren (und dies kann keine Software erzwingen: „Fick dich du Opfer, aendere jetzt die scheisse oder ich ficke deine Mutter“ und weitere Beispiele; was bringt dabei eine Zusammenfassungserzwingung? weiß man nun mehr, ob diese Änderung vernünftig ist?); nach der Einschaltung waren aber hunderte Verluste von sinnvollen Änderungen gegen das Interesse des Projektes zu verzeichnen – dies ist objektiv belegt.

Ich unterschreibe wie ihr, dass es sehr hilfreich ist, wenn eine vernünftige Zusammenfassung die Änderung begründet und dass softwareseitig nur möglich ist zu speichern, wenn eine (vernünftige) Zusammenfassung angegeben ist. Wie das nun zu verwirklichen sei, darüber denke ich seit Monaten nach – auch über ein Gegenmeinungsbild, was eben die Ergebnisse aus der Aktivität der forcesummary verwertet. Wieso tausende Bearbeitungen täglich nun nicht gespeichert wurden, weiß ich nicht; Ursachen sehe ich a) in technischer Überforderung (nicht jeder ist mit dem Internet groß geworden oder hat sich in dieses so intensiv eingearbeitet, kann aber dennoch unser Projekt voranbringen), b) in Unkenntnis eines Vorschauzwanges nach acht Jahren ohne diesen bei gleichzeitig unzureichenden Hinweisen darauf, c) dass diese Hinweise erst nach dem (versuchten) Speichern gegeben werden – wie oft habe ich schon direkt nach dem Klick das Tab geschlossen [nur weiß ich halt, dass ich für mich die forcesummary angeschaltet habe – heißt nicht, dass mir jedesmal das Passende zum Eintragen einfällt bzw. jede Änderung begründet werden muss (Evidenz)] – dies kann man durch oben genannte Lösung realisieren, indem das Speicherfeld erst aktiviert wird, wenn eine Zusammenfassung drin steht (eine sehr gute Lösung, meiner Meinung nach; würde sicherlich auch bei b) helfen) …

Insofern bin ich bestrebt, eine Zusammenfassungsaufforderung so eingeführt zu sehen, dass weder sinnvolle Änderungen verloren gehen noch Benutzer durch technischen Regelverdruss vergrault werden. Letzteres ist auch bei den Sichtungen zu beobachten, die uns zwar ein Überprüfen aller Änderungen ermöglichen, allerdings zu einem gewaltigen Zeitaufwand. So ist es sicherlich richtig, dass eine vernünftige Zusammenfassung den Aufwand reduzieren kann.

Einer Zusammenfassung zu vertrauen, reicht aber nicht aus, der Änderung zu vertrauen, da muss man eben den Inhalt der Änderungen üerprüfen – und wenn dies eben wochenlang keiner macht, dann stauen sich die Sichtungen, denn so war es bei der Einführung dieser gewünscht, die Änderung bleibt aber in der Versionsgeschichte und kann selbst bei Revertieren immer wieder wiederhergestellt werden. Wenn Zusammenfassung und Inhalt im Einklang stehen und nicht erfunden sind, ist dies von zeitlichem Vorteil für die Kontrolle, dennoch muss diese durch uns durchgeführt werden. Und wieso dann Benutzer, auch angemeldete, bevormundet werden sollen, versteh ich einfach nicht: Denkvorgänge (hier zur Schaffung von Einklang und Änderung) lassen sich weder durch Zwang noch durch Technik gut erzwingen.

Ich denke, die Nachteile durch diese Form der forcesummary sind deutlich umrissen worden, um das Meinungsbild zu erfüllen, sollte so schnell wie möglich eine Zusammenfassungsaufforderung so gestaltet werden, dass weniger (bis keine) Änderungen dadurch verloren gehen (auch wenn dadurch mehr zu sichten sei – dies ist aber ein Problem der Sichterei und nicht der forcesummary), also alle sinnvollen Änderungen so abgespeichert werden, dass sie wiederherstellbar sind (sei es durch einen Missbrauchsfilter [man könnte ja [2] durchgehen und die sinnvollen Änderungen wieder einfügen], sei es durch eine Funktion der Developer, sei es notfalls jetzt durch eine JavaScripthelfslösung).

Meine Meinung diesbezüglich muss man natürlich nicht teilen, sie erfüllt aber die Wünsche des Meinungsbildes (mehr Zusammenfassungen für ein besseres Beurteilen der Änderungen) bei gleichzeitigem Reduzieren der Nachteile (Verlust von Änderungen); in welcher Ausführung auch immer: eine Zusammenfassungsaufforderung wird uns nicht abnehmen, jede Änderung kritisch zu prüfen. Grüße, —DerHexer (Disk., Bew.) 11:36, 9. Aug. 2009 (CEST)

Ich quotemardere mal: „treffende Zusammenfassungen zu formulieren […] kann keine Software erzwingen […] Wie das nun zu verwirklichen sei, darüber denke ich seit Monaten nach“––Wie Du im Endeffekt schon selbst sagst: Gar nicht. Es ist ein soziales Problem, kein technisches. Selbst erfahrene Autoren benutzen oft die Zusammenfassung nicht, obwohl sie sicherlich nicht unwissend sind. Sie wollen eben nicht. Zwang bewirkt da höchstens Trotzreaktionen, dann gibt's halt lauter ZuQs wie „asdf“. Mir ist übrigens schleierhaft, wo der Glaube an ZuQ als arbeitssparendes Allheilmittel herkommt, bin ich eigentlich der Einzige, der durchaus schon falsche Quellen darin gefunden hat?

Was den technischen Teil des „wie“ angeht, gibt es mehrere Möglichkeiten: einfache Musteranalysen (z.B. Regexps, vulgo: „entspricht diese summary einem positiv/negativ-Muster?“), statistische Verfahren (etwa Di- und Trigraphhäufigkeitsverteilung der summary ermitteln, falls zu weit von Normalverteilung der Biester entfernt => reject) oder Wörterbuchverfahren (zu viele Wörter, die nicht in üblichen Zusammenfassungen vorkommen => reject). Kann man natürlich auch kombinieren. Ich bezweifele angesichts der zumeist extrem kleinen Textschnipsel (etwa „t“ oder „k“ sind ja durchaus valide) mit breiter Streuung, dass man damit auch nur halbwegs brauchbare Trefferquoten hinbekommt – ich fänd es sogar ehrlich interessant, ob randomisiertes „Deine ZuQ nehm ich heut nicht“ mit per Daumen geschätztem 0.15 ≤ P(reject) ≤ 0.3 nicht signifikant besser träfe. Für eine Meldeheuristik mag sowas ausreichen, da kann man mit vielen false positives leben, für automatisches Ablehnen jedoch meines Erachtens nicht.

Kurz: Vergiss es. Viel Aufwand sowas auszuknobeln, wenig Nutzen. Zusammenfassungen der Länge 0 ablehnen ist wenigstens kaum Aufwand, aber blind auf „Sichten“ hämmern is' damit auch nich'. Viele Grüße, —mnh·∇· 12:56, 9. Aug. 2009 (CEST)

P.S.: Wär nett, wenn Du hier und da mal einen Absatz machen würdest, solche großen, zusammenhängenden Textklötze sind am Bildschirm nicht prickelnd zu lesen.

Absätze gemacht. Zur Problematik … hmm, klingt überzeugend. Grüße, —DerHexer (Disk., Bew.) 13:05, 9. Aug. 2009 (CEST)

Hinweis

Da das Ganze nun schon wieder eingeschlafen zu sein scheint und ich nicht gewillt bin, das Aussitzen des Problems hinzunehmen, hier ein kleiner Hinweis: Wenn bis Ende des Monats nicht eine geeignete Alternativtechnik (JavaScript) aktiviert wurde, bin ich dann auch mal mutig und werde auf bugzilla die Wiedereinschaltung von forceeditsummary gemäß gültigem Community-Beschluss beantragen. Die Wiederabschaltung des Features ohne gleichzeitiger Einrichtung einer Alternative widerspricht dem geäußertem Communitywillen und ist ein klarer Regelverstoß. Wie man darauf abstellen kann, dass sich der deutlich ausgedrückte Wille der Community in nicht mal einem halben Jahr plötzlich ins Gegenteil verkehrt haben soll, ist mir schleierhaft. --Stepro 08:33, 21. Aug. 2009 (CEST)

Man könnte auch einfach das Sichten einstellen oder einen Sichterstreik veranlassen. ;-) Ich unterstütze den letzten Beitrag. -- Geitost 10:48, 21. Aug. 2009 (CEST)

Ich freue mich über die Unterstützung, möchte aber bitten von Streikaktionen abzusehen. :-) Wir wollen doch eine qualitativ hochwertige Enzyklopädie erstellen (zumindest ich), da müssen wir eben dazu auch die beschlossenen Instrumente einfordern. --Stepro 11:51, 21. Aug. 2009 (CEST)

Vielleicht reicht es ja auch schon, das Wort erwähnt zu haben, damit sich da mal was bewegt. ;-) -- Geitost 12:05, 21. Aug. 2009 (CEST)

Ich werde dann auf Bugzilla argumentieren, dass 131:58 wohl kaum als Community consensus zu verkaufen ist. —Complex 10:52, 21. Aug. 2009 (CEST)

Das verstehe ich nicht. 69% sollen keinen consensus darstellen? --Stepro 11:51, 21. Aug. 2009 (CEST)

Wenn man die 48 meist heftige Ablehnungen der Geschichte (Gründe lesen!) noch dazurechnet, genau. —Complex 12:29, 21. Aug. 2009 (CEST)

Habe Church of Emacs, der die Abschaltung veranlasst hat[3], um eine Stellungnahme an dieser Stelle gebeten. Dass derzeit keinerlei Alternative aktiv ist, davon habe ich mich gerade unter IP überzeugt. Gruß --dealerofsalvation 11:40, 21. Aug. 2009 (CEST)

Mir fällt gerade auf, dass man dieselbe Begründung der nicht gespeicherten Hunderten/Tausenden Bearbeitungen sicherlich auch auf den Bearbeitungskonflikt anwenden kann, denn dann wird ja die Änderung auch nicht gespeichert. Sollen wir dann also auch diese Nichtänderung abschaffen? Alleine aus dem Grund müsste man auch als neuer Bearbeiter schnell dazu kommen, die Abspeicherung der gemachten Änderungen anschließend zu prüfen. Gerade bei neuen Benutzern gehe ich davon aus, dass diese wissen wollen, ob sie ihre Änderung auch anschließend sehen können. Deshalb wird dann auch eine solche Meldung, dass nicht abgespeichert wurde, gesehen. Vielleicht könnte man ja alternativ auch die forcierte Zusammenfassung für die ersten 100 Änderungen neuer Benutzer und IPs einführen. Möglicherweise gibt es dort weniger verloren gegangene Änderungen, weil diese noch nicht so vertraut mit der Software sind und genauer hinsehen, was mit ihren Änderungen passiert. -- Geitost 12:05, 21. Aug. 2009 (CEST)

IPs und neue Benutzer sehen ihre Änderungen doch so oder so nicht: WP:GV. Und bei einem Zahlenkriterium müssten dynamische IPs eingerechnet werden (was wohl nur schwer ginge). Des Weiteren glaube ich nicht, dass es so viele Bearbeitungskonflikte pro Tag gibt (natürlich nur eine Vermutung; eruieren kann man das wohl aber nur schwer). Grüße, —DerHexer (Disk., Bew.) 12:33, 21. Aug. 2009 (CEST)

Direkt nach dem Edit wird IPs und neuen Benutzern die ungesichtete, d. h. ihre, Version angezeigt. Die gesichtete Version sehen sie nur, wenn sie den Artikel über einen Link oder die Suche aufrufen. Auch dann gibt es einen Link auf die ungesichtete Version. --dealerofsalvation 12:55, 21. Aug. 2009 (CEST)

Umreißen des derzeitigen Problems

Ich zitiere mal:
Standardversion momentan beim Abspeichern:

• Über der Zusammenfassungszeile steht fett und groß:
  • „Das Kopieren urheberrechtlich geschützter Werke ist verboten!“ Daneben dann genauere Infos dazu und der Hinweis, dass man mit dem Speichern der Seite versichert, den Beitrag selbst verfasst zu haben usw.
• Unter der Zusammenfassungszeile sowie den Knöpfen zum Abspeichern steht noch:
  • „Wenn du nicht möchtest, dass dein Text weiterbearbeitet und weiterverbreitet wird, dann speichere ihn nicht. Falls du den Text nicht selbst verfasst hast, muss er unter den Nutzungsbedingungen verfügbar sein und du stimmst zu, notwendigen Lizenzanforderungen zu folgen.“

So weit mal zu dem, worauf hingewiesen wird. Ich kann dort nirgends den Hinweis auf WP:Q finden und auch nirgends den Hinweis, dass Änderungen in irgendeiner Weise nachvollziehbar beziehungsweise bequellt sein sollten. Das bedeutet, dass die neuen Benutzer/IPs davon ausgehen dürften, dass ihre sinnvollen (unbequellten) Änderungen im Projekt bestehen bleiben und dass sie frustriert sein werden, wenn einfach revertiert wird (wobei es oft vorkommt, dass vergessen wird, beim Revertieren auf WP:Q hinzuweisen. Dann ist für die Benutzer nicht mal ersichtlich, nach welchen Kriterien revertiert wurde.
Es steht neben (unter/über/sonstwo) der Zusammenfassungzeile nirgends der Hinweis, dass man damit rechnen muss, dass unbelegte(, sinnvolle) Änderungen revertiert werden, was aber der Fall ist und auch sein soll laut den Richtlinien, dass man belegen soll, die aber so gut wie kein Newbie erst mal kennt. Es steht z.B. nirgends eine Art Warnhinweis, dass man mit Frust rechnen muss, wenn man zum Projekt beitragen will. ;-) Auch dies ist aber der Fall im derzeitigen Zustand.

• Fazit 1: Ich denke, alles andere ist besser als der derzeitige Zustand.
• Fazit 2: Sichten ist mit einem enormen Aufwand verbunden, was zu hohen Sichtungslags führt – einerseits, weil die aktiven Sichter mit mehr Aufwand weniger gesichtet bekommen, andererseits, weil weniger Leute Lust auf solcherlei Aufwand haben (verbunden mit Anschissen wg. Sichtungen oder Revertierungen mangelhaft bequellter Änderungen).

So, ich habe die forcierte Zusammenfassung aktiviert und bekomme nun (für alle ohne forcierte Zusammenfassung, damit alle wissen, worüber wir reden):

1. rot umrandetes Feld Zusammenfassung
2. oben über dem Bearbeitungsfeld den Text:
   

„Achtung: Deine Änderung wurde noch nicht gespeichert!
Wikipedia-Artikel sollen nur überprüfbare Informationen aus zuverlässigen Quellen enthalten. Damit wir deine Änderung überprüfen und nachvollziehen können, bitten wir dich: Klicke hier, gib deine Begründung und wenn nötig Belege für die Änderung ein und klicke dann erneut auf ‚Seite speichern‘.“

Frage: Warum wird das Feld Zusammenfassung nicht standardmäßig vor dem Speichern rot umrandet und warum findet sich der Text unter 2. (ohne den roten Einleitungstext) mit dem Hinweis auf WP:Q nicht standardmäßig in der Nähe der Speicherknöpfe? Das wäre wohl das Minimum.

Ich habe mir schon sehr häufig beim Sichten Änderungen angesehen, die ich nicht nachvollziehen konnte und deshalb nicht gesichtet habe. Dadurch bleiben diese dann weiter im Pool der nicht gesichteten, 3 Wochen alten Versionen. Wie viele Sichter sich diese nun ansehen, feststellen, dass sie nicht nachrecherchieren, nicht durchwinken und nicht revertieren wollen, bis sich ein Sichter findet, der irgendwas damit macht, mag ich mir gar nicht auszumalen. Das bedeutet, dass etliche Leute mit derselben unbelegten Änderung zu tun haben. Hat natürlich

1. mit dem Aufwand zu tun,
2. mit Unkenntnis des betreffenden (Fach-)Gebietes und
3. mit der Situation, dass unklar ist, ob man nen Anschiss wg. Durchwinken oder wg. Revertieren der unbelegten Änderung bekommt. :-/

Man könnte auch ne Markierung einführen für Sichter, die anzeigt, wie viele Sichter die Version bereits angesehen haben, ohne eine Sichtermarkierung setzen zu wollen (ohne Namen derjenigen Sichter). Dann bräuchte man sich so was ohne Fachkenntnis gar nicht mehr anzusehen. ;-) Bzw. hätte man dann mal eine bessere Vorstellung des Aufwands, der hier betrieben wird für nur eine unbelegte Änderung und auch im Vergleich zu anderen nicht gut nachvollziehbaren Änderungen. Nur mal so ne Idee zur Transparenz dessen, was wir hier machen. Daraus könnte man dann weitere Handlungsvorschläge erarbeiten. -- Geitost 12:06, 21. Aug. 2009 (CEST)

Übergangslösung

Church of emacs meint, dass er sich nach der Wikimania um die Alternative kümmern will[4]. Ich schlage als kurzfristige und ausdrückliche Übergangslösung vor, in MediaWiki:Wikimedia-copyrightwarning oder MediaWiki:Wikimedia-editpage-tos-summary den Hinweis „Bitte gib deine Quellen an“ einzufügen, wie er von mindestens 2005 bis 30. März 2009 an ersterer Stelle stand. Bitte um Diskussion. --dealerofsalvation 05:45, 24. Aug. 2009 (CEST)

 Pro Noch besser fände ich es, stünde dort irgendwo ein ähnlicher Text wie dieser:

• Wikipedia-Artikel sollen nur überprüfbare Informationen aus zuverlässigen Quellen enthalten. Damit wir deine Änderung überprüfen und nachvollziehen können, bitten wir dich: Gib deine Begründung und möglichst deine Quellen für die Änderung ein.

Abgewandelter, gekürzter Text der forcierten Zusammenfassung nach dem Speicherversuch (siehe einen Abschnitt weiter oben unterhalb des roten Textes). Wie auch immer, irgendwas in der Art mit Link zum Weiterlesen sollte auf jeden Fall dorthin. Ich bin eher dafür, diesen Hinweis beim unteren Text Wikimedia-editpage-tos-summary anzufügen, weil er beim Copyright nicht so gut passt und eher untergehen würde und der zweite Text auch bislang noch recht kurz und übersichtlich ist. Es sollte ein eigener Absatz dafür eingefügt werden, damit es übersichtlich bleibt.

Vielleicht könnte man auch zusätzlich Zusammenfassung noch ändern in Zusammenfassung und Quellen, der verlinkte Text heißt ja auch so (Hilfe:Zusammenfassung und Quellen). -- Geitost 11:02, 24. Aug. 2009 (CEST)

Von mir aus gerne ausführlicher, aber ich weiß nicht, ob es dafür Konsens gäbe. Ich habe schon die Meinung gelesen, dieser Lizenz-Hinweis sei so wichtig, dass da besser kein Hinweis auf so etwas wie Quellen davon ablenken solle, Edits ohne Quellenangabe könne man schließlich revertieren.

Ich würde ja bevorzugen, den Quellenhinweis in den oberen Text (Wikimedia-copyrightwarning) einzubauen. Ein Blick auf en, fr, es, it und nl zeigt: 3 dieser WPs haben einen Quellenhinweis im oberen Text, eine im unteren. Außerdem, je früher man den Quellenhinweis sieht, desto besser – hat man erstmal seinen Beitrag geschrieben und erst dann geht einem das mit der Quellenpflicht auf, ist man frustriert.

„Zusammenfassung“ - damit meinst du MediaWiki:Summary: dies ist dynamisch, das zeigt bei Edits im Artikelnamensraum den Text „Zusammenfassung und Quellen“, bei allen anderen Namensräumen, eben auch dieser Diskussion, nur „Zusammenfassung“. Gruß --dealerofsalvation 18:59, 24. Aug. 2009 (CEST)

Ich habe es jetzt über MediaWiki:Wikimedia-copyrightwarning umgesetzt. --dealerofsalvation 05:31, 25. Aug. 2009 (CEST)

Das sieht als Übergangslösung gut aus. --Septembermorgen 13:18, 25. Aug. 2009 (CEST)

Find ich auch gut so. :-) Mal sehen, was das so ausmacht bei den Sichtungen... -- Geitost 21:32, 25. Aug. 2009 (CEST)

Auswertung der Rotumrandung

Ist es möglich den Anteil ausgefüllter ZuQ-Zeilen nach Einführung der Rotumrandung im Vergleich zum jetztigen Zustand zu ermitteln? D.h. es sollte (falls möglich) der Anteil ausgefüllter ZuQ im ANR vor Einführung der Rotumrandung über einen genügend langen Zeitraum ermittelt werden, um später den Nutzen der Umstellung beurteilen zu können. --Septembermorgen 18:52, 22. Sep. 2009 (CEST)

Per API ist es möglich die Letzten Änderungen auszuwerten: API-Abfrage. Alternativ kann die Datenbank des Toolservers genutzt werden (bin mir nicht ganz sicher, ob die Daten dort sind). Jeweils sind nur 30 Tage rückwirkend möglich. Der Umherirrende 21:27, 22. Sep. 2009 (CEST)

Stand der Dinge

Ich kopiere meine Anfrage von WP:FzW: Wikipedia:Fragen zur Wikipedia/Archiv/2012/Woche 11#Zusammenfassungszeile erzwingen. Vielleicht liest hier ja noch jemand mit und kann etwas zum aktuellen Stand der Dinge sagen:

Im Wikipedia:Meinungsbilder/Hinweis auf Notwendigkeit der Angabe von Zusammenfassung und Quellen wurde Anfang 2009 mit deuticher Mehrheit die standardmäßige Aktivierung der Benutzereinstellung „Warnen, wenn beim Speichern die Zusammenfassung fehlt“ für alle Benutzer beschlossen. Per bugzilla:17453 wurde diese im März 2009 dann auch aktiviert, im Juli desselben Jahres dann aber per bugzilla:19208 wegen "conflicts with extensions, such as ConfirmEdit (Captcha)" und der fehlenden Möglichkeit, das auf den Artikel-Namensraum einzugrenzen wieder deaktiviert und durch den AbuseFilter 10 ersetzt. Dieser wiederrum wurde im Juli 2011 automatisch(?) deaktiviert, weil er bei mehr als 5 % der Bearbeitungen ausschlug (wobei er wohl auch schon zuvor nur das Logbuch befüllte und dem Benutzer eben keinen Hinweis lieferte, so ganz sicher bin ich mir da nicht). Seither ist es wieder jedem möglich, Artikel ohne Eingabe einer Zusammenfassungszeile zu bearbeiten und beim Abspeichern darauf noch nichteinmal einen Hinweis zu bekommen. Wie ist da der technische Stand? Ist die ursprünglich verwendete Benutzereinstellung (wieder?) brauchbar (das bezieht sich vor allem auf das Zusammenspiel mit bei uns verwendeten Extensions; die Begrenzung auf den Artikel-Namensraum ist zwar sinnvoll, aber im Meinungsbild nicht verlangt)? Kann der Abuse-Filter (evt. modifiziert und z.B. aufgespaltet in eine Version für IPs und eine für angemeldete Benutzer, o.ä.) wieder scharfgeschaltet werden? Könnten die angemeldeten Benutzer (die ja z.B. keine Captchas eingeben müssen) die Benutzereinstellung kriegen und nur die IPs per Abuse-Filter abgefangen werden? Gibt es andere Lösungsansätze? --YMS (Diskussion) 14:19, 14. Mär. 2012 (CET) --YMS (Diskussion) 15:14, 19. Mär. 2012 (CET)

Archivierungsanfrage

{{Ping|DerHexer|Benutzer:Church of emacs|Benutzer:Schniggendiller|Benutzer:Umherirrender}}

• Da ich mich gerade frage wie aktuell diese Seite ist und was sie überhaupt darstellt eine Richtlinie wohl eher nicht, denn es gibt ja gar keine generelle „erzwungene Zusammenfassung“ es sei denn man möchte das so.
• Meine Frage lautet daher: Was soll mit dieser Seite geschehen, kann das ins Archiv?
• Wenn ich das richtig sehe, gibt es eine offizielle technische Hilfe (Hilfe:Zusammenfassung und Quellen) zur Nutzung der Zusammenfassungszeile, und mich würde, wenn ich denn diese Seite je zuvor bewusst gesehen oder aufgerufen hätte, diese Gegensätzlichkeit der Aussagen doch verwirren. Mal ehrlich die Informationen auf der Seite sind fast sechs Jahre alt, die Anfrage aus dem Jahr 2012 wurde nicht einmal mehr hier beantwortet.
• Hilfreich finde ich so etwas wirklich nicht, daher würde ich mir eine Verschiebung heraus aus der oberen Ebene des WPNR doch sehr wünschen. 27 Abrufe in drei Monaten
• Eine andere Möglichkeit wäre es natürlich die Diskussion wieder aufzunehmen aber … wer möchte das schon. Auch wenn ich das, für mich persönlich, wirklich absolut sinnvoll finde.
• Dazu gehören wohl auch → Wikipedia:Bearbeitungsfilter/10→Wikipedia:Technik/Baustellen/Warnung wenn Zusammenfassung fehlt

Ist mir nur gerade so aufgefallen und da wollte ich mal anfragen was ihr da so meint. Als Nebeneffekt würde der Shortcut EZ für irgendeine spätere Nutzung frei werden. --Liebe Grüße, Lómelinde Diskussion 18:57, 25. Jul. 2015 (CEST)

Dein Ping hat nicht funktioniert. Das Thema scheint eingeschlafen zu sein und auch nicht mehr weiter verfolgt zu werden. Dies war mal als Diskussions- und Sammelseite zu einem speziellen Thema gewesen um die Diskussionen zu bündeln und damit sie nicht immer wieder neu auf WP:FzW oder anderen Seiten aufflammen. So ein vorgehen halte ich immer noch für sinnvoll, damit man die Diskussion zum Thema zentralisiert, leider schläft eine Seite meistens dann auch ein oder wird direkt als Regel oder Gesetz angesehen. Wenn es dich stört, schieb es weg. Aus meiner Sicht ist das nur ABM. Der Umherirrende 19:12, 25. Jul. 2015 (CEST)

Danke für deine Einschätzung. Ich frage lieber die anderen auch noch einmal. @DerHexer, Church of emacs, Schniggendiller: Oups ja, die Vorlage war wohl falsch ausgefüllt. Mir geht es ja auch darum was dann mit dem Shortcut geschehen soll. Daher frage ich zusätzlich mal noch PerfektesChaos was er meint. Alternativ könnte man auch einen dicken Baustein setzen, der kennzeichnet, dass diese Seite keine Richtlinie darstellt. Warum ABM, wer hat denn dadurch Arbeit? Ich passe das dann schon selbst an, aber „ohne Nachfrage“ darf ich nichts mehr verschieben. Wie man es macht scheint es doch immer falsch zu sein. --Liebe Grüße, Lómelinde Diskussion 07:04, 26. Jul. 2015 (CEST)

Geht das mit dem Archivierungswahn schon wieder los?

Wenn du dir schon deine Claqueure zusammenrufst, dann sollten aber auch ein paar andere hier nicht fehlen. Ich denke da so beispielsweise an Benutzer:Itti, Benutzer:Henriette Fiebig, Benutzer:Geolina163, Benutzer:Matthiasb und die anderen. --185.40.134.3 07:38, 26. Jul. 2015 (CEST)

Diese Seite wird ein Versuch gewesen sein, er ist wie der Umherirrende schreibt, eingeschlafen. Das mit dem Archiv jedoch, war meines Wissens reichlich auf äußerst unangenehme Weise durchgekaut und eigentlich erledigt. Anscheinend jedoch nicht. Ja @Lómelinde: danke, dass du auch meine Meinung hören möchtest, das Archiv ist ein Ort wo nichts mehr wiedergefunden wird. Um diese Seite wäre es prinzipiell nicht wirklich schade, jedoch sehe ich überhaupt keine Notwendigkeit Seiten in ein Archiv zu verschieben. Benötigt es einen Hinweis, dass die Seite nicht aktuell ist? Ich denke eher nicht, das sieht eh jeder, der lesen kann. Doch wenn es glücklich macht. --Itti 10:43, 26. Jul. 2015 (CEST)

Nein deine Meinung dazu kenne ich und ich habe bewusst nur die Leute angesprochen die diese Seite bearbeitet haben. Ich möchte deine Meinung ganz sicher nicht tausendmal wiederholt vorgekaut bekommen und sie ist auch „nicht allgemeingültig“ und daher für mich auch nicht weiter relevant. Ich möchte nur und ausschließlich Antworten von den Benutzern die ich um eine Antwort gebeten habe, auf Provokationen durch meinen IP-Stalker reagiere ich nicht. Ich bitte daher um Verständnis, dass ich diese Diskussion auch nicht nochmals mit dir führen werde. --Liebe Grüße, Lómelinde Diskussion 10:54, 26. Jul. 2015 (CEST)

Das ist mir jedoch herzlich egal, denn auch ich darf hier in diesem Projekt eine Meinung haben. Das Wort werde ich mir von dir sicher nicht verbieten lassen. --Itti 11:00, 26. Jul. 2015 (CEST)

• Die Angelegenheit ist nicht abgeschlossen; somit grundsätzlich nicht archivierungsfähig.
  • Die Fragestellung taucht alle Jahre wieder mal irgendwo auf.
• So richtig offen und virulent ist sie auch nicht.
  • Die Mindestanforderungen des MB von 2009 sind per Einstellung umgesetzt.
  • Es gibt noch eine offene Technik-Baustelle, wie ein darüber hinaus spezifischer wirkendes Gadget aussehen könnte.
  • Niemand hat Lust, ein solches Gadget produktiv umzusetzen, und es wird auch nicht breit verlangt.
• Die zugrundeliegende Problematik besteht weiterhin.
  • Die unterschiedlichen Wege zur Realisierung sind weiterhin offen.
• Umseitig sind nur Optionen und Informationen dargestellt. Ein Richtliniencharakter ist nicht zu erkennen; insofern sind auch keine auffälligen Hinweise erforderlich.

VG --PerfektesChaos 11:43, 26. Jul. 2015 (CEST)

O.k. Dankeschön mehr wollte ich gar nicht wissen. --Liebe Grüße, Lómelinde Diskussion 12:56, 26. Jul. 2015 (CEST)

Nachdem ich aus Gründen, die sich mir heute nicht mehr erschließen, diese Seite auf beobachten habe, wurde ich auf diese Diskussion aufmerksam. Wikipedia-Seiten sollen nur dann nach Wikipedia:Archiv verschoben werden, wenn sie einen LA durchlaufen haben, und die Entscheidung auf Löschen lief. (Daß seit geraumer Zeit LAe auf WNR-Seiten abgebügelt werden mit "WP-Seiten werden nicht gelöscht", macht de Angelegenheit nicht besser. Die meisten Seiten in Wikipedia:Archiv gehören da gar ncht hin. --Matthiasb – Vandale am Werk™ ^{(CallMyCenter)} 13:37, 26. Jul. 2015 (CEST)

Matthias die Frage wurde mir hinreichend beantwortet es bedarf hier keiner generellen Diskussion über eure Privatmeinung. Was ich wissen wolte weiß ich jetzt und gut ist. Die Anfrage daher abgeschlossen. --Liebe Grüße, Lómelinde Diskussion 13:42, 26. Jul. 2015 (CEST)

Lómelinde, ob dir das schmeckt oder nicht. Du hast keinerlei Rechte irgendwem das Wort zu verbieten. --Itti 13:51, 26. Jul. 2015 (CEST)

Lómelinde, das ist keine Privatmeinung von mir, sondern das war der langjhrige Stand der Seite Wikipedia:Archiv und dementsprechend wurde bei LAen auf WNR-Seiten jahrelang verfahren, bis die Ordnungssucht die Unterscheidung von eigentlich gelöschten, aber aus Dokumentationsgründen nicht zu löschenden Seiten und lediglich eingeschlafenen Seiten zunichtegemacht hat. --Matthiasb – Vandale am Werk™ ^{(CallMyCenter)} 15:33, 26. Jul. 2015 (CEST)