Wikibooks:Meinungsbilder/ Gesichtete Versionen

Aus Wikibooks
Zur Navigation springen Zur Suche springen
Locked.svg

Erledigt! Die Diskussion ist zu einem (vorläufigen) Ende gekommen, und es gibt derzeit keinen weiteren Diskussionsbedarf.

Ergebnis: Nach Diskussion und generellem Zuspruch für die Lösung des Wunsches nach mehr Kontrolle über Inhalte (ursprünglich auf Basis der "gesichteten Versionen" wie aus der Wikipedia bekannt, aber mit einer handvoll Konkurrenzvorschlägen) stellte sich heraus, dass die entsprechende Erweiterung für gesichtete Versionen nicht mehr von der Wikimedia an die Projekte ausgespielt wird (vgl. m:Special:Permanentlink/20758859#Enabling). Andere Varianten wurden diskutiert aber mangels Beteiligung erstmal ad akta gelegt. Die Initiatoren erwägen eine Neuauflage des Vorstoßes mit möglicher Beteiligung der Wikimedia in ~6 Monaten (vgl. Spezial:Permanentlink/954712#Wikibooks:Meinungsbilder/_Gesichtete_Versionen). --HirnSpuk 00:28, 12. Apr. 2021 (CEST)[Antworten]

Meinungsbild auf Basis dieser Diskussion: Wikibooks:Verbesserungsvorschläge#Gesichtete_Versionen_-_Neuauflage

das Problem[Bearbeiten]

Wie finden wir eine Balance aus hoher Qualität und leichter Änderbarkeit? Welche Möglichkeiten der redaktionellen Arbeit gibt es bereits und sollte darüber hinaus das Tool der gesichteten Versionen eingeführt werden? --Maximilian.Petras 21:17, 20. Mär. 2021 (CET)[Antworten]

Hintergrund[Bearbeiten]

Qualität: In unserem Projekt bei OpenRewi erstellen Wissenschaftler:innen und AG-Leiter:innen Lehrbücher und Übungen für eine bestimmte Zielgruppe (Studierende, Praktiker:innen aus der Rechtspflege). Die Inhalte werden innerhalb der Projektteams sehr intensiv diskutiert. Für jedes Kapitel ist eine bestimmte Person verantwortlich, andere Autor:innen überprüfen die Inhalte in einem offenen Peer-Review-Prozess. Dennoch bleibt es bei der Letztverantwortung. Die Autor:innen eines Kapitels treten dabei mit Klarnamen auf und stehen für die Inhalte mit ihrer wissenschaftlichen Reputation.

Änderbarkeit: Ziel des Projektes ist aber auch, den Input von externen Fachleuten, Studierenden oder anderen Interessierten so häufig wie möglich anzuregen. Dafür hat Hirnspuk uns eine tolle Kommentarfunktion gebaut. Wir wollen aber auch, dass die Kapitel direkt von den Leuten geändert werden. Zum Beispiel werde ich in meinem Seminar im Sommersemester jede Woche alle Studierenden auffordern, die Kapitel zu verbessern. Deshalb können theoretisch geballt in einem engen Zeitraum viele Leute an den Kapiteln herum schreiben. Wir werden uns auch über öffentliche Aufrufe (z.B. bei Twitter) darum bemühen, dass andere Leute über die Kapitel drüber schauen.

Vandalismus: Ich hoffe es natürlich nicht, aber gerade in den Projekten zu den Grundrechten und dem Migrationsrecht gibt es erhebliches Potenzial für starke politische Diskussionen. Hier würden zusätzliche Mittel die Admins entlasten.

Das offene Wiki-Prinzip finden wir natürlich gut, deshalb sind wir hier. Gerade weil wir mit Klarnamen agieren, entstehen hier neue Probleme, die wir gerne lösen wollen.

Lösung 0 - mit bestehenden Tools arbeiten[Bearbeiten]

Speziell bei OpenRewi könnten wir die Autor:innen-Namen raus nehmen, sobald die Bücher in einem Verlag in der ersten Auflage veröffentlicht sind. Über die Artikel kommt dann der Disclaimer, dass hier weiterhin "work in progress" stattfindet.

Mögliche Vorteile

  • geringer technischer Aufwand

Mögliche Nachteile

  • Wikibooks wird zum reinen Arbeitsplatz - kein Ort, an dem die fertigen Bücher sind. Das wäre schade.
  • wir verweisen aus den im Verlag veröffentlichten PDF-/Epub-Versionen über die Links auf Wikibooks - sie werden so automatisch zum Bestandteil der publizierten Bücher - Falls das "unverlässliche" work in progress Varianten wären, müssten wir wiederum die Links raus nehmen

Lösung 1 - Seiten sperren[Bearbeiten]

Artikel von OpenRewi Sperren und somit als aktuelle Auflage festsetzen - weitere Arbeiten nur an einer "inoffiziellen" Kopie des Artikels.

Mögliche Vorteile

  • bestehende Infrastruktur kann genutzt werden
  • Seiten wären "sicher" gegenüber Änderungen - nur Admins können die Sperrung aufheben

Mögliche Nachteile

  • Arbeit müsste durch Admins geleistet werden (hier kommen bald noch ein paar Projekte hinzu, das wäre sehr viel Arbeit)
  • wie lassen sich die Bearbeitungen zusammenführen, so dass die Autorenliste erhalten bleibt?
  • der Artikel soll über mehrere Monate verbessert werden und gleichzeitig als Prototyp relativ gesichertes Wissen enthalten - es wäre schwer hier den korrekten Zeitpunkt für die Sperrung festzulegen

Beispiel einer Umsetzung bei OpenRewi Wir stellen unsere Bücher, z.B. im Projekt Grundrechte, soweit fertig bis sie ohnehin in einem Verlag veröffentlicht werden. Sobald das Manuskript an den Verlag geht, werden die bis dahin bearbeiteten Versionen gesperrt und es wird eine Kopie des Buches angelegt. Ab dann wird an dieser Kopie bis zur zweiten Auflage gearbeitet, ohne dass den Kapiteln einzelne Autor:innen zugeordnet sind. Sobald die zweite Auflage veröffentlicht wird, kommt die erste Auflage raus aus dem Buchkatalog. usw. usw.

Lösung 2 - Seiten teilweise sperren[Bearbeiten]

Artikel von OpenRewi teilweise sperren, so dass sie nur durch angemeldete Benutzer verändert werden können.

Mögliche Vorteile

  • bestehende Infrastruktur kann genutzt werden
  • Seiten wären zumindest gegen oberflächlichen Missbrauch sicher

Mögliche Nachteile

  • Sperrung müsste durch Admins geleistet werden (bei OpenRewi kommen bald noch ein paar Projekte hinzu, das wäre sehr viel Arbeit)
  • die Hürde der Anmeldung ist evtl. nicht besonders hoch - das ist in meinen Augen eher eine Vandalismus-Prävention als eine redaktionelle Arbeit

Lösung 3 - Tool zu gesichteten Versionen einführen[Bearbeiten]

Hinweis

Die technische Umsetzung ist extrem problematisch. Die Wikimedia hat die Implementierung seit 2014 ausgesetzt. Wenn wir das selber machen (falls das überhaupt geht?), wäre ein Zeitaufwand von mehr als acht Stunden + regelmäßige Wartung hinterher damit verbunden.--Maximilian.Petras 20:49, 22. Mär. 2021 (CET)[Antworten]

Vor ein paar Jahren hat @Stephan Kulla bereits die Frage aufgeworfen, ob das Feature aus der Wikipedia zur Sichtung von Änderungen auch hier eingeführt werden sollte.

Mögliche Vorteile:

  • eine Qualitätsgarantie unserer Artikel, da immer die* jeweilige Autor:in drüber schaut
  • eine niedrigere Hemmschwelle von Externen, Vorschläge für Änderungen und Ergänzungen zu machen, da nicht sofort alles online ist, sondern ein Diskussionsprozess gestartet wird
  • Erleichterung bei den Autor:innen von OpenRewi, die alle mit Klarnamen arbeiten und für die Artikel "verantwortlich" sind
  • ein intensiverer Austausch innerhalb der Wikibooks-Community über neue Projekte

Mögliche Nachteile:

  • geringe Anzahl aktiver Sichter - Gefahr, dass neue Änderungen und Artikel hängen bleiben

Anwendungsbeispiele speziell bei OpenRewi

  • ein Kapitel wird als Grundlage für eine universitäre Arbeitsgemeinschaft von drei unterschiedlichen wissenschaftlichen Mitarbeiter:innen gleichzeitig innerhalb einer Woche benutzt - verschiedene Studierende machen Änderungsvorschläge, weil wir sie gezielt dazu auffordern - die OpenRewi Autor:in des Kapitels kann die Änderungen in Ruhe anschauen annehmen/ablehnen/kommentieren - währenddessen kann das Kapitel weiter von vielen Arbeitsgemeinschaften gleichzeitig genutzt werden, da ein kontinuierlicher Qualitätsstandard garantiert ist
  • ...


Die technische Umsetzung der Einführung:

Interessant ist die Umsetzung in der englischen Wikibooks-Version. Dort wird immer die aktuellste Version der Seite angezeigt. Nur im Kinderbereich wird die jeweils überprüfte Version angezeigt. Es wird aber ausdrücklich allen Büchern freigestellt, ebenfalls diesen Schutz in Anspruch zu nehmen. Vielleicht wäre dieses Modell auch etwas für unser Wikibooks? Dann könnten wir die Bücher von OpenRewi individuell schützen.

Den passiven Sichterstatus würde ich niedrigschwelliger als in der deutschen Wikipedia ansetzen. Vielleicht reichen hier zehn edits wie in der englischen Wikipedia?

Die konkrete Nummer für den aktiven Sichterstatus kennt ihr besser als ich. Wieviele edits braucht es z.B., um ein Buch fertig zu stellen?

Speziell für unser OpenRewi-Projekt bräuchten wahrscheinlich alle Autor:innen zunächst manuell den aktiven Sichterstatus, um die Änderungen ihrer Artikel verwalten zu können. Wir schreiben die Bücher als Gemeinschaftsprojekt, so dass nicht super viele Änderungen zusammen kommen, um den Status automatisch erhalten zu können. Dennoch wäre es gut, wenn die Autor:innen die Änderungen von Externen für ihre individuellen Kapitel jeweils sichten könnten.

Für die meisten etablierten Autoren würde sich also nicht viel ändern, da sie ohne Probleme in den aktiven Sichterstatus rutschen? Für die bei OpenRewi manuell zu erteilenden könnte ich mich auch jetzt schon als Admin zur Wahl stellen, um im Falle meiner Wahl die Arbeitslast für alle zu reduzieren.

Offene Diskussion[Bearbeiten]

Mich interessiert eure Meinung natürlich sehr. Vielen Dank schon jetzt für die Kommentare von @HirnSpuk, @Qwertz84 , @Yomomo, @Jürgen

Was denkt ihr? @Nikolas? @Rhea? @Lars? @Johannes?

{{|1=Symbol suggestion vote.svg Kommentar Also, erstmal; ich sehe Euren Bedarf und ich möchte das gerne lösen. Ich denke aber wir brauchen dafür Zeit. Das aktuelle Meinungsbild halte ich für zu schnell und nicht sauber genug ausgearbeitet, weil die Optionen viel zu tief eingreifen. Zu den Gründen:

  1. Ich schätze, wir haben zur Zeit viel zu wenig erfahrene Admins, die das sinnvoll umsetzen können. Es müssten ja auch Hilfen geschrieben werden etc. Auch eine schnelle Admin-Ernennung für Max würde das Problem nur begrenzt lösen. Was passieren kann, wenn Admins zu schnell agieren ist im Import-Logbuch und dieser Diskussion zu sehen: Benutzer_Diskussion:Yomomo#Vorlage:Dokumentation.
  2. Es müssten Regeln festgelegt werden, nach denen diesbezüglich gehandelt werden kann. Die obige Einsatzplanung finde ich zu rudimentär.
  3. Ich kann verstehen, dass das gut für das Projekt OpenRewi ist und Ihr eine schnelle Umsetzung favorisiert. Ich bin mir jedoch nicht sicher, ob das (aktuell und schnell) so eine gute Idee für Gesamtwikibooks ist.

Wichtigste Frage für mich: Wie wird diese Opt-In/Out-Maßnahme beim Sichten umgesetzt?

Umsetzung im April 2021 halte ich für vollständig unrealistisch.

Von meiner Seite gibt es zur Zeit ein generelles Symbol oppose vote.svg Contra für alle Punkte, weil zu schnell und zu unpräzise. Grundsätzlich befürworte ich aber eine Umsetzung in der ein oder anderen Form. Eine Nutzung der gesichteten Versionen kann ich mir gut vorstellen. Dazu möchte ich aber definitiv mehr Infos haben: Wie kanns laufen? Wer machts? Wer schreibt die dazugehörigen Hilfeseiten? Wie sollen die Grenzen für die Rechte gesetzt werden? Meine Erfahrungen mit den gesichteten Versionen in der Wikipedia sind unterirdisch, daher bin ich skeptisch. Die Version auf den englischen Wikibooks wirkt auf den ersten Blick durchaus in Ordnung, da brauche ich aber Zeit mir das anzugucken, solange wie mir hier keiner erklärt, wie das präzise laufen kann.

Mich interessiert auch die Meinung von @Bautsch und @Gluedrop sowie @Stephan. Gruß --HirnSpuk 22:13, 20. Mär. 2021 (CET)}}[Antworten]

Symbol suggestion vote.svg Kommentar Meiner Meinung nach muss man das auch einfach mal ausprobieren. Man kann eine solche Maßnahme auch wieder zurücknehmen, wenn es sich herausstellt, dass das für "Gesamt WB" nichts war. Wichtig finde ich, dass die Arbeit hierzu gerecht verteilt wird, und da sollte schon jemand aus dem OpenRewi-Projekt tatkräftig und administrativ bei der Umsetzung helfen können. Qwertz84 23:10, 20. Mär. 2021 (CET)[Antworten]

Symbol suggestion vote.svg Kommentar Da ich explizit nach meiner Meinung gefragt wurde:
  • Meine Erfahrungen sind möglicherweise nicht repräsentativ.
  • Die Auswirkungen auf Wikibooks in Bezug auf Zulauf / Hemmschwellen, Administration oder Aufwand / kritische Masse kann ich nicht abschätzen.
  • Ich halte Sichter in der Wikipedia für wichtig und richtig.
  • Bislang bin ich in Wikibooks gut ohne Sichtung gefahren, das könnte sich aber eventuell auch einmal ändern...
--Bautsch 23:52, 20. Mär. 2021 (CET)[Antworten]

Symbol suggestion vote.svg Kommentar Ich bin heute tiefer in die Spezifikationen der Extension eingetaucht und dabei zufällig auf die Randnotiz gestoßen, dass die Wikimedia im Moment flagged Revisions nicht mehr installiert. Soweit ich weiß, hat der deutsche Wikimedia-Ableger ebenfalls eine eigene Technik-Abteilung. Treffen die auch eigene Entscheidungen? Gerade wenn flagged Revisions in der deutschen Wikipedia so stark etabliert ist? Falls nicht, müssen wir wahrscheinlich gar nicht weiter diskutieren. --Maximilian.Petras 20:23, 21. Mär. 2021 (CET)[Antworten]

In der Tat, das ist hässlich! Auch zu lesen dort: m:Flagged_Revisions#Enabling. Die Norweger waren ~2014 die letzten, die gefragt haben, wo der Task immer noch offen ist. Welche Idee steckt hinter Deiner Anfrage nach der Technik? Meinst Du damit die Manager von [1]? Ich glaub nicht, dass die da irgendwelche Möglichkeiten haben. Und die Technikabteilung in der Wikipedia wird da erst recht wohl nichts tun können. Aber fragen kostet nix. Ich habe auch im Phabricator gelesen ~8h pro Woche sind vollzeit nötig um den Kram aufzusetzen (phab:T31744#1275729). Die Antwort auf meine Fragen im englischen Wikibooks lässt mich ähnliches vermuten. Selbst wenns noch gehen würde: Ich sehe nicht, wer sich hier drum kümmern könnte.

Weiter diskutieren sollten wir dennoch, denn das Problem haben wir ja nach wie vor. Gehen wir also davon aus, dass Lösung 3 raus ist? --HirnSpuk 21:52, 21. Mär. 2021 (CET)[Antworten]

Symbol suggestion vote.svg Kommentar Lösung 2 halte ich für die schlechteste von allen, da sie nur Vandalismus verhindert. Die Hemmschwelle zum Anmelden ist so niedrig, dass das niemanden davon abhält Amok zu laufen. Wir hatten hier schon einen solchen Fall. Der Herr scharrt auch schon wieder mit den Hufen, da er inzwischen in diversen anderen Wikis mal wieder raus geflogen ist (ich halte es für denkbar, dass er zurückkehrt). Es ist also eine Frage von "wie schnell erkennt man verdeckten Vandalismus".

Lösung 1 hingegen ist auch zukunftsfähig. Ich mein, es wär zwar cool, wenn OpenRewi ein Selbstläufer würde, aber was wenn nicht? Was, wenn Ihr jetzt – sagen wir – 8 Bücher schreibt und dann sind alle Studenten weg, die Projekte sind ausgelaufen, die Promovierten gehen in die Politik oder gründen gut laufende Kanzleien (sorry für den bösen Seitenhieb ;-), ist lieb neckend gemeint)? Dann steht die Wikibooks-Gemeinschaft vor dem Problem, dass hier keiner wirklich Ahnung von Recht hat. Mit vollgesperrten Auflagen wäre das Problem dann nahezu nicht existent. Mit Teilgesperrten Seiten stehen wir nach wie vor vor dem selben Problem.

