Wikipedia:Verbesserungsvorschläge/Archiv/2009/April

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

gesperrte Admin-Socke ;)

Vielleicht eine ganz blöde Idee... aber vielleicht überlegenswert? Mal unabhängig davon ob dies rechtlich haltbar ist: Man könnte doch einen Account anlegen und mit Admin-Rechten versehen um damit einer breiteren Benutzergruppe als Admins das Einsehen von gelöschten Inhalten zu ermöglichen? Das Passwort dafür könnte man (nur als Idee) bestätigten Benutzern / Schiedsgericht / OTRS zukommen lassen? Mit diesem Account darf nicht editiert werden. Jeder Edit, gleich welcher Art wird revertiert. Was meint ihr? --Marcela 23:07, 5. Apr. 2009 (CEST)

Halte ich nichts von. Die Gefahr, dass da mal jemand doch mal Mist baut oder mit dem Password schludert und dann andere Mist bauen, ist zu groß. Und was soll dann passieren? Der „Admin-für-Alle“-Account bräuchte mindestens ein neues Passwort, das dann alle Berechtigten neu mitgeteilt bekommen müssten, und wie sanktioniert man denn den Übeltäter (der ja, da der Admin-Account eingeloggt war, bestenfalls per CU-Vergleich aller berechtigten Nutzer zu ermitteln wäre? Ein immenser Datenschutzeingriff...) Bedarf besteht auch nicht: Schiedsgerichtler haben AFAIR die Knöpfe für die Dauer ihres Dienstes, OTRSler können sich regulären Wahlen stellen. Für den Rest ist es nicht so schwer, einen Admin zu finden. Dafür gibt es extra die Seite mit Adminanfragen, gegebenfalls auch die Löschprüfung. -- Tobnu 23:17, 5. Apr. 2009 (CEST)
Die Vandalismusmöglichkeit ist für Adminaccounts ungleich größer. Wenn ich mal bockig bin, logg ich mich über Proxie ein, zerstöre größere Mengen nur äußerst mühsam wiederherstellbarer Artikel per ihr-wisst-schon-wie und spiele danach weiter den netten, unscheinbaren, voll vetrauenswürdigen Typen? Nee, lieber nicht. −Sargoth 23:45, 5. Apr. 2009 (CEST)

Halte ich für eine prima Idee. Zumindest einen Versuch – für langjährige und vertrauenswürdige Mitarbeiter – wäre es imho wert. --Hans Koberger 08:48, 6. Apr. 2009 (CEST)

Dann geht nur wieder das Passwort verloren. Tipp: in bugzilla: einen Antrag stellen, dass eine neue Benutzergruppe "darf gelöschte Seiten sehen" eingerichtet wird, das Recht zum Vergeben an Admins geben und die können dann munter das Recht vergeben. —Wuzur 10:55, 6. Apr. 2009 (CEST)

Die Idee ist ungefähr genauso gut wie auf Unix-Systemen meheren Leuten das root-Passwort zu geben, mit anderen Worten: es ist grober Unfug. Eine Benutzergruppe "Darf gelöschte Seiten sehen" haben wir bereits. Wir nennen sie Admins. Ich sehe keinerlei Handlungsbedarf. --AT talk 16:55, 8. Apr. 2009 (CEST)

