User:HAmap/LDMK/Workflow

Workflow

Weil wir mit unterschiedlichen Programmen, IT-Kenntnissen und Strategien editieren, kommt es leicht zu Datenschrott, oder auch Ärger. Qualitativ hochwertig und Fehler-minimierend wird Editierung mit diesem workflow:

• Jeder ist für seine Änderungen verantwortlich, dass sie korrekt sind. Es gibt systembedingt bei OSM kein zwingendes Review- und Freigabe-Verfahren, also ist Eigenverantwortung und Selbstüberprüfung gefragt.
• Jeder editiert im Bewusstsein, dass die Änderungen sofort online sind. Daraus ergibt sich die Notwendigkeit für vorsichtige und umsichtige Änderungen.
• Jeder (insbesondere ein Neuling) prüft eigenständig und zeitnah seine Edits mit mindestens einer passenden Endanwendung z.B. via https://www.openstreetmap.org/ oder OsmAnd (Zeitverzug beachten).
• Änderungen (Changesets) werden örtlich und im Elemente-Umfang möglichst klein gehalten, damit sie übersichtlich und leichter überprüfbar bleiben und ggf. leichter revertbar sind.
• Jede Änderung (Changeset) muss in sich abgeschlossen sein. D.h. es werden keine “Baustellen” in den OSM-Daten hinterlassen mit z.B. widersinnigen oder fehlenden Tags, kaputten Flächen usw. Es könnte ja sein, dass der Mapper aus welchen Gründen auch immer sein Werk nicht vollendet und eben diese Baustelle ins OSM zurück lässt.
• Bei testweisen Änderungen wird immer nur ein Objekt/Element/Ort (Ort hier z.B. nur eine Schleuse) geändert. Es wird sofort in mindestens einer passenden Endanwendung geprüft, ob das funktioniert hat oder ob etwas kaputt gegangen ist, um dann sofort ein Revert durchzuführen.
• Bei Änderungen (insbesondere bei testweisen), wo man sich der Korrektheit nicht ganz sicher ist, wird aktiv um Review durch andere gebeten.
• Wir nutzen das etablierte OSM-eigene Hinweis-System, um auf problematische oder fehlerhafte Changesets hinzuweisen, damit nix im Nachrichtenverkehr untergeht.
• Die Mapper arbeiten eigenständig und unabhängig voneinander. Koordination erfolgt nur in Hinsicht der örtlichen Aufteilung (Zuständigkeit für z.B. Kanal-Abschnitt Schleuse x bis y). Ziel ist den Kommunikations- und Abstimmungs-Overhead zu minimieren.
• Richtschnur sind neben dem Wiki die Festlegungen (z.B. Tagging) im Forum, dokumentiert auf der Projekt-Wiki-Seite.