Yomomo hat ja neulich importiert und dabei wurden die Versionsgeschichten "gemerged" (vereinigt). Was schonmal das Problem der Autorennennung vereinfachen würde. Vielleicht kann man das zu diesem Zweck bewusst provozieren? Benutzer:Stephan Kulla, Benutzer:Mjchael, Benutzer:Yomomo hat jemand von Euch Zeit das mal auszuprobieren?

Und dieses Problem zu besprechen ist dringend nötig, denn Ihr seid ja nicht die einzigen mit dem Problem. Jeder akademische Autor wird früher oder später vor der Frage stehen.

Gruß --HirnSpuk 21:52, 21. Mär. 2021 (CET)[Antworten]

Symbol suggestion vote.svg KommentarHaha, mich wirst du in keiner Großkanzlei finden, aber ich weiß natürlich, worauf du hinaus willst. Auch wenn ich bis jetzt davon ausgehe, dass es OpenRewi für immer geben wird. Du hast mich umgestimmt. Ich bei Lösung 1 mehr Details zur möglichen Umsetzung bei OpenRewi hinzugefügt.

Würden wir die Seiten der "ersten Auflage" (die gesperrte Version) dann in die neue Work in Progress Auflage importieren? --Maximilian.Petras 20:49, 22. Mär. 2021 (CET)[Antworten]