Dass es für Dich persönlich keine Verbesserung ist, ist mir schon klar... --Hans Koberger 17:00, 8. Apr. 2009 (CEST)
Ich halte es unter anderem auch deshalb nicht für eine Verbesserung weil "langjährige und vertrauenswürdige Mitarbeiter" Admins werden/sein sollten und das Einziehen einer weiteren Bürokratie- bzw. Abstimmungsschicht unnötig ist. Lies es einfach als: Mehr Admins bitte! --AT talk 17:03, 8. Apr. 2009 (CEST)
Das „Wer-wird-Admin-Spiel“ hat aber ganz andere Regeln. Die Eigenschaften „langjährig“ und „vertrauenswürdig“ spielen da eher eine Nebenrolle ;-) Für die Arbeit für WP wäre es für Nichtadmins jedenfalls eine gute Hilfe. --Hans Koberger 17:13, 8. Apr. 2009 (CEST)
(BK) Dass die Möglichkeit, gelöschte Artikel einsehen zu können, auch für mich der verführerischste Aspekt der Admintätigkeit war (und ist), will ich nicht verhehlen. Diese Möglichkeit aber auf eine kleine Gruppe zu begrenzen, ist imho nicht nur aus missbräuchlichen und unehrenhaften Erwägungen („Herrschaftswissen“) gegeben (und wäre dann selbstverständlich sofort abzustellen, indem man das allen freigibt), sondern auch und gerade wegen der imo doch erheblichen Missbrauchsmöglichkeiten, die sich daraus ergeben. Die von Sargoth genannte Möglichkeit, viel gezielter Vandalismus zu begehen, wenn auch nur die Anzahl und zeitliche Anordnung gelöschter Versionen bekannt wären, halte ich für durchaus real. Ausserdem müssten eine recht grosse Anzahl von URVen, Beleidigungen und Klarnamensnennungen per Oversight entfernt werden, weil sie eben nicht publiziert werden dürfen (und eine Publikation stellt es ja dar, wenn eine Information einer grösseren, nicht abgeschlossenen Gruppe öffentlich zugänglich gemacht wird). Den Aufwand, hier alle gelöschten Versionen durchzugehen, zu prüfen und dann dem Oversight zu melden, halte ich nicht für leistbar - und das Argument von Sargoth bliebe bestehen. Aus diesen Gründen finde ich eine Begrenzung auf Benutzer, denen per Wahl das Vertrauen ausgesprochen wurde, notwendig. Inwieweit man dafür einen neue Gruppe mit diesem besonderen Recht schaffen sollte, will ich nicht beurteilen, ich wäre eigentlich eher dafür, die Gruppe der Admins kräftig zu erweitern - Hans, Dir bin ich damit doch auch schon auf die Füsse getreten. --Port (u*o)s 17:18, 8. Apr. 2009 (CEST)

Änderungen in der Versionshistorie zusammenfassen

Ich möchte den Vorschlag machen, Änderungen desselben Autors in der Versionshistorie zusammenfassen zu können. Ich habe jetzt erst erfahren, dass mit jedem Abspeichern der komplette Artikeltext gespeichert wird. Trotzdem wird es mir auch in Zukunft nicht gelingen, alle Änderungen in nur einem Vorgang erledigen zu können. Man übersieht doch immer wieder etwas oder baut einen Artikel mehrschrittig aus, um nicht die Übersicht über das Ganze zu verlieren. Hinterher könnte man dann diese Schritte zusammenfassen und sich ggf. eine gemeinsam passende Zusammenfassungszeile überlegen. Dabei wäre es überlegenswert, ob ein Autor nur die eigenen Änderungen zusammenfassen darf (wäre für den Anfang erst mal ausreichend), oder ob auch Admins oder sogar jeder Benutzer die kleinschrittigen Änderungen eines Editors zusammenfassen darf. Die Zwischenschritte würden somit gelöscht und unnötiger Speicher, den sowieso Niemand mehr braucht, auf den Servern freigegeben. Technisch dürfte diese Implementierung kein allzu großer Aufwand sein. Es wäre eine weitere Schaltfläche in der Versionshistorie erforderlich, eine Überprüfung (darf der Benutzer das?, alle Versionen vom selben Autor und kein anderer dazwischen?) und ein angepasster Löschautomatismus. -- Qhx 13:50, 11. Apr. 2009 (CEST)

Was ist denn, wenn ich meine Programmierung an einer Vorlage absichtlich in zwei Schritten speichere, damit man nachher leichter nachvollziehen kann, was gemacht wurde, bzw. um die letzte Bearbeitung leichter rückgängig machen zu können, ohne dass die gesamte Bearbeitung rückgängig gemacht werden muss und die einzelnen Entwicklungsstufen auseinanderklamüsert werden müssen? Deine Betrachtung erfolgt bislang ausschließlich aus Lizenzsicht. Werden einzelne Bearbeitungen zusammengefasst, so gehen mit ihnen verbundene Informationen wie Quellenangaben und Bearbeitungszeitpunkt verloren. Hier ist abzuwägen, ob der eingesparte Speicherplatz diesen Informationsverlust aufwiegt. Gruß --WIKImaniac 14:17, 11. Apr. 2009 (CEST)
Man kann ja so eine Funktion implementieren, ob und wie sie dann benutzt wird, ist ja schließlich Sache des Autors. So eine Funktion ist ja kein Automatismus (und kann auch garnicht so verwendet werden), aber als Option kann das schon sinnvoll sein. -- Qhx 16:29, 11. Apr. 2009 (CEST) PS: und zu den Quellenangaben kann es ja eine Rückfrage programmieren, ob alle Quellen in der Betreffzeile stehen.
Hallo Qhx, gut, wenn von keinem Automatismus die Rede ist, dann kann ich damit leben. Ggf. wäre ein Hinweis/eine Rückfrage sinnvoll, wenn der Software vor dem Speichern aufgefallen ist, dass nach dem Speichern zwei aufeinanderfolgende Bearbeitungen desselben Benutzers enthalten sein würden. Problematisch ist der Zeitraum zwischen Feststellen dieses Umstandes und der Beantwortung der Systemrückfrage, da in der Zwischenzeit andere Benutzer eine Bearbeitung vorgenommen haben könnten, wodurch ein Verschmelzen der beiden Beiträge nicht mehr möglich wäre. In diesem Fall sollte einfach eine Meldung ausgegeben werden, dass das Verschmelzen der Beiträge fehlgeschlagen ist. Gruß --WIKImaniac 16:54, 11. Apr. 2009 (CEST)
Zum Speicherplatzargument: Die Texte werden (zumindest bei WMF-Projekten) komprimiert gespeichert, sodass der Kompressionsalgorithmus effektiv doppelte Teile nicht nochmal speichert, sondern nur durch eine Art Verweis auf das Duplikat. Die effektive Ersparnis an Speicherplatz wäre also nicht so groß. Grüße, -- ChrisiPK (Disk|Beiträge|Bewerten) 16:56, 11. Apr. 2009 (CEST)
Siehe auch hier. --Carbenium 12:56, 14. Apr. 2009 (CEST)

Beschleunigte WP-Namenraum-Orientierung für Wikipedia-Autoren und sonstige Interessierte

Um Wikipedianern, Neuwikipedianern und an den Funktionsweisen von Wikipedia interessierten Außenstehenden den Zugang zum Wikipedia-Namenraum zu erleichtern, möchte ich darum bitten, den dritten Willkommenssatz auf der Hauptseite wie folgt zu ändern:
Gute Autorinnen und Autoren sind stets willkommen.
-- Barnos -- 07:56, 23. Apr. 2009 (CEST)

Nachtrag für den Fall, dass sich der Sinn des Änderungsvorschlags nicht von selbst erschließt:
Nur wer Glück hat oder sehr gründlich sucht, gelangt bisher von der Hauptseite über Wikipedia nach Themen (kaum der geeignete Wegweiser in Bezug auf den WP-Namenraum) im dritten Zugriff auf das Autorenportal, der m. W. bisher einzigen WP-Namenraumseiten-Verteilerstelle.
Die Änderung bewirkt vielleicht noch nicht viel, kann aber doch eine Erste-Hilfe-Orientierung für den Wikipedia-Namenraumdschungel sein. -- Barnos -- 16:05, 23. Apr. 2009 (CEST)
Kann nicht schaden... --Carbenium 19:58, 23. Apr. 2009 (CEST)
Hm, das Autorenportal ist doch in der Sidebar verlinkt? Ansonsten finde ich den Vorschlag ebenfalls sinnvoll.--cromagnon ¿alguna pregunta? 02:09, 24. Apr. 2009 (CEST)
Klarer Fall von Irrtum meinerseits - danke für die Aufklärung auch hier! Nachzudenken bleibt dennoch – und für diese Auffassung steht Ihr vielleicht auch(?) - über eine stärkere Hervorhebung dieser Zentralverteiler-Hauptseite und über eine bessere Erschließung des Wikipedia-Namenraums insgesamt, damit Interessierten der Zugang zu den Kernbereichen der Wikipedia-Werkstatt erleichtert wird und damit nicht auch andere meinen Holzweg gehen. Morgengrüße -- Barnos -- 07:49, 24. Apr. 2009 (CEST)
Eine Doppelverlinkung wichtiger Dinge sollte man gerade im Anfängerbereich nicht ablehnen, denn als ich noch Neuling war, hat es Ewigkeiten gedauert, mich mit der Sidebar anzufreunden... --Carbenium 11:59, 24. Apr. 2009 (CEST)
Volle Zustimmung. Dass mit dem Autorenportal inzwischen eine so gute Übersichtsseite existiert, war selbst mir als altem Hasen nicht bekannt - die meisten Seiten, die mir wichtig sind, habe ich bereits anderswo verlinkt, und ansonsten suche ich halt immer. Gute Idee, das prominenter zu machen. -- Perrak (Disk) 13:17, 24. Apr. 2009 (CEST)

"Bestätigte Versionen" statt "Geprüfte Versionen"

Nach den bisherigen Erfahrungen mit den FlaggedRevisions wäre es wünschenswert, tatsächlich eine zweite Kategorie einzuführen. Es gibt derzeit zwei abgrenzbare Gruppen von "Sichtern", die einen, die nur Vandalismusfreiheit überprüfen (damit der Benutzer diese nicht zu sehen bekommt), und die, die weitergehende qualitative Prüfungen vornehmen (z.B. Prüfung der Quellenangaben, Rechtschreibung, Neutralität u.a.). Es wäre sinnvoll, zwischen diesen beiden Sichtungsverfahren zu differenzieren, auch mit dem Ziel, die "Qualitätssichter" keinem Zeitdruck auszusetzen und trotzdem eine schnelle Verfügbarkeit der "gesichteten" Inhalte zu gewährleisten.

Eine solche zweite "Klasse" von Sichtungen sollte aber nicht "Geprüfte Versionen" heißen, sondern beispielsweise "Bestätigte Versionen". Mit dem Wort "Prüfung" wird ein zu hoher Anspruch gestellt, da damit ja allgemein eine "Überprüfung der Wahrheit" beziehungsweise eine "Prüfung der Qualität" auf hohem Niveau assoziiert wird. Diesen Anspruch können die FlaggedRevisions aber meiner Meinung nicht wirklich erfüllen, insbesondere wegen der Forderung, "keine verfälschenden Lücken" durchgehen zu lassen, was insbesondere bei Wissenschaften, in denen es keinen klaren Mainstream gibt, ziemlich sicher zu Grabenkämpfen führen dürfte.

Man könnte dazu das Meinungsbild zu den Sichtungskriterien reaktivieren, wo ja schon einige Vorschläge für eine solche Vorgehensweise stehen. Meiner Meinung nach sollten die Grundprinzipien Theoriefindung, Neutralität und vor allem Belege als Bedingung für diese "Bestätigung" sein. Auch ein Kommentarfeld wäre hilfreich. Die Anforderungen an die "Bestätiger" sollten auch höher sein als für normale Sichter, z.B. wäre anzudenken, diese nur auf Antrag zu verteilen.--cromagnon wearedifferent 22:02, 18. Apr. 2009 (CEST)

