[OSM-dev] Removing functionality and giving just No as answer

Tom Hughes tom at compton.nu
Fri Feb 24 17:23:51 UTC 2017


On 24/02/17 17:15, Дмитрий Киселев wrote:

>     The key thing is that you need some mechanism for appointing people
>     to that circle of maintainers who get to vote on which things should
>     be included and which shouldn't. On most projects that is done by
>     promoting from those making useful contributions, so it's hard to
>     move in that direction until we can get more people involved.
>
>
> Going that way, maintainer will fall into approval buble, people who
> shares maintainers vision have higher chance to become a "good" committer,Â
> so feedback from users who doesn't share yours vison become smaller and
> smaller.

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?

> I agree that comments on gh isn't the message board, and not all commits
> should be applyed and authours/maintainers vision should be respected,Â
> but now we are in quite a weird state:Â

Well that completely contradicts your previous paragraph.

You can't say that there should be a person or persons in charge of 
looking after the overall vision and deciding what fits and what doesn't 
and then say that somehow feedback from "enough" users can somehow 
override that.

> We have discussion and voting procedure for tags even for the very
> specific tags, like electrical power scemes.

Which works because the real mappers then just ignore the vote and carry 
on as before ;-)

Seriously, the wiki tag voting is not a good example for, well, anything 
really.

> But for software, the community have no way to affect pull requests or
> roadmap items.

Anybody can effect the "roadmap" because we don't have one. Like most 
open source projects we don't have people we can instruct to follow some 
roadmap so we rely on people writing code and offering it so that is how 
you affect the roadmap.

Yes if you're not a programmer then that doesn't help you but I'm not 
sure what else would - you can propose things on github until you're 
blue in the face but if there's nobody interested in implementing them 
then it's not going to happen.

As to "affecting pull requests" what I'd really love is a concrete 
proposal of how you think this would work - are you really suggesting 
that if enough people say "+1" then it should go in no matter what the 
maintainer(s) think of it? I think if you do that you will have trouble 
keeping maintainers involved.

Tom

-- 
Tom Hughes (tom at compton.nu)
http://compton.nu/



More information about the dev mailing list