Symbol suggestion vote.svg KommentarUnd könnten die gesperrten Seiten weiter auf den Diskussionsseiten kommentiert werden? Das wäre als extra Kommentarfunktion toll für die Printversion.--Maximilian.Petras 20:55, 22. Mär. 2021 (CET)[Antworten]

Nun, eine Kopie ist akutell inklusive Versionsgeschichte möglich, aber schwierig, vergleiche dort: Wikibooks:Ich_brauche_Hilfe#Import_einer_Versionsgeschichte. Ich denke die Kommentare von Reise Reise dort deuten darauf hin, dass es eine Möglichkeit gibt. Ich würde gern damit spielen, kann das aber ohne Admin-Rechte nicht tun und könnte auch überhaupt keinen Zeithorizont dafür angeben, selbst wenn ich es dürfte. Ich sehe jetzt allerdings nur begrenzt Probleme bei einem simplen Copy-Paste, da es ja "nur" darum ginge mögliche "Neuautoren" in die zweite Edition zu kriegen, was bei einem "Import" ja vielleicht möglich wäre, wie ich oben schrieb. Auch das muss allerdings jemand mit Adminrechten probieren.

Eine Kommentierung der gesperrten Seiten sollte weiter möglich bleiben, da – wenn ich es richtig sehe – Diskussionsseite und Inhaltsseite getrennt voneinander gesperrt werden müssten, um beide zu sperren. Wenn ich das richtig sehe, dann sollten sogar die Vorlagen-Links weiter auf die Diskussionsseite funktionieren. Es ändert sich also nichts außer, dass niemand mehr in der fixierten Edition editieren kann. Es bedürfte natürlich zu Beginn eines jeden Kapitels einer noprint-Vorlage, die auf die "unstable"-Version hinweist.