Ein wunderbarer Vorschlag! Regeln könnte man das über einen zweiten Sichtungsbutton, damit der Sichter von Fall zu Fall entscheiden kann, ob er sich die Zeit nehmen will, einen eingefügten Link wirklich nachzuverfolgen oder ob man sich auf die Bestätigung der Freiheit von offensichtlichem Vandalismus beschränken will.
Zur Bezeichnung: geprüft ist schon gar nicht so verkehrt (vielleicht wäre überprüft noch besser), weil bestätigt eher impliziert, daß die Fakten im Artikel fachmännisch abgenickt sind. --Carbenium 13:21, 21. Apr. 2009 (CEST)
Das stimmt auch wieder... aber für mich hat "Geprüft" halt so einen "High-End"-Beigeschmack... Eine andere Möglichkeit wäre, die jetzigen "Gesichteten Versionen" in "Freigegebene Version" oder "Vandalismusfreie Version" umzubenennen und das Wort "Gesichtet" dann für diese neue Sichtungsklasse zu verwenden (viele argumentierten ja beim Meinungsbild letztes Jahr, dass schon die Bezeichnung "Gesichtet" Assoziazionen bei den Lesern wecke, der Inhalt der Änderungen sei überprüft worden). Aber am Namen sollte es eigentlich nicht scheitern, wichtig wäre mir eben, die viel zu hohen Anforderungen auf Wikipedia:Geprüfte Versionen auf ein Maß herunterzuschrauben, das der Realität entspricht. Die "Qualitätssichter" gibt es ja jetzt schon.--cromagnon ¿alguna pregunta? 02:07, 24. Apr. 2009 (CEST)
...deren Arbeit aber bisher leider nicht von einer "normalen" Sichtung unterscheidbar ist. In diesem Sinne stimme ich Dir voll zu, auch was die Bezeichnungsvorschläge angeht! --Carbenium 12:05, 24. Apr. 2009 (CEST)

Hier gehts weiter: Wikipedia Diskussion:Meinungsbilder/Einführung geprüfter Versionen (Testphase). Wurde nicht von mir initiiert, aber quasi "gekapert" ;-) --cromagnon ¿alguna pregunta? 06:02, 27. Apr. 2009 (CEST)

Markierung gesichtet im Versionsvergleich

Im direkten Versionsvergleich fehlt die Angabe, ob es sich um eine gesichtete Version handelt oder nicht. Dafür immer extra nochmal in die Versionsgeschichte zu gehen, ist bisweilen nervig weil überflüssig und mit zusätzlichem Aufwad verbunden. --Carbenium 13:20, 21. Apr. 2009 (CEST)

Könntest du genauer beschreiben, was du meinst? In der normalen Diffansicht ist die Markierung ja über dem Versionsvergleich vorhanden. (auf diesem Screenshot z.B. „gesichtete Version“ bzw. „Entwurfsversion“) --P.Copp 14:59, 28. Apr. 2009 (CEST)

Versionsgeschichte entlasten

Könnte man nicht alle ältesten Versionen (bis auf die letzte) eines Artikels entfernen, solange diese vom gleichen Benutzer stammen, also z.B. hier alle von 10:42 bis 11:42 Uhr? Das würde die Versionsgeschichte überschaubarer machen und die Server entlasten. --Hydro 12:29, 25. Apr. 2009 (CEST)

