[Osmf-talk] [OSM-talk] Toward resolution of controversies related to, iD

[Allan Mustard]

> Message: 1
> Date: Tue, 9 Jun 2020 11:32:58 +0100
> From: ndrw6 at redhazel.co.uk
> To: talk at openstreetmap.org
> Subject: Re: [OSM-talk] Toward resolution of controversies related to iD
> Message-ID: <ef16dc43-f81b-f378-482e-2ce3c50aaab6 at redhazel.co.uk>
> Content-Type: text/plain; charset=utf-8; format=flowed
I believe ndrw6 has misunderstood much of the RFC.
> ...
> To me, OSMF wants the control of a project it hasn't developed but 
> turned out too successful to ignore, and to add insult to injury you are 
> asking the author to keep working on it by committing patches he 
> disagrees with.
No, OSMF wants an end to the controversy, not control.   Please re-read
the first two lines in the RFC:

> The OpenStreetMap Foundation Board of Directors *seeks to resolve
> controversies* that have periodically arisen around updates of and
> enhancements to the iD editor.  This request for comment (RFC) is
> expected to lead to *adoption of community structures that will not
> answer to the Board or be influenced by the Board*, in keeping with
> the OSM philosophy that the Board supports OSM but does not tell
> anybody what to map or how to map. 

> I see several problems with it:
>
> - It's deeply unethical. OSMF should foster the development of the OSM ecosystem, not harass people working on it. How does this fit OSMF own charter and CoC?
The OSMF is not harassing anyone.  In fact, this RFC was written in
consultation with iD developers.  It fits into the OSMF's charter to
support the project,
> (1) encouraging the growth, development and distribution of free
> geospatial data;
I do not understand your accusation that the proposal is "deeply
unethical".  Can you please explain what is unethical about it?
> - Taking control from the original authors would slow down, if not stall, the development of iD.
Please re-read this passage from the RFC:

> *OSMF is seriously considering creating or identifying a body to
> adjudicate various kinds of technology disputes*, capable of drawing
> on expertise ad hoc to determine the best path forward for the
> community. Software projects could opt-in into using this appeal
> process; it would not be required. This appeal process may simply
> involve arbitrating the disagreement between different parties or
> projects and helping to find agreement between them; or might involve
> making or overruling decisions.
Control would remain with the authors, but the authors would have the
option of requesting ("could opt-in") an appeal process to reduce
conflict and resolve disputes.
> - Giving the control to a committee would steer the development in a different direction (as in: "different from the current, good direction"). At very least it would give an excuse for rejected ideas to be pushed again.
See the previous point.  A committee would not "control" the project. 
It would adjudicate disputes on request.  Further it would draw "on
expertise ad hoc", meaning the composition of those involved would
change, depending on the type of expertise needed.  For example, a
dispute over a particular tag might involve seeking expertise from
individuals familiar with a particular industry.  As for rejected ideas,
since the developers are the ones deciding whether to "opt-in", that
isn't really a concern.
> Frankly, I would rather have iD hosted elsewhere and being developed further to the benefit of a broader OSM community.
I don't understand this point.
> Better yet, talk to each other and come up with a workable plan. 
That's what we are doing right now.  This RFC is a "request for comment" :-)
> OSMF proposal is very one-sided and disproportional, what is _OSMF_ willing to compromise on to improve cooperation?
I don't see your point here.  OSMF is proposing either to create an
independent body to adjudicate disputes, if if one is willing, to ask an
existing body to adjudicate disputes.  OSMF itself will not control that
body or its decisions, i.e., once created, it will be out of the OSMF's
control.  What more could the OSMF give up as part of a compromise?
> Bye
>
> Ndrw
cheers,
apm

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osmf-talk/attachments/20200609/899a943e/attachment.htm>