Deine Präzisierung oben ist übrigens wahrscheinlich auch nicht ganz richtig. Man muss die erste Edition nicht aus dem Buchkatalog nehmen. Wenn man die beiden Versionen vereinigt, dann wird ja automatisch aus der ersten die zweite Auflage und das bleibt aus der Versionsgeschichte auch ersichtlich. Folglich bedarf es keiner weiteren Arbeit im Buchkatalog. Die Editionen sind sogar rein kapitel-/seitengebunden; eine Änderung im Buchkatalog (den ich übrigens überflüssig finde) ist also gar nicht nötig, wenn ein Kapitel eine Neuauflage bekommt. Es muss einfach nur ein Admin die unstable-Version exportieren und in die Haupt-Version importieren. Dann müsste das automatisch richtig werden. Die unstable-Version kann ja sogar exakt so bleiben, da sie ja als Basis für die nächste Auflage genutzt werden kann. So ist zumindest meine Hoffnung. Unglücklich wäre, wenn wir das alles händisch klöppeln müssten, mit Autorenliste und so. Das wär dann doch zu viel des Guten.

Ich denke, um zu prüfen, ob das geht müsste ein Admin folgendes probieren:

  1. Seite anlegen (oder vorhandene nutzen)
  2. Seite sperren (also wenn vorhandene, dann irgendwas nehmen, was nicht so wichtig ist)
  3. Seite exportieren Spezial:Export, mit VOLLER Versionsgeschichte!
  4. Seite als Seite/ unstable o.ä. importieren
  5. Seite/ unstable ein paar mal von unterschiedlichen Leuten bearbeiten lassen
  6. Seite/ unstable exportieren mit VOLLER Versionsgeschichte
  7. Seite/ unstable in Seite importieren und Versionsgeschichte prüfen.

Erwartung: Die Versionsgeschichten werden vereinigt, Export und Import ist für Admins möglich, beide Seiten sind hinterher identisch, mit identischer Versionsgeschichte. Arbeitsaufwand für Admins: Je Seite 1x sperren, 1x Export, 1x Import. Je Auflage und Seite 1x Export, 1x Import. Um den ersten Export/Import (Punkt 3/4) zu umgehen, könnte man auch mit Copy-Paste experimentieren. Dann würde ein Admin nur noch zum Sperren und zum Auflagenupdate benötigt.

--HirnSpuk 00:07, 23. Mär. 2021 (CET)[Antworten]

Symbol suggestion vote.svg Kommentar Ein paar Anmerkungen zur 1.Lösung:

  • Selbstverständlich soll jeder hier die gleichen Rechte haben: auch andere Autoren könnten für sich beanspruchen, voll gesperrte Seiten für ihre Buchprojekte zu bekommen. Wenn nun viele Autoren vollgesperrte Seiten beanspruchen, führt das zu erheblichem Workload der Administration und widerspricht meiner Ansicht nach dem Ziel von Wikibooks.
  • Man erkennt in der Versionsgeschichte, wer was geschrieben hat, damit ist ja klar, wer wessen Mutter beleidigt hat und wer für die fachlichen Inhalte verantwortlich ist. Dadurch sollte die Reputation gewahrt bleiben.
  • Vollsperrung arbeitet mit einer "Arbeitskopie". Bei dieser Kopie wird ja auch die Versionsgeschichte vollständig dupliziert. Zur Zeit haben wir keine mir bekannte Möglichkeit hier, Seiten entsprechend zu duplizieren.
  • Sperrungen und Sichtungen haben doch das Ziel, Vandalismus und "Einflussnahme" spezieller Gruppen zu verhindern. Dieser Vandalismuss kann auf der Ebene der Arbeitskopie wie auch der ungesichteten Versionen passieren.

