[OSM-dev] Removing functionality and giving just No as answer
wduffee at gmail.com
Fri Feb 24 17:50:44 UTC 2017
I'm new to OSM @dev but I see a couple of items that have come up on this
thread I wanted to try and note...
First, what is actually the request in Issue 1446? Yes, the word-by-word
request is to add the entry back to the right-click menu, but it seems a
little more than that. Useful (at least to some) functionality was removed
without replacement. While there is a browser workaround, that is
apparently not useable for everyone. I personally feel like Tom is correct
in saying that the entry doesn't need to be in the right-click menu for
everyone. But the functionality was removed from one location (the menu)
without it being provided elsewhere - that changes the discussion from
being one of UX and shifts it to dictating what users should and shouldn't
be doing with the tool.
The feeling I got from the Issue thread wasn't "the maintainer doesn't see
this functionality as being appropriate for the right-click menu" but
rather "the maintainer doesn't want to provide that functionality to the
user at all". That's likely not what the maintainer meant, but I feel like
that's what came out. And the more there was push back on adding that
functionality *in the menu*, the more the requestors pushed to add it
because they missed the functionality.
I honestly don't think that anyone cares if it is in the right-click menu
for everyone, just that it is available to those users who want it. Perhaps
long-term there could be an "advanced" or "developer" or "kitchen sink"
mode which can be set in the users profile, which enables these kinds of
menu entries while keeping the base UI cleaner? In the mean time since
there is a PR already, why not add it back into the menu?
The second issue is something I've seen arise up a few times on the dev@
list...who sets the agenda. I agree with Dmitry: "the community have no way
to affect pull requests or roadmap items." Of course open source isn't
purely a popularity contest, but if the push back from maintainers is (as
in this instance) "you aren't the norm" then naturally the person making
the request will gather people to +1 their request. That's not getting devs
getting railroaded, that's users advocating for themselves and their
Tom, when you say "Can you give me any example of an major open source
project that accepts changes on the basis of self appointed voting - ie
that says that so long as you can get N people to say they want it then it
should go in no matter what?" that's an oversimplification of the way open
source decisions are made and disingenuous. It comes back to organization
and transparency, and expectations of how many engineering resources are
available and what needs to be done by particular milestones. When the time
comes to prioritize however, if everyone assigns their vote to an issue and
nothing else is blocked...then...well, unless it is something clearly out
of line with the project's goals, then that's what is going to get done.
Right now it seems like there isn't a way to get code merged unless -
frankly - you want it to be there. There have been a number of complaints
(on all sides) about the lack of core contributors, but when a PR is made
for a relatively simple issue and then n'acked (as in this case) based on
one person's UX vision....then what message is that sending to potential
On Fri, Feb 24, 2017 at 11:38 AM, Дмитрий Киселев <
dmitry.v.kiselev at gmail.com> wrote:
> Ok, lets continue with our current
> "I'm the boss, that's why" approach.
> 2017-02-24 13:25 GMT-04:00 Yves <yvecai at gmail.com>:
>> I have personally three use cases:
>> a) trigger a faster? rerender in a mapping situation I'm not sure of
>> b) compare a tile with another
>> c) get the tile scheme right zyx or zxy?
>> dev mailing list
>> dev at openstreetmap.org
> Thank you for your time. Best regards.
> dev mailing list
> dev at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev