Wikiup Diskussion:Meinungsbilder/Namensraum für temporäre Dateiuploads

Anwendungsbereich

Als bedeutendsten Anwendungsbereich würde ich die Bilderwerkstatt sehen. Vorlagen und Entwürfe könnten im temp. Namensraum stattfinden und nur die zufriedenstellenden Versionen werden in den richtigen oder gleich nach Commons geladen. Allerdings mangelt es mir generell an einer sinnvollen Begründung, denn was spricht denn wirklich dafür? Speicherplatz nicht, denn gelöschte Dateien bleiben in der Datenbank ja erhalten. Höchstens die Übersicht, aber das kann man auch durch Löschen/Verschieben etc erreichen. Zumal ein neuer Namensraum für Bilder einen recht tiefen Eingriff in die Software erfordert, neue Strukturen bei Bildern sind sehr aufwändig. Grüße --h-stt !? 14:45, 21. Nov. 2011 (CET)

Zum technischen: Statt eines echten zweiten Dateinamensraumes könnte man auch einen virtuellen Namensraum machen, wie es bei den Kats üblich ist. Beispiel: Datei:Temporär:Bildname.png --Morten Haan Wikipedia ist für Leser da 15:23, 21. Nov. 2011 (CET)

Stimmt, ich hatte auch primär an DÜB und Fotowerkstatt gedacht. Hintergrund dieser Idee ist, die DÜP etwas zu entlasten, sie reagiert nämlich reichlich allergisch auf bewusst ohne Freigabe hochgeladene Bilder, Beispiel 1, Beispiel 2, obwohl es durchaus auch sinnvolle Begründungen für ein solches Handeln gibt. Ideal wäre natürlich tatsächlich ein echter zweiter Dateinamensraum mit Haltbarkeitsdatum, in dem per Cronjob abgelaufene Medien gelöscht werden (vielleicht sogar echt ohne Wiederherstellbarkeit gelöscht), ansonsten wäre die Katlösung natürlich ein hilfreicher Hack... Grüße, Grand-Duc 19:56, 21. Nov. 2011 (CET)

Unnötig

Das Meinungsbild ist ziemlich unnötig. Es gibt die Vorlage:Temporäres Bild, die pappt man einfach in die temporären Dateien rein, wodurch sie in der Kategorie:Datei:Temporär landen. Dann programmiert man noch einen Bot so, dass er auf Dateien älter als z. B. vier Wochen automatisch SLA stellt, und schon hat man das Problem gelöst. SteMicha 21:30, 21. Nov. 2011 (CET)

Man bräuchte noch nicht mal einen Bot. Mann kann die Vorlage so umprogramieren, dass sie die SLA-Vorlage nach einiger Zeit automatisch einbindet. Ein virtueller Namensraum wäre aber trotzdem sinnvoll, denn dann kann man die Einbindung z. B. in Artikel per Missbrauchsfilter verhindern. Ob man dafür aber ein MB braucht, ist die Frage. --Morten Haan Wikipedia ist für Leser da 22:20, 21. Nov. 2011 (CET)

Die Vorlage kannte ich gar nicht! Hmm, damit sinkt die Priorität für dieses Mb deutlich - wobei ein in der Software implementierter Namensraum natürlich sehr wohl "nice to have" wäre, finde ich. Grüße, Grand-Duc 23:51, 21. Nov. 2011 (CET)

Ich bin mir nicht sicher, ob das wirklich nice to have wäre, denn mehrere Dateinamensräume können die WP auch unübersichtlicher machen, gerade für Neulinge. Virtuelle Namensräume, Vorlagen und Wartungskats sorgen da mMn eher für Übersichtlichkeit. --Morten Haan Wikipedia ist für Leser da 15:34, 22. Nov. 2011 (CET)

Ich finde den Vorschlag sehr interessant, nach reiflicher Überlegung (siehe Pro- und Contra-Listen) lande ich aber auch bei einer Vorlage. Ein Bot, der vollautomatisch löscht, wäre ebenfalls möglich. Um Missbrauch zu unterbinden müsste der Bot lediglich in die Versionsgeschichte der Dateibeschreibungsseite schauen und die letzte Version heraus suchen, die der Uploader des Bildes gesichtet hat. Steht dort drin, dass die Datei bitte nach Zeit x gelöscht werden soll, löscht der Bot. --TMg 23:30, 26. Nov. 2011 (CET)

@Morten Haan: Ein Temporär-Namensraum ist sowieso primär etwas, dass sich an erfahrene WP-Bildredakteure wendet, Neulinge dürften damit erstmal nicht in Kontakt kommen. Grüße, Grand-Duc 23:51, 26. Nov. 2011 (CET)