Qwertz84 23:35, 22. Mär. 2021 (CET)[Antworten]

Ein paar Anmerkungen zu Deinen Punkten, ich sehe da Missverständnisse:

  • Den Workload für die Administration halte ich aber für vertretbar niedrig im Vergleich zur Wartung der Sichtung. Warum widerspricht Workload für die Administration den Zielen von Wikibooks? Und klar: Ohne "Geht-klar" der Administration ist die Chose nicht umsetzbar.
  • Wer macht sich denn den Aufwand aus der Versionsgeschichte raus zu suchen, wer wessen Mutter beleidigt hat? Außerdem geht es nicht um offensichtlichen Vandalismus, sondern um Vandalismus, den man nur mit Sachverstand beurteilen kann. Beispiel ist unsere letzte offizielle Benutzersperrung. Bei jedem Wiedergänger-Account kostet es uns knapp ne Woche das zu merken. Der Kollateralschaden bei Auflagen wäre – glaub ich – deutlich niedriger.
  • Wie ich oben schrieb erhoffe ich mir die Möglichkeit. Ohne diese ist das natürlich auch nicht umsetzbar.
  • Die Sichtungen, wie sie hier von OpenRewi gewünscht sind, sollen aber als redaktionelles Werkzeug eingesetzt werden und nicht als Vandalen-Block.

