in den letzten Tagen fanden Massenedits des Users @geozeisig statt. Dabei wurde an archäologischen Objekten site_type=* stumpf durch archaeological_site=* ersetzt.
Ist dieser Massenedit vorgestellt, disskutiert und abgesprochen worden?
Es gab dieses Proposal zum Umtagggen von site_type auf archaeological_site. Das Proposal wurde mit 20 zu 4 Stimmen angenommen. Ob das auch eine dazugehörige Massenänderung rechtfertigt? Vermutlich ja.
Wie kann kann durch solche Massenedits sichergestellt werden, daß der value-Wert weiterhin korrekt ist? Gar nicht…
Ungeachtet dessen erwarte ich im Vorfeld von solchen Aktionen eine Information in den einschägig häufig genutzten Informationskanälen… So hat das für mich einen sehr faden Beigeschmack…
Sven
Edit: ich sehe im Proposal nirgendwo, daß zugleich ein Massenedit genehmigt wurde… oder?
1 Like
Mammi71
(One feature, Six mappers and still More ways to map it)
4
wenigstens im Wiki gehört dort, wo jetzt “veraltet” steht, dokumentiert, wo dies diskutiert und abgestimmt wurde.
Ich sehe bei einer archäologischen Stätte nur eine relativ geringe Gefahr/Wahrscheinlichkeit, dass sich der value in der Zwischenzeit unbemerkt geändert haben könnte.
Man könnte es zwischen den Zeilen rauslesen. "It is proposed to change the main key for archaeological sites from site_type= to archaeological_site=. This would apply to c. 113 000 features."
Muss man aber nicht.
Nun, wenn man ausschließlich den key ändern möchte, um dem ganzen eine bessere Struktur zu geben, honoriere ich das duchaus, dann muß aber zwingend hinzu geschrieben werden, daß bei Annahme des Proposals dieses als Massenedit geschieht und diesen vor dem Start in einschlägigen Kommunikationskanälen vorher ankündigen…
Danke! Das ist nicht mehr witzig.
Das ist erst recht ein Grund, einen vollständigen Revert. Ich gehe so nun auch weiter: eine Sperrung des betreffenden Users zu verlangen, da er explizit dagegen verstoßen hat.
Reverten kannst du ja auch selbst, falls du darauf bestehst, dass der Massenedit nochmal ordentlich angekündigt werden muss. Mir wärs das in dem Fall nicht wert. Eine Sperre zu beantragen wird wohl nur etwas bringen, falls dein Revert ebenfalls wieder vom User geozeisig revertiert wird oder er nach deinem Revert weiterhin Massenedits vornimmt. Ansonsten reicht auch einfach ein Kommentar am Änderungssatz. (Die DWG wird eh allerhöchstens eine 0-Stunden-Sperre verhängen, das bringt dir also auch nicht mehr als selbst einen Kommentar zu schreiben)
Edit: ich sehe im Proposal nirgendwo, daß zugleich ein Massenedit genehmigt wurde… oder?
im Wiki wurde gekennzeichnet dass site_type deprecated sei, was ja auch abgestimmt wurde, Massenedits sind aber nicht abgestimmt worden, genau.
Ich hatte im Wiki noch einen Hinweis gesetzt dass site_type derzeit viel häufiger ist als archaeological_site aber realistisch betrachtet, wenn jetzt auch nur vereinzelt von site_type entfernt werden wird wenn archaeological_type ergänzt wird, dann wird man wohl oder übel auch noch nach archaeological_site als key suchen müssen wenn man ein vollständigeres Ergebnis will.
Eigentlich gibt es keine dringende Notwendigkeit zum Entfernen von site_type
update: ich sehe allerdings dass laut taginfo gestern schon die Hälfte umgetaggt war
Unter keinen Umständen sollten Sie in großem Umfang "veraltete" Tags in der Datenbank (halb-)automatisch durch andere ersetzen, ohne den Verhaltenskodex für automatisierte Bearbeitungen einzuhalten. Jede solche Änderung wird rückgängig gemacht.
Dagegen ist klar verstoßen worden… User ist bereits gemeldet… Es ist nicht seine erste, in dieser Form geartete Aktion.
Man muss den Anwendern / Kartenmachern natürlich etwas Zeit geben für die Anpassung an neue Taggingregeln. Ich würde hier 6 Monate für angemessen halten.
Ich finde 6 Monate Wartezeit viel zu lang für eine so einfache Anpassung. Zumal neu erfasste Objekte schon ab sofort oft den neuen Schlüssel nutzen werden und daher eine Anwendung Interesse daran haben sollte, zeitnah umzustellen.
Aus meiner Sicht ist ein monate- oder jahrelanges Koexistieren eines per Proposal für ersetzt erklärten Schlüssels mit dem neuen Tagging nicht wünschenswert. Ich würde mir daher wünschen, dass ein Massenedit ~1 Monat nach einem akzeptierten Proposal zur Regel wird.
Denn einerseits ist ein Massenedit in dieser Form nicht regelkonform. Andererseits kann es aber auch nicht Sinn der Sache sein, dass die bereits beim Proposal geführte Diskussion dann noch ein zweites Mal geführt werden muss, weil die Leute, die gegen das Proposal waren, natürlich auch gegen den Edit sind.
(Idealerweise wäre das so gut koordiniert, dass eine Anwendung gar nicht erst beide Schlüssel unterstützen muss, sondern direkt vom alten zum neuen wechseln kann … ja, man wird doch noch träumen dürfen. )
Die ganze Geschichte ist zwar gut gemeint, aber nicht gut gemacht. Was hätte den Proposal-Ersteller mit einer entsprechenden Begründung daran gehindert, mit der Proposal-Absegnung zugleich von vorn herrein einen automatischen Edit vorzusehen? Wenn solche Schlüssel geändert werden sollen, wäre das für mich naheliegend gewesen.
Den Massenedit hätte man besser machen müssen, ja. Aber an sich im Ergebnis sehe ich eine Verbesserung der Date Lesbarkeit und jetzt auch eine bessere Grundlage, um Qualitätssicherung auf dem neuen Tag anzuwenden. Ein Revert finde ich vergebene Liebesmüh, die für alle nur mehr Arbeit machen würde.
die Meinung kann man sicher vertreten, aber es wäre klar eine Änderung der bisherigen Praxis und würde den Proposals viel mehr Macht einräumen als es derzeit der Fall ist. Eine Handvoll Mapper könnte entscheiden, 100.000de Objekte von hunderten und tausenden Usern in einem Schlag umzutaggen, also in deren Tagging einzugreifen. Bisher ging es in Proposals darum, Ideen zu sammeln und Vorschläge zu erarbeiten, aber jeder konnte weiterhin taggen wie er wollte. Jetzt werden tags von den Objekten die ich gemappt habe (und tausende andere) entfernt mit dem Hinweis auf 20 Leute die im Wiki abgestimmt haben.
Es ist eins, einen neuen tag hinzuzufügen aufgrund von anderen tags am Objekt (automatischer Edit), und ein anderes, bestehende tags zu löschen, vor allem, wo es technisch keine Erfordernis gibt, weil der “alte” Key ansonsten nicht benutzt wird.