Ich verstehe auch nicht, welchen wesentlichen Vorteil der Namensraum gegenüber einer Vorlage bringen würde. Ich verschiebe das MB mal zu den eingeschlafenen, da sich hier seit der Entdeckung der Vorlage nichts mehr tut. --PM3 15:30, 13. Feb. 2012 (CET)

Gedanken von TMg

Ich selbst habe bereits temporäre Uploads benutzt (Beispiele in einem Abschnitt hier drüber) und möchte daher etwas auf die in diesem Diff erwähnten Kontra-Argumente entgegnen.

• Temporäre Arbeitskopien per Benutzerwunsch-SLA löschen lassen - ja, natürlich ist das problemlos möglich. Aber konkurrierende Wartungsprozesse (DÜP!) nehmen hier ein wenig die Kontrollierbarkeit des Vorgangs auf der Seite des Hochladers. Die potentiellen Nutzer eines Temporäruploads werden, schätze ich, erfahrene Autoren sein, die sich mit allen Lizenzen auskennen und von Fall zu Fall bewusst entscheiden, eine Datei temporär hochzuladen, die DÜP braucht nicht in Aktion zu treten. Das lässt sich aber nach derzeitigem Stand der Dinge nicht verhindern, zumal ich die Reaktion erlebt habe, dass es meiner Interpretation nach als unkollegial oder unangemessen/unerwünscht angesehen wurde, bewusst ohne freie Lizenz hochzuladen und somit der DÜP Arbeit zu verschaffen - obwohl es in meinen Augen durchaus sehr legitime Zwecke für ein solches Handeln gibt.
• Externe Imagehoster haben schwerwiegende Nachteile: oftmals begrenzte Dateiengröße, Werbung, Erfordernis, eine externe Seite zu besuchen (eigene Erfahrung: "Warum zwingst Du uns, auf diese unsägliche Flickr-Seite zu gehen?", Dschwen zu mir in einem DÜB-Thread).
• Verschiebungen in den Temporär-NR rein zu unterbinden ist eine sehr gute Idee - warum soll das aber ein Kontra-Argument sein? das Feature gibt es zurzeit nicht in der Software, weswegen ein solches Merkmal nicht als pro- / kontra-Argument herhalten kann, sondern schlicht ins Lastenheft für die Entwicklung aufgenommen werden sollte.
• Aus dem Einsatzzweck eines solchen NR ergibt sich, dass vollautomatische Löschungen unproblematisch sind. Der Temp-NR wäre ein Werkzeug, dass eben unter anderem dieses Merkmal "Automatik-Löschen" besitzt und neben bestehenden Verfahren koexistieren würde.
• Verschiebungen aus dem Temp-NR heraus könnten beispielsweise nur von dem originalen Hochlader vorgenommen werden. Muss der Hochlader auch beispielsweise Sichter (kann dieser Status automatisiert beim Hochladevorgang abgefragt werden? AFAIK existiert die Benutzergruppe "Editor" für den Sichterstatus) sein, so reduziert sich das Missbrauchspotential erheblich.
• Vorlage und Bot sind sinnvolle Alternativen, allerdings wird ein Bot vom Toolserver abhängen und somit Ausfallpotential haben. Außerdem würde eine Implementierung im Mediawiki-Code (als Extension?) eine solche Technik für andere Wikis zur Verfügung stellen und nicht auf WMF-Projekte mit Toolserver-Nutzung beschränkt sein.

Grüße, Grand-Duc 01:28, 27. Nov. 2011 (CET)

Tut mir leid, einigen Punkten muss ich deutlichst widersprechen.

• Unfreie Dateien haben in einem WikiMedia-Projekt absolut nichts zu suchen, auch nicht temporär. Das ist ein deutlicher Verstoß gegen das, wofür die MediaWiki-Projekte stehen. Solche Dateien muss man irgendwo anders hochladen. Möglichkeiten dafür gibt es wie gesagt mehr als genug.
• Sobald man das Verschieben irgendwie einschränkt, verliert die Idee des neuen Namensraums mindestens die Hälfte ihres Nutzwertes. Das Hinausschieben muss ja möglich sein, das Hineinschieben aber nicht. Das wird zu Streit und Problemen führen, wenn jemand eine seiner temporären Datei löschen lassen möchte, jemand anders möchte sie aber behalten und verschiebt sie deswegen. Solche Verschiebungen sind nicht rückgängig zu machen, außer vielleicht durch einen Administrator. Das wäre, als könnte ein x-beliebiger Benutzer eine Sperre setzen, die nur von einem Admin wieder entfernt werden kann. Etwas so einseitig funktionierendes gibt es sonst nirgends. Wenn du das Verschieben nur dem Uploader erlaubst, ergeben sich genauso viele Probleme. Wenn jemand die Datei behalten möchte, der Uploader aber nicht, muss man sie runter- und im Datei-Namensraum neu hochladen. Das wird genauso zu ärgerlichen Streitereien führen.