Gruß --HirnSpuk 00:23, 23. Mär. 2021 (CET)[Antworten]

  • Zu Warum widerspricht Workload...: Sorry, wenn das falsch rüberkam: Wenn viele Autoren vollgesperrte Seiten beanspruchen, dann führt das einerseits zu einem erheblichen Workload und andererseits widerspricht das mMn. den Zielen eines offenen Wikibooks. Der erhebliche Workload selber widerspricht selbstverständlich nichts und niemandem.
  • Zu Wer macht sich denn den Aufwand: einzig und alleine Fachautoren können den fachlichen Gehalt von Büchern beurteilen. Das geht uns beim Traktorenlexikon, bei Esperanto und bei allen anderen Büchern so. Da ist Rechtswissenschaft keine Ausnahme und hat keine Sonderstellung. Tatsächlich ist damit aber auch die Verantwortung klar: Autor:innen sind für ihre Werke selbst verantwortlich. Anders sieht es bei Vandalen aus: Wegen der zusätzlichen Knöpfchen sind die Administratoren hier in der Pflicht.
  • Ich bin bei "Auflagen" aber grundsätzilch bei dir, HirnSpuk. Auch, wenn das gerade nicht so rüberkommt.

Qwertz84 09:43, 23. Mär. 2021 (CET)[Antworten]

Symbol suggestion vote.svg Kommentar Beim Versuch rauszukriegen, wie das mit dem Import funktioniert, habe ich mal rausgesucht, wie die aktuellen Abläufe ohne Bürokraten jetzt sind: m:Steward_requests/Permissions/Minimum_voting_requirements.