Bist du sicher, dass das die Server entlasten würde, ne knappe Millionen Versionsgeschichten durchzuarbeiten und einzelne Versionen zu fusionieren? Kann ich mir nicht vorstellen. -- Discostu (Disk) 13:09, 25. Apr. 2009 (CEST)
Das wäre aber nur eine einmalige Aktion (die ja auch nicht eilt und von einem Bot besorgt werden könnte) und dann hätte man m.E. einiges gewonnen. --Hydro 13:31, 25. Apr. 2009 (CEST)
Ich habe bereits vor längerer Zeit vorgeschlagen, mehrere von einem Nutzer nacheinander ausgeführte Änderungen zusammenzufassen. Da die letzte Version vor der Tätigkeit des Nutzers und die letzte Version, die der Nutzer bearbeitet hat, bekannt sind, kann es keine Schwierigkeit sein, die Differenz zu bilden, als nur eine Änderung unter dem letzten Datum zusammenzufassen und mit einem Merkmal (z. B. Zus.) zu kennzeichnen. -- wefo 14:24, 25. Apr. 2009 (CEST)
#.C3.84nderungen_in_der_Versionshistorie_zusammenfassen. Und wie ein Bot die Versionsgeschichte bearbeiten kann erschließt mir nicht so ganz. —Wuzur 18:54, 25. Apr. 2009 (CEST)
Vielleicht ein Systembot? -- Benzen C6H6 19:18, 25. Apr. 2009 (CEST)
Nicht wünschenswert, weil dabei Bearbeitungskommentare verlorengehen würden - und die enthalten oft wesentliche Informationen. Aufgrund der Art, wie die Versioneen gespeichert werden, sehe ich auch überhaupt keinen technischen Vorteil. --h-stt !? 10:50, 26. Apr. 2009 (CEST)
für die übersichtlichkeit fände ich es schön wenn nacheinanderfolgende bearbeitungen eines benutzers zusammengefasst dargestellt würden. es müsste halt für die vollständige liste eine "ausklappfunktion" geben. aber das wäre reine übersichtlichkeit. eine entlastung der server würde dadurch Sicherlich nicht erfolgen ...Sicherlich Post 10:58, 26. Apr. 2009 (CEST)
Für gewöhnlich beshäftigt man sich mit einer Stelle in der Versionshistorie eines Artikels nur ein Mal. Insofern empfinde ich eine Ausklappfunktion dort als unnötige Spielerei, die in der Summe viel Serverkapazität frißt, ohne daß es nennenswert und durchgängig nützen würde. Und daß die Zugänglichkeit jeder einzelnen Version wichtig ist, wird in einem der beiden unten velinkten Threads auseinandergedröselt. --Carbenium 21:50, 26. Apr. 2009 (CEST)
Ich hatte das schon mal als Anfrage gestartet, ist aber schnell im Archiv gelandet. Es ging mir dabei nicht um die echte Zusammenfassung, sondern nur bei der Anzeige der History. Bei Bedarf muss man die einzelnen Edits schon verfolgen können, siehe Vorschlag von Sicherlich. Und das dürfte eigentlich machbar sein. -- Jesi 12:05, 26. Apr. 2009 (CEST)
Man muß noch nicht mal die oben eingebundene Archivsuche bemühen, um darauf zu stoßen, daß dieser
Vorschlag schon mehrfach kam:
Wikipedia:Verbesserungsvorschläge#Änderungen_in_der_Versionshistorie_zusammenfassen und direkt im Anschluß:
Wikipedia:Verbesserungsvorschläge/Archiv/2009/März#Versionsgeschichte_verkleinern
--Carbenium 21:43, 26. Apr. 2009 (CEST)

Na gut, das mit den dann fehlenden Bearbeitungskommentaren kann ich einigermaßen nachvollziehen, aber die Diskussion ist ja auch ein wenig in Richtung „Zusammenfassung aller Mehrfachedits“ abgeglitten. Meine ursprüngliche Anfrage bezog sich ja nur auf die ältesten Versionen, wenn diese vom gleichen Benutzer/Ersteller stammen. Solche dürfte es nämlich garnicht geben, wenn der Artikel korrekt erstellt worden wäre, d.h. im Benutzernamensraum großgezogen und dann nicht in den Artikelnamensraum verschoben, sondern als neuer Artikel hineinkopiert worden wäre. --Hydro 22:04, 26. Apr. 2009 (CEST)

