<div dir="ltr"><div>Hi</div><div><br></div><div>I second the comments of Topographe below. Continuous improvement is a major challenge.</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le dim. 18 oct. 2020 à 23:09, Martin Koppenhoefer <<a href="mailto:dieterdreist@gmail.com">dieterdreist@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>And once we have done it, we could do it again and again, for all kinds of reasons.</div></div></div></blockquote><div>Not all kinds of reasons: once the change has been reviewed, voted, discussed by the community for a significant amount of time.</div><div>Providing a technical efficiency or a given tool doesn't mean we should overuse that tool.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div>The problem is not the data at the origin, it is the system around the database.</div></div></div></blockquote><div><br></div><div>If the system isn't suitable enough, let's improve it.<br></div></div></div><div>For instance: among other things, versions keep a record of a manual edit of a particular user and allow change reversal.</div><div>Once a big change like man_made => human_made has been reviewed and acknowledged by the community, do we need a formal version to reverse it?<br></div><div>How many DWG changesets have been reversed in the past?</div><div>I think the need to create versions for this particular kind of change is very low.</div><div><br></div><div>All the best</div><div><br></div><div>François<br></div><div><br></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 19 oct. 2020 à 08:55, Topographe Fou <<a href="mailto:letopographefou@gmail.com">letopographefou@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="background-color:rgb(255,255,255);background-image:initial;line-height:initial"><div id="gmail-m_7108958130540194530response_container_BBPPID" style="outline:currentcolor none medium" dir="auto"> <div name="BB10" id="gmail-m_7108958130540194530BB10_response_div_BBPPID" dir="auto" style="width:100%"> Putting appart this 'man' vs 'human' debate...</div><div name="BB10" id="gmail-m_7108958130540194530BB10_response_div_BBPPID" dir="auto" style="width:100%"><br></div><div name="BB10" id="gmail-m_7108958130540194530BB10_response_div_BBPPID" dir="auto" style="width:100%">This reminds me a thinking I regularly have in minds: OSM shall have a way to tell all (registered) data users that "starting from yyyy/mm/dd following major change in the database will be applied following vote xxx from OSM community. Please see drawbacks, workarounds and recommandations for editors in wiki page www" . The idea would not be to trigger this mechanism every week but to be able to schedule few data scheme improvements in concertation with (and supervized by) a dedicated Working Group (DWG ? Or a contiunuous improvement wg ?). I think OSM already did it in the past and the wellspreading of its data shall not block us for improvements. Keys can be seen as arbitrary strings from a sw point of view but I think there is a benefit to have consistent keys, which may imply from time to time to review 10 years old tagging schemes. It can even simplify life of editors and data consumers.</div><div name="BB10" id="gmail-m_7108958130540194530BB10_response_div_BBPPID" dir="auto" style="width:100%"><br></div><div name="BB10" id="gmail-m_7108958130540194530BB10_response_div_BBPPID" dir="auto" style="width:100%"><br></div> <div id="gmail-m_7108958130540194530blackberry_signature_BBPPID" name="BB10" dir="auto">     <div id="gmail-m_7108958130540194530_signaturePlaceholder_BBPPID" name="BB10" dir="auto">LeTopographeFou<br>
</div></div></div></div></blockquote></div></div></div>