Wir brauchen für die ganze Aktion wohl einen Upload-Importer. Ob und wie diese Rechte vergeben werden, lässt sich anhand obiger Seite nur begrenzt beurteilen. Es scheint aber möglich. Da müsste man im Fall der Fälle wohl nachfragen. Ich konnte jedoch bestätigen, dass die Versionsgeschichten vereinigt werden. Und ich habe mehrfach gelesen: Die Versionsgeschichte ist nicht nötig, um der Lizenz genüge zu tun. Heißt also auch Copy-Paste wäre so oder so möglich. Auch wenn es sich nach meiner Erfahrung hier irgendwie falsch anfühlt. Gruß --HirnSpuk 02:59, 24. Mär. 2021 (CET)[Antworten]

Wie das Sichten in der Wiki funktioniert, verursacht es meines Erachtens eine (noch stärkere) hierarchische Struktur. Ich bin eher für Lösung 2, man kann die entsprechenden Seiten für nicht angemeldete sperre, wenn eine angemeldete (besonders anonyme) Person immer wieder stört, kann man sie auch vorläufig sperren, diese Vorgehensweise braucht nicht so viel Aufwand.Praktisch gesehen, ist Sichten nicht viel anders, nur, wie gesagt, meines Erachtens verursacht es noch mehr Hierarchie, die zwar notwendig sein kann, aber nicht in dieser Art und Weise... LG! Yomomo 18:00, 5. Apr. 2021 (CEST)[Antworten]

Symbol suggestion vote.svg Kommentar Es geht nur um das Buch "OpenRewi", richtig? Wenn ja, dann seit ihr frei, jede Lösung zu wählen, die ihr für sinnvoll haltet. Ich würde empfehlen, genauso wie die Wikipedia vorzugehen: Seiten bei Bedarf (und ggf auch nur für eine gewisse Zeit) zu sperren, wenn sich Vandalismus häuft. Ansonsten sind die Nachteile (weniger Korrekturen von außen / aufwendigere Bearbeitung, weil man stets angemeldet sein muss) größer als eventuelle Vorteile. Eher würde ich schauen, dass es eine Struktur gibt, die Vandalismus gut auffangen kann. Spezial:Änderungen an verlinkten Seiten ist zum Beispiel gut geeignet alle Änderungen eines Projekts anzuzeigen (Bsp: Änderungen an „Mathe für Nicht-Freaks“). So kann man schnell Änderungen an einem Projekt kontrollieren. Bei uns im Projekt gibt es auch Personen, die sich verantwortlich fühlen, diese Änderungen regelmäßig durchzuschauen. Meine Empfehlung: Wenn eine Seite regelmäßig vandaliert wird, sperrt man diese für IP-Bearbeitungen. Liebe Grüße Stephan Kulla 19:40, 5. Apr. 2021 (CEST)[Antworten]

Symbol suggestion vote.svg Kommentar Danke für eure ganzen Rückmeldungen! Das ist sehr hilfreich. Ich scheue mich im Moment, Admins um das Testen unserer Ideen zu bitten. Wenn Serlo gute Erfahrungen mit den bestehenden Strukturen gemacht hat, könnten wir das auch erstmal ausprobieren. Also Lösung 0 wählen, Wikibooks als Arbeitsplatz benutzen. Bei Bedarf einzelne Seiten sperren etc. --Maximilian.Petras 21:14, 6. Apr. 2021 (CEST)[Antworten]

Zeitplan[Bearbeiten]

Diskussion bis zum 02.04.2021

Abstimmung bis zum 09.04.2021

Umsetzung bis zum ??.04.2021 - das ist nur ein Vorschlag. Ich kann nicht abschätzen, wie lange solche Umsetzungen dauern. Die Hilfeseiten könnte ich auf jeden Fall mitschreiben.

Abstimmung[Bearbeiten]

Lösung 1[Bearbeiten]

Lösung 2[Bearbeiten]

Wenn Lösung 3 nicht umsetzbar ist, fände ich die Lösung ebenfalls okay.--Maximilian.Petras 20:25, 21. Mär. 2021 (CET)[Antworten]

Lösung 3[Bearbeiten]

Ich würde die Lösung gerne zurückziehen, siehe oben.