Ok, aber das weiß man als jemand, der ein kleines Bißchen Erfahrung hat. Und dann kann man ja die Radiobuttons in der Versionsgeschichte zusammenfassen. Es stellt sich deshalb die Frage, ob sich die Mühe einer Implementation eines solchen Features lohnt. Meiner Meinung nach nicht... --Carbenium 23:00, 26. Apr. 2009 (CEST)
@Carbenium dein eingekästelter beitrag ist super zu lesen
bleibt zu hoffen, dass nicht alle diese variante benutzen werden
zumindest ich finde es nervig
ich halte es für praktisch wenn die beiträge zusammengefasst sind da mich beiträge bestimmter benutzer nicht interessieren da ich ihnen vertraue; ganz egal welchen absatz sie bearbeiten
das die diskussion so regelmäßig wiederkommt könnte ein indiz dafür sein, dass es begehrt ist?
...Sicherlich Post 23:32, 26. Apr. 2009 (CEST) für deinen beitrag "Für gewöhnlich beshäftigt man sich mit einer Stelle" - wieviele ungewöhnliche gegenbeispiele von wieviel verschiedenen benutzern willst du haben?
Freut mich, daß ich Deinen Lesegewohnheiten entgegengekommen bin... ;-) Aber ich setze Rahmen an sich spärlich und wohlüberlegt. Was die Beispiele angeht: erzähl! Vier sollten für den Anfang reichen... ;-) Ich geh halt davon aus, daß man sich gewöhnlicherweise einmal mit sowas beschäftigt (z.B. im Rahmen einer Erstsichtung) und sich danach i.d.R. auf nachfolgende Sichtungen verläßt. Daß es immer Ausnahmen geben wird ist klar, aber das ist sicherlich nur ein verschwindend geringer Prozentsatz aller History-Aufrufe, sodaß die zusätzliche Serverlast nicht zu rechtfertigen ist. Da mehrere aufeinanderfolgende Edits eines Nutzers leicht ins Auge fallen, würde Dein Anliegen nur dann Sinn ergeben, wenn Du die Edits diese User komplett ausblenden könntest (wie man das bei Bots kann). Und die Tatsache, daß diese Frage so häufig auftaucht, könnte auch einfach damit zusammenhängen, daß es irgendwo eine dicke Lücke im Hilfe:-Namensraum gibt – denn daß das in der immer wieder geforderten Form nicht umsetzbar ist, tritt ja in jedem diesartigen Thread zutage... --Carbenium 00:36, 27. Apr. 2009 (CEST)
Natur, diverse von asdfj, toddyb, illbeback - nur von meiner beobachtung von gestern ... ich schaue sehr regelmäßig in die beobachtung denn die sichtungen sind ein schutz gegen "offensichtlichen vandalismus" nicht mehr und das ist ziemlich wenig und es hat durchaus sinn diese zusammenzufassen und nicht auszublenden; siehe etwa als wunderbares und aktuelle bsp. Freie Stadt Danzig. ...und es ist keine Lücke denn es ist machbar; habe ich ja oben schon gezeigt und wenn das der erste thread ist wo die machbarkeit zutage tritt dann ist das ja super ...Sicherlich Post 08:29, 3. Mai 2009 (CEST)

Autoconfirmed erst nach Mindestanzahl an Bearbeitungen

Immer mehr Leute legen Vorratssocken an. Der autoconfirmed-Status wird nach 4 Tagen automatisch vergeben. Das bedeutet jemand kann sich bequem einen Account vorsorglich registrieren und nach einiger Zeit direkt halbgesperrte Seiten bearbeiten und Verschiebungen durchführen. Wichtig war früher das Upload-Recht. Da aber inzwischen fast alle Bilder nach Commons hochgeladen werden ist das inzwischen nicht mehr so interessant.

Um Vorratssocken etwas einzudämmen fände ich es daher sinnvoll zusätzlich eine Mindestbeitragszahl einzuführen, wie bereits auf einigen andere WP vorhanden. Es müssen dann beide Bedinungen erfüllt sein (4 Tage und Mindestbeitragszahl). Derzeit gilt: 'default' => 0; 'arwiki' => 50; 'enwiki' => 10; 'eswiki' => 50; 'zhwiki' => 50

Ich wäre aber dafür diese Zahl möglichst niedrig zu halten. 5 bis maximal 10 Edits wären meine Vorstellung (nicht eingeschränkt auf ANR).

Als Nebenwirkung müssten Bots zusätzlich das skipcaptcha-Recht bekommen, was aber kein Problem darstellt. (ist schon)

P.S.: Was bringt eigentlich ein Verschiebeschutz autoconfirmed, wenn man eh erst mit autoconfirmed verschieben darf? -- Merlissimo 12:49, 22. Apr. 2009 (CEST)