Meinen vorgeschlagenen Bot würde ich deswegen sogar noch stärker einschränken: Er löscht nur, wenn der Löschwunsch in der letzten Version der Beschreibungsseite steht und diese letzte Version vom Uploader gesichtet wurde. Das heißt, jeder andere Benutzer kann den Löschwunsch jederzeit stoppen. --TMg 11:17, 27. Nov. 2011 (CET)

entferntes "Argument"

Den folgenden Absatz habe ich kurz nach dem Einfügen wieder von der Vorderseite entfernt:

• Mit den heutigen Möglichkeiten (Upload als reguläre Datei und anschließender Schnelllöschantrag) wird die Datei nicht vollständig gelöscht. Streng genommen können nämlich auch Admins Seiten oder Dateien nicht wirklich löschen, sondern nur für bestimmte Benutzergruppen verbergen. Das (nicht notwendige) Bild bleibt also für ewig auf dem Server liegen und belegt dort Speicherplatz. Bei hochauflösenden Fotos mit 5 MB und mehr ist schnell eine Festplatte voll. Dementsprechend teuer kommt es der Wikimedia Foundation zu stehen – und damit uns allen, denn wir müssen sie durch Spenden finanzieren. In einem eigenen Namensraum hingegen könnte man es so regeln, dass die Bilder nach einer gewissen Frist endgültig, d. h. physisch vom Server gelöscht werden, und der Speicherplatz wieder freigegeben wird.

Das ist kein sinnvolles Argument weil nicht mit der Datenbankstruktur vereinbar. Die Software ist so konfiguriert, dass eben gar nichts gelöscht werden kann. Es kann nur in verschiedenen Stufen für immer mehr Leute unsichtbar gemacht werden. Jeder neue Namensraum für Dateien erfordert einen richtig tiefen Eingriff in die Software, der IMHO den kleinen Nutzen dieses MB nicht wert ist. Aber so tief in die Struktur einzusteigen, dass man echte Löschungen vorsehen würde, dem stimmt die Foundation mit absoluter Sicherheit nur wegen unseres kleinen MB und dessen höchst beschränktem Anwendungsbereich nicht zu. Ich bleibe weiterhin dabei, dass dieses MB einfach einschlafen sollte, es ist nicht sinnvoll. Grüße --h-stt !? 12:15, 23. Mär. 2012 (CET)

Die Serveradmins können aber schon Daten löschen. Das muss auf jeden Rechner möglich sein. Im übrigen gab es auch mal einen Bug, der dazu führte, dass eine ganze Reihe Bilder unwiederbringlich verloren gegangen ist. Sie wurden also damals unabsichtlich gelöscht. -- herein... 23:49, 23. Mär. 2012 (CET) Nachtrag: viele andere (private) Wikis setzen doch auch auf der MediaWiki-Software auf, z.B. Stupidedia. Und dort können gelöschte Artikel nur eine gewisse Zeit nach der Löschung wiederhergestellt werden. Verstreicht diese Frist, verschwinden die Artikel und zugehörigen Logbucheinträge endgültig vom Server und können auch von Admins nicht mehr wiederhergestellt werden. So ähnlich stelle ich mir das auch für den vorgeschlagenen Namensraum vor. -- herein... 08:45, 24. Mär. 2012 (CET)

Die Serveradmins können im Notfall von Hand in die Datenbankstruktur eingreifen und dort jede beliebige Änderung vornehmen. Aber das Konzept ist natürlich, dass man nichts physikalisch löscht, sondern "gelöschte" Inhalte nur ausblendet. Nur für normale Nutzer, auch für Admins, sogar für Bürokraten ... Etwas anderes passiert in keinem MediaWiki-Wiki. Und ich garantiere dir, dass die Foundation dieses Konzept nicht wegen eines kleinen, miserabel vorbereiteten Meinungsbildes in der deWP aufgeben wird. Grüße --h-stt !? 11:19, 26. Mär. 2012 (CEST)

Archiviert

Da seit März, also inzwischen 5 Monaten nichts mehr am eingeschlafenen MB geschieht und nicht mehr diskutiert wird, habe ich es nun archiviert. --Geitost 14:39, 20. Aug. 2012 (CEST)