<html><head></head><body><div class="ydp6099832cyahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;"><div><div><span><span style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;">> I believe the issue is more about the unwillingness to take community feedback seriously at all when it doesn't coincide with the opinions already held by the developers. Which brings us back full circle to the discussion of the privileged position of the default editor on openstreetmap.org and the related transparency (aka who is holding the purse strings) and the non-existent community control or even just control by the OSMF.</span></span><br></div><div><span><span style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif;"><br></span></span></div><div>This is a very interesting paragraph, dense with deep topics for the OSM project. These topics should separate this from the particulars of individual situations, because the dynamics are not unique to any single component of the OSM data and software ecosystem. <span><span style="color: rgb(0, 0, 0); font-family: Helvetica Neue, Helvetica, Arial, sans-serif; font-size: 16px;">OSM has always been a muddle and arguably one of the reasons for its success. </span></span>In OSM people disagree, there's strong points of view and discussion, sometimes it resolves, often times we continue to muddle through. Yes, the OSMF has ultimately legal authority over all aspects of the project but by design and history, exercises it very selectively. And community is a very amorphous concept, with disagreements over what that means and how it functions. </div><div><br></div><div>Certainly the shape of the OSM project has outgrown the systems we haphazardly put in place for governance and community back in 2007. It's worth stepping back from many of the recent heated issues in the community, and look at how they are the result of growth without intentional adaptation, and consider what kind of approach we can take to imagine what OSM is like in the next 15 years.</div><div><br></div><div>-Mikel</div><div><br></div><div class="ydp6099832csignature">* Mikel Maron * +14152835207 @mikel s:mikelmaron</div></div>
<div><br></div><div><br></div>
</div><div id="yahoo_quoted_7706287071" class="yahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div>
On Thursday, May 9, 2019, 5:56:14 PM EDT, Simon Poole <simon@poole.ch> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div id="yiv2981659117"><div>
<p><br clear="none">
</p>
<div class="yiv2981659117moz-cite-prefix">Am 09.05.2019 um 23:14 schrieb Mikel
Maron:<br clear="none">
</div>
<blockquote type="cite">
</blockquote></div><div><div class="yiv2981659117ydp28784ea9yahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;">
<div>
<div>
<div>
<div dir="ltr" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;">> What do you think?
Should the next version of iD be deployed on
<a rel="nofollow" shape="rect" class="yiv2981659117moz-txt-link-abbreviated" target="_blank" href="http://www.openstreetmap.org">www.openstreetmap.org</a>?</div>
</div>
<br clear="none">
</div>
<div>Absolutely. My understanding is this feature will greatly
improve data quality in OSM. I think it's fair to validate
squareness of existing buildings. Appreciate the great work
of the iD team. </div>
<div><br clear="none">
</div>
</div>
</div>
<p>The question was not about validating square or not square
buildings, it is about storing a hint for iDs validation mechanism
permanently in OSMs data. There is some precedent for doing so, as
was mentioned in the github issue, still it is a bit controversial
and discussion when adding such a feature should be expected. <br clear="none">
</p>
<p>[Rant on the massively overrated concern for buildings in the
first place and the background why people think that such a
validation is necessary omitted]</p>
<blockquote type="cite">
<div class="yiv2981659117ydp28784ea9yahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;">
<div>
<div>Also commend your attention to tagging issues Michael.
There's certainly a broader issue with how tags are managed
in OSM. In short it's a mess all around and is in need of a
rethink. I don't think this minor issue is a "hill to die
on" however.</div>
</div>
</div>
</blockquote>
<p>I believe the issue is more about the unwillingness to take
community feedback seriously at all when it doesn't coincide with
the opinions already held by the developers. Which brings us back
full circle to the discussion of the privileged position of the
default editor on openstreetmap.org and the related transparency
(aka who is holding the purse strings) and the non-existent
community control or even just control by the OSMF.<br clear="none">
</p>
<p>Simon</p><div class="yiv2981659117yqt8102198110" id="yiv2981659117yqtfd53993"><br clear="none">
</div><div class="yiv2981659117yqt8102198110" id="yiv2981659117yqtfd11691">
<blockquote type="cite">
<div class="yiv2981659117ydp28784ea9yahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;">
<div>
<div><br clear="none">
</div>
<div>-Mikel</div>
<div><br clear="none">
</div>
<div class="yiv2981659117ydp28784ea9signature">* Mikel Maron * +14152835207
@mikel s:mikelmaron</div>
</div>
<div><br clear="none">
</div>
<div><br clear="none">
</div>
</div>
<div class="yiv2981659117yahoo_quoted" id="yiv2981659117yahoo_quoted_7595470285">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div> On Thursday, May 9, 2019, 4:18:20 PM EDT, Michael
Reichert <a rel="nofollow" shape="rect" class="yiv2981659117moz-txt-link-rfc2396E" ymailto="mailto:osm-ml@michreichert.de" target="_blank" href="mailto:osm-ml@michreichert.de"><osm-ml@michreichert.de></a> wrote: </div>
<div><br clear="none">
</div>
<div><br clear="none">
</div>
<div>
<div dir="ltr">Hi,<br clear="none">
</div>
<div dir="ltr"><br clear="none">
</div>
<div dir="ltr">this could be seen as a tagging discussion
but I think that it is a<br clear="none">
</div>
<div dir="ltr">discussion on governance and power. That's
why this email goes to the<br clear="none">
</div>
<div dir="ltr">Talk mailing list.<br clear="none">
</div>
<div dir="ltr"><br clear="none">
</div>
<div dir="ltr">Quincy Morgan, one of the maintainers of iD,
invented a new tag called<br clear="none">
</div>
<div dir="ltr">nosquare=yes today which should be added to
buildings which are not<br clear="none">
</div>
<div dir="ltr">square and should not be flagged by iD's
validator. I (and later Paul<br clear="none">
</div>
<div dir="ltr">Norman) pointed out issues with the tag. I
asked Quincy to discuss the<br clear="none">
</div>
<div dir="ltr">addition with the wider community beforehand.<br clear="none">
</div>
<div dir="ltr"><br clear="none">
</div>
<div dir="ltr"><a rel="nofollow" shape="rect" target="_blank" href="https://github.com/openstreetmap/iD/issues/6332">https://github.com/openstreetmap/iD/issues/6332</a><br clear="none">
</div>
<div dir="ltr"><br clear="none">
</div>
<div dir="ltr">Here are the issues I pointed out in the
bugtracker. At the beginning he<br clear="none">
</div>
<div dir="ltr">planned to use square=no which he later
changed to nosquare=yes but this<br clear="none">
</div>
<div dir="ltr">change does not make things better:<br clear="none">
</div>
<div dir="ltr">> Although noname=yes is common, it is not
that common that it can serve as an argument in favour of
introducing unsquare=yes. In difference to noexit=yes,
unsquare=yes and noname=yes only serve as a workaround for
quality assurance tools. noexit=yes also conveys
information for map users: There road ends here.<br clear="none">
</div>
<div dir="ltr">> <br clear="none">
</div>
<div dir="ltr">> Some people prefer to tag as complete as
possible and add oneway=no, cycleway=no, lit=no etc. to
any way. However, such a practice is not base on a broad
consensus and if you dig deep enough in the history of
user blocks in OSM, you might find blocks set due to an
excessive use of negative binary tags.<br clear="none">
</div>
<div dir="ltr">> <br clear="none">
</div>
<div dir="ltr">> I think that iD does not need this tag
and should only validate buildings if they have been added
or modified in the current session. If doing so, they will
be reported once which does not bother that much.<br clear="none">
</div>
<div dir="ltr">> <br clear="none">
</div>
<div dir="ltr">> Adding such a tag is not a simple change
as it might seem to be and I ask you to discuss it with
the broader community on the Tagging mailing list.<br clear="none">
</div>
<div dir="ltr"><br clear="none">
</div>
<div dir="ltr">What do you think? Should the next version of
iD be deployed on<br clear="none">
</div>
<div dir="ltr"><a rel="nofollow" shape="rect" class="yiv2981659117moz-txt-link-abbreviated" target="_blank" href="http://www.openstreetmap.org">www.openstreetmap.org</a>?<br clear="none">
</div>
<div dir="ltr"><br clear="none">
</div>
<div dir="ltr">Best regards<br clear="none">
</div>
<div dir="ltr"><br clear="none">
</div>
<div dir="ltr">Michael<br clear="none">
</div>
<div dir="ltr"><br clear="none">
</div>
<div dir="ltr"><br clear="none">
</div>
<div dir="ltr">-- <br clear="none">
</div>
<div dir="ltr">Per E-Mail kommuniziere ich bevorzugt
GPG-verschlüsselt. (Mailinglisten<br clear="none">
</div>
<div dir="ltr">ausgenommen)<br clear="none">
</div>
<div dir="ltr">I prefer GPG encryption of emails. (does not
apply on mailing lists)<br clear="none">
</div>
_______________________________________________<br clear="none">
talk mailing list<br clear="none">
<a rel="nofollow" shape="rect" ymailto="mailto:talk@openstreetmap.org" target="_blank" href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br clear="none">
<a rel="nofollow" shape="rect" target="_blank" href="https://lists.openstreetmap.org/listinfo/talk">https://lists.openstreetmap.org/listinfo/talk</a><br clear="none">
</div>
</div>
</div>
<br clear="none">
<fieldset class="yiv2981659117mimeAttachmentHeader"></fieldset>
<pre class="yiv2981659117moz-quote-pre">_______________________________________________
talk mailing list
<a rel="nofollow" shape="rect" class="yiv2981659117moz-txt-link-abbreviated" ymailto="mailto:talk@openstreetmap.org" target="_blank" href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a>
<a rel="nofollow" shape="rect" class="yiv2981659117moz-txt-link-freetext" target="_blank" href="https://lists.openstreetmap.org/listinfo/talk">https://lists.openstreetmap.org/listinfo/talk</a>
</pre>
</blockquote>
</div></div></div><div class="yqt8102198110" id="yqtfd37369">_______________________________________________<br clear="none">talk mailing list<br clear="none"><a shape="rect" ymailto="mailto:talk@openstreetmap.org" href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br clear="none"><a shape="rect" href="https://lists.openstreetmap.org/listinfo/talk" target="_blank">https://lists.openstreetmap.org/listinfo/talk</a><br clear="none"></div></div>
</div>
</div></body></html>