Prinzipiell keine schlechte Idee, allerdings ist es bei sagen wir 10 Edits ein leichtes, relativ unbemerkt kleine kosmetische Änderungen zu machen und dann loszuschlagen. Wenn, sollte die Zahl schon bei 50 oder so liegen. Grüße von Jón + 12:52, 22. Apr. 2009 (CEST)
Ergänzungsinfo: Alle oben mit 50 Mindestbearbeitungen angegeben WPs erlauben das Verschieben ohne autoconfirmed. -- Merlissimo 13:06, 22. Apr. 2009 (CEST)
Wie viele benutzen dort die Verschieben-Funktion bevor sie autoconfirmed sind? Viele Grüße, —mnh·· 13:07, 22. Apr. 2009 (CEST)
Ich habe oben bereits einen ähnlichen Vorschlag gmeacht, womit bei autoconfirmed alles bleiben soll wie es ist, dafür aber eine neue Benutzegruppe eingeführt werden soll – Nur die und Admins sollen zweidrittelgeschützte Seiten bearbeiten können. --linveggie in Memorian Anita Roddick 12:12, 23. Apr. 2009 (CEST)
Eine Einführung von beidem wäre nicht verkehrt, da durch SUL viele Benutzerkonten durch einfaches Anklicken eines Interwikilinks entstehen und vier Tage später autoconfirmed werden, obwohl sich der Benutzer nie mit den hiesigen Gepflogenheiten beschäftigt hat... --Carbenium 19:56, 23. Apr. 2009 (CEST)
Dafür, allerdings die Mindestzahl 10 wie auf en.wiki ist zu niedrig, das habe ich in 10 minuten getan ohne dass es auffällig ist. -jkb- 13:08, 28. Apr. 2009 (CEST)
Der Versuch auf enwiki zeigt mMn, dass die Änderung der Anforderungen von "4 Tage/0 Edits" auf "4 Tage/10 Edits" keinen wesentlichen Erfolg gebracht hat. Ein Vandale, der sich die Zeit nimmt ein Benutzerkonto anzulegen und 4 Tage zu warten, um anschließend zu vandalieren, der wird auch die 2 Minuten opfern, die es dauert um 10 Mini-Edits auf der Spielwiese oder der eigenen Benutzerseite zu machen. Eine ernsthafte Abschreckung ist wohl erst so ab 50-100 geforderten Edits zu erwarten. Da stellt sich allerdings wieder die Frage, ob das nicht ein zu großes Hindernis für „good-faith“-Benutzer wäre, die z.B. ein Bild zu ihrem ersten Artikel hochladen möchten. Gruß --P.Copp 15:04, 28. Apr. 2009 (CEST)
Das mit den Bildern ist nicht so schlimm; Bilder kann man auf die Commons immer noch aus dem Stand pumpen. syrcro 15:29, 28. Apr. 2009 (CEST)
Sehe ich ähnlich. Der Aufwand wird für Vandalen nicht besonders erhöht, andererseits werden neue Benutzer, die nur eine Änderung (z.B. an einer halbgeschützten Seite) vornehmen möchten, davon abgehalten. Erfahrenen Benutzern fällt es leicht, 10, 20 oder auch 50 Beiträge anzusammeln, als Neuling fehlt es einem an Änderungen, die man vornehmen kann (ging jedenfalls mir so). Ergo, Vorschlag nicht umsetzen. --Church of emacs D B 16:11, 28. Apr. 2009 (CEST)
Das ist sicherlich richtig, aber 50 Edits sind auch nicht so die Welt, nerven aber, wenn man ständig Vorratssocken so hoch pushen muß. Es wird dann nämlich schnell lästig, für die 3-4 Vandalenedits, die es dauert, so eine Socke wegzuschließen, ständig 50 neutrale oder gute Edits machen zu müssen. Abgesehen davon halte ich es für sinnvoll, für gewisse Rechte die Zahl an Edits an verschieden Seiten im ANR festzumachen (also nicht jeden Edit, sondern die editierten Seiten zu zählen). --Carbenium 08:13, 3. Mai 2009 (CEST)
Genau das war mein Gedanke ;-). Wenn nun 50 zur Diskussion stehen sollte, müssen wir uns aber auch noch Gedanken um den Verschiebeschutz machen. Da ist 50 IMO zu hoch. Vielleicht sind ja auch 10 Artikeledits möglich. Das wäre aber dann nicht nur eine Konfigurationsänderung, sondern zugleich ein Feature-Request. -- Merlissimo 20:32, 3. Mai 2009 (CEST)