openstreetmap-carto 🚀 - Project governing status

Oh come on. There are only 16 open PRs right now and your oldest one is barely 2 months old.

None of the maintainers is paid for the work on this style so you need to accept that available free time varies for them.

Don't get me wrong - as i have said before it would be great if decisions on changes were faster, in particular when the result is ultimately a rejection. And i think this could probably be improved without additional work load for the maintainers - by doing early reviews on suitability/prospects of the changes. But the idea that this is currently a particular issue and development is stalled by maintainer inactivity is fairly frivolous.

I would also like to encourage a bit more responsibility on side of the contributors here. I am currently reluctant to submit new changes because i have a fairly long list of things that could use improvement with my previous modifications and i feel it would be important to address these - even if it is difficult to find the time. I know there are some contributors here who regularly contribute followup changes and fixes for their own modifications and consider it their resposibility to do so but there are others with more or less a _don't look back_ approach. In principle that is fine, any contribution should be welcome. But it is certainly more valuable if the contributor also looks after his/her changes afterwards.

So to paraphrase a famous quote: _don't ask what your maintainers can do for you, ask what you can do for your maintainers_.

imagico on 13 Nov 2016

PRs may have been open only for short time, but there is quite the number of open tickets that need to be addressed. I know not all of them may be done at once, but what is holding that one? https://github.com/gravitystorm/openstreetmap-carto/issues/1504 I hear that this code needs to be implemented before more work comes in, yet like many other issues it is stagnant for many months.

wmyrda on 13 Nov 2016

PRs may have been open only for short time, but there is quite the number of open tickets that need to be addressed. I know not all of them may be done at once, but what is holding that one? #1504 I hear that this code needs to be implemented before more work comes in, yet like many other issues it is stagnant for many months.

The way to solve issues is more contributions, not more maintainers. If interest in an issue from maintainers was required to solve it, we could close half of the outstanding issues as wontfix.

We are discussing new maintainers internally, but need to ask them first.

pnorman on 13 Nov 2016

Still contributions seem as not the only thing required. In example issue 1504 the code is ready if I read it right.

wmyrda on 13 Nov 2016

The way to solve issues is more contributions, not more maintainers.

I'm not quite sure actually. I think there is a strong causal relation between how quickly contributions are merged, and how many contributions we get.

matthijsmelissen on 13 Nov 2016

👍1

Still contributions seem as not the only thing required. In example issue 1504 the code is ready if I read it right.

No, there are open issues impacting the lua branch: https://github.com/gravitystorm/openstreetmap-carto/labels/lua. A specific issue is best discussed there

pnorman on 13 Nov 2016

I think the lua branch is kind of specific and I don't think it's relevant here. It's a big, "backbone" change and we're not having ready PRs just to merge, so it's still in a code developing stage and not a governing stage. It's where Paul is wearing contributor's hat. The only thing in common is lack of information - when I knew I could test something, I just did it, but now I'm not sure what is needed and who could help.

I don't want to push anyone to do (or not to do) anything. It's absolutely not a problem of anybody being "lazy". It's not a problem of being paid - nobody is, probably, we're all volunteers here and I appreciate the work on writing issues and code the same as I do appreciate the work on deciding and merging. But when I (as a contributor) "ask what you can do for your maintainers", I simply _don't know_, so I feel there's kind of invisible bottleneck. My loop as a contributor is broken and I'm not even sure my work is useful here. This is the problem I try to describe here.

I'm happy with the project starting to be aware of contributors community. We have CoC and we (as a project) learned how to talk to the people - that's just great! That's probably why people become active and try to do something. I see it exactly the way Matthijs said: "I think there is a strong causal relation between how quickly contributions are merged, and how many contributions we get." Communicating, deciding and merging is important for people to be properly guided and happy to do more. Managing volunteers is important and it's a part of healthy open project.

kocio-pl on 14 Nov 2016

👍1

Regarding _strong causal relation between how quickly contributions are merged, and how many contributions we get_:

This might be the case but i don't think this project is in the long term limited by the number of contributions. If i have a look at how the map changed in styling over the last years most clear improvements are the result of slow, considerate work that was not just quickly made and quickly merged. If i have a look at the open issues a significant number of them are about problems introduced by changes that were noted soon after these were made but that were not fixed since then. This is why i called for more responsibility on side of the contributors - quality of contributions rather than quantity.

If you'd just decrease the latency when merging changes and this way encourage more contributions this would (a) reduce pre-merge QA of the changes and (b) increase the number of unsolved issues with the style since it is always easier to introduce a new feature than to solve a problem introduced by a feature addition that was not recognized when the change was originally made.

I simply don't know, so I feel there's kind of invisible bottleneck.

Well - if you have that impression it would be ridiculous of me to deny it of course but if i look at the currently open PRs there are five from you with new feature additions (and in general of the 16 open PRs the vast majority are either feature additions or subjective styling 'improvements' in contrast to objective fixes for styling or technical issues). We have 386 open issues many of which as said are problems with previous changes with obviously also several regarding your changes. I think focusing on fixing these would be a very important contribution and in line with _doing something for the maintainers_. Merging a basic fix for an existing problem is much easier than weighing the advantages and disadvantages of a feature addition or a subjective styling change regarding if it is an overall improvement.

I'm not even sure my work is useful here.

The main reward for contributing is usually having improved the map - and due to the prominence of the main OSM map and its importance for mapping this is quite a significant reward. So the question you should probably ask yourself is: _have my changes improved the map_ and _can i change the focus of my work to make it better_. My assessment of your contributions would be yes in both questions - but that is my subjective impression of course.

imagico on 14 Nov 2016

Yet @gravitystorm is in practice not active here for a long time, rarely even giving some advice or expressing his thoughts on general issues.

Yes, unfortunately I have been rather busy elsewhere. At SotM @pnorman @math1985 and I got together to discuss the situation, and I volunteered to step down entirely if the others thought it was worthwhile, but I was asked to remain as a maintainer, despite my limited availability.

We also discussed appointing new maintainers, and there were three candidates nominated. I've now invited them all and have had responses from two of them so far, so please welcome @kocio-pl and @imagico to the team.

Of course, this won't solve overnight all the problems, but I think it will help. I would like to re-iterate some of the points made above. I think it is worthwhile focussing on:

Creation and documentation of design goals. This makes decision-making more predictable and gives us an overall strategy, in addition to deciding each PR as it comes up.
Concentrating on fixing existing problems, in addition to dealing with new features.
I also believe we should focus our efforts on merging in the lua branch. Having a long-running split of effort is never the best idea, doubly so when there are a few people spread quite thinly.

Personally, I will be making more of an effort to keep up-to-date with reading the comment notifications (I'm again over 250+ notifications behind) and contributing where I can to the various discussions.

gravitystorm on 15 Nov 2016

👍3

Thanks for the invitation, Andy, and congratulations, Christoph! I hope joining new active team members will help us to better manage the project in the future. I've started with a bit of cleaning and like to continue that for some time to get used to the new tools.

For this moment I consider the governing status issue as resolved (very quickly!), so I'm closing it. However feel free to drop here any related comments, if you have one.

kocio-pl on 15 Nov 2016

Welcome to the team @kocio-pl and @imagico!

In the past, we worked on the principle that every PR should be reviewed by one other maintainer (maintainers don't accept their own pull requests). Let's stick with this principle, at least for now.

Also, in the spirit of open source development, let's keep having (policy) discussions in the open as much as possible (perhaps except for discussions concerning people).

With the addition of the new maintainers, @gravitystorm is taking a step further back. I think this is a good occasion to thank him for all the work he has put in getting the migration to cartocss to work, in maintaining the project, and in expanding the community. @gravitystorm, even if you don't have time to actually contribute code, high-level guidance on cartographic direction from your side is of course still very much appreciated.

Creation and documentation of design goals. This makes decision-making more predictable and gives us an overall strategy, in addition to deciding each PR as it comes up.

I very much agree with this. We should, as much as possible document, these changes in CARTOGRAPHY.md.

If i have a look at the open issues a significant number of them are about problems introduced by changes that were noted soon after these were made but that were not fixed since then.

@imagico Do you have some examples of these?

matthijsmelissen on 15 Nov 2016

In the past, we worked on the principle that every PR should be reviewed by one other maintainer (maintainers don't accept their own pull requests). Let's stick with this principle, at least for now.

I have observed some counterexamples here and there and thought that it's not that important, but your proposal is perfectly acceptable for me.

Also, in the spirit of open source development, let's keep having (policy) discussions in the open as much as possible (perhaps except for discussions concerning people).

That's exactly how I feel it and it looks like an established practice here.

@gravitystorm, even if you don't have time to actually contribute code, high-level guidance on cartographic direction from your side is of course still very much appreciated.

Sure! I would also like to thank you for the work you've done here - not only for the code and cartographic design, but also for the team building.

kocio-pl on 15 Nov 2016

👍2

@imagico Do you have some examples of these?

From the issues i opened recently: #1934 #2353 #2378 #2380 - of course the last ones are simply too fresh to expect a fix already (big changes with lots of side effects that require thorough consideration).

But i also had in mind the footway matter (#1793, #1748) and the tracks at z13/14 - see after merge comments in #747 and later issue #1591. And the general chaos of label/icon priorities at high zooms leading to icons and labels disappearing as you zoom in, changes keep adding features there but no one addresses the basic problems.

And to also appropriately kick me in my own butt - #1547, #2135 - the former hinges on water polygons of course.

imagico on 15 Nov 2016

👍1

I'll just add here - please also welcome @nebulon42 to the maintainers team!

gravitystorm on 16 Nov 2016

🎉2 👍2

With the increase in size of the maintainer team, we are going to try out a different review process. This only involves the reviews of pull requests made by maintainers, pull requests by others will be reviewed as always.

The new process:

A maintainer's pull request is (normally) merged by the maintainer that created it.
Before merging a pull request, the maintainer makes sure that the pull request has received sufficient review, both in terms of code quality and in terms of cartography. A pull request should have at least one review before it is merged.
The maintainer making the pull request allows for sufficient time for such review (the time needed depends on factors like complexity and impact of the pull request).
Maintainers should take into account feedback they receive. In particular, negative reviews should be a reason to seriously reconsider the proposal. However, in the end each maintainer is allowed to merge pull requests independent on the amount of positive or negative reviews, giving maintainers ownership of their own changes. If there is a review that requests changes and the pull request is merged there should be some reasoning why this was not taken into account.

The new review system will be used for 3 months (until the end of June), after which we will evaluate it.

matthijsmelissen on 2 Apr 2017

A bit off-topic, but still about project governance: "What it feels like to be an open-source maintainer" blog post - may sound familiar for some of you.

kocio-pl on 16 Apr 2017

👍1

3 months have almost passed since @math1985 has proposed self-merging PRs, so I reopen the issue to discuss it. I'm not sure if it was really used at all and it was not too active time frame (except for lua branch merging), but at least we know this process was not abused and is not the source of new problems, which is good.

I've just merged two PRs from @nebulon42 because I was convinced that was still preferred way of doing things, but it seems I haven't really understand the main principle - "A maintainer's pull request is (normally) merged by the maintainer that created it." And honestly I don't find it to be a major fault - merging by other maintainer means it's double-checked and somebody else find this change useful (not only acceptable). On the other hand it takes away a bit of maintainer's responsibility for his actions. But I think the ultimate goal is to make overall progress and current change rate is small, so I would just say that:

A maintainer's pull request is allowed to be merged by the maintainer that created it.

kocio-pl on 1 Jul 2017

I think the main issue with merging PR's of others is that we might merge things that the original author does not feel are ready (this has happened in the past under the old system). But I don't feel strong about this aspect - the main thing for me is that the original author has the possibility to merge his PR.

matthijsmelissen on 1 Jul 2017

👍1

I think review requirement just doesn't work in this project. Even big changes like https://github.com/gravitystorm/openstreetmap-carto/pull/2654 can have no one full formal review (only contributors are allowed to do this). Some PRs (bigger and smaller) are even not commented for weeks by anyone, which I read as just lack of interest. While it would be always good to have a peer review, this condition proved to be too strict.

kocio-pl on 31 Jul 2017

Even big changes like #2654 can have no one full formal review (only contributors are allowed to do this).

I don't believe this is correct - I'm certainly able to do reviews of PRs on other repos

pnorman on 31 Jul 2017

I was trying to formally invite somebody else for review and it looked like it's not possible, but I might just misunderstood how it really works.

kocio-pl on 31 Jul 2017

For an example of a review where I commented but didn't approve/request changes, https://github.com/openstreetmap/iD/pull/4166#pullrequestreview-53385791. I've done others where I've approved, but don't have one handy.

The request a review by someone else is newer, and I haven't made much use of it. We might not be able to request a review from someone who isn't a collaborator, but that doesn't stop anyone from reviewing.

pnorman on 1 Aug 2017

It’s out of topic here, I know (but I don’t know where to put it else):

For those who speak german: At http://www.spektrum.de/lexikon/kartographie-geomatik/ there is an online dictionary about cartography. Maybe it might help…

sommerluk on 7 Aug 2017

Following up from #2601 with https://github.com/gravitystorm/openstreetmap-carto/pull/2601#issuecomment-322678459 and https://github.com/gravitystorm/openstreetmap-carto/pull/2601#issuecomment-322702036:

It should be clear that the lack of discussion is directly related to the fact that concerns about changes seemingly do not matter any more. No one likes to put effort into reviewing and discussing changes if they have the impression their views do not find consideration.

I pointed out the possibility that this could become a problem very early when the idea of loosening the consensus principle and allowing maintainers to merge their own changes was first discussed (in private email conversation):

I am however generally a big proponent of resolving dissent through argument and
convincing the other side to change their mind. This would not be made
impossible by your proposed change but it would not really be encouraged.

imagico on 16 Aug 2017

My feeling is that lack of communication and decisions was here before - that's why I created this ticket.

I've been to the both sides of this (proposing and reviewing). What I don't like is for example:

making a code that nobody will review
making a code that probably won't be accepted
waiting to know if anybody will review and accept my code
not hearing the alternative solution
making a review when I'm not interested in the subject
making a review when I'm not an expert in this code or subject
being forced to do a review
waiting for the coder to respond

The safe choice in all these situations is to do nothing, but that's what I want to avoid in the first place. Lack of discussion means simply that convincing won't even happen. On the other hand it's hard to achieve agreement here when discussing and this leads to stagnation.

That's why I think one point in the new scheme (_"Before merging a pull request, the maintainer makes sure that the pull request has received sufficient review, both in terms of code quality and in terms of cartography. A pull request should have at least one review before it is merged."_) is not effective, because it still leads to stagnation - and this is my evaluation. All the other points are OK for me.

I prefer free discussion over silence, because it helps fix problems (but considering arguments does not mean agreeing with them) and for example 1 month deadline - if there's no review, there's no obstacle for a PR. This way nobody is forced to do a review, but if you're interested there's enough time and it's always better to speak, so stagnation is much less probable.

kocio-pl on 16 Aug 2017

❤1

It should be clear that the lack of discussion is directly related to the fact that concerns about changes seemingly do not matter any more.

Yes, but only in part. You experienced that very vividly in #2654. @math1985 chose to merge it and I'm not sure if I would have done that. I chose to close #2597 instead even if IMO this PR wouldn't have had so much impact. Merging of #2654 made things more complicated here for sure and this adds to what I write in the last paragraph.

The safe choice in all these situations is to do nothing, but that's what I want to avoid in the first place. Lack of discussion means simply that convincing won't even happen. On the other hand it's hard to achieve agreement here when discussing and this leads to stagnation.

That is also true. One has to recognize the fact that OSM is a do-ocracy. Those who do something are right. I'm not sure if that is essentially beneficial for this project or for a design project overall. On the other hand, I'm not able to offer better alternatives.

Speaking of which: I currently don't have the energy or resources to be able to do my job as maintainer properly. I was already forced to unsubscribe from all the notifications. So I only get notified if I'm directly mentioned (FYI). Additionally, I offer to step down as maintainer or just go into sleep mode for some time. I leave the choice up to your preference as I'm undecided what is better.

nebulon42 on 16 Aug 2017

👍1

I'm sorry to hear you're stepping back @nebulon42, but I understand different things sometimes take priority!

I chose to close #2597 instead even if IMO this PR wouldn't have had so much impact.

Did you close it because you stopped believing in the PR yourself, or because you felt there was not enough support? If you still believe in it yourself, you could have gone through with the PR as far as I'm concerned (if I recall correctly I was the only person against it).

Additionally, I offer to step down as maintainer or just go into sleep mode for some time. I leave the choice up to your preference as I'm undecided what is better.

I don't have a strong opinion - in the past we have let people remain a maintainer even if they did not contribute much.

matthijsmelissen on 16 Aug 2017

Let's have a look at current open PRs by the maintainers.

#2385, #2758 and #2751 are waiting for a review for less than a week.
#2699 is waiting for a review for over a week but less than a month.
#2671, #2673, #2743, #2746, #2454 are WIP and wait for the author to continue work on them.
#2700, #2732 are approved and wait for the author to merge them.

So in this case we have only one PR waiting for review for less than a week, and none waiting for review for less than a month. To me it also feels like reviews are sometimes slow, but the data does not support that at the moment.

matthijsmelissen on 16 Aug 2017

I don't have a strong opinion - in the past we have let people remain a maintainer even if they did not contribute much.

It doesn't bother me at all if some maintainers are not active, so it's not a problem for me.

One has to recognize the fact that OSM is a do-ocracy. Those who do something are right. I'm not sure if that is essentially beneficial for this project or for a design project overall. On the other hand, I'm not able to offer better alternatives.

This is what I believe also. It's hard to make everyone happy (except for some basic fixes) and trying to do this too much kills any progress. On the other hand it's good to have some input from the others before merging any code and sometimes changes are rejected, which is fine. I think healthy system should be balanced a bit more towards making changes and review process should not be designed to block changes by default, as currently (lack of review is enough to block anything), rather to make changes better.

That's why I'm proposing to test 1 month review deadline as an additional rule. We can also evaluate it after 3 months.

kocio-pl on 17 Aug 2017

That's why I'm proposing to test 1 month review deadline as an additional rule. We can also evaluate it after 3 months.

I would support this. I do say that with the hope that we won't actually need to use it: hopefully this will give us as reviewers the incentive to make sure every PR is reviewed by at least one of us within a month. But it's not fair to make people who wish to contribute wait for multiple months just because nobody feels like reviewing (which, I do admit, takes quite some time).

@imagico @pnorman What do you think?

matthijsmelissen on 17 Aug 2017

Did you close it because you stopped believing in the PR yourself, or because you felt there was not enough support?

Personally I was fine with the PR and I think I would have merged it after you merged #2654. But then again I didn't want to merge something in that was disapproved of by a fellow maintainer. And of course I didn't want to resolve all the merge conflicts that accumulated because it was held up so long.

nebulon42 on 17 Aug 2017

Well - my impression at the moment is that there usually is essentially no cartographic and only very limited QA review happening when changes from maintainers are merged - an observation which i think is also reflected in the number of after merge issues. So it would not really make much practical difference if there is a formal review requirement or not. I am strongly in support of the four eyes principle as a means to ensure some level of QA but like so many other things this can only work if the maintainers follow this with their heart and not just as an inconvenient rule you have to somehow work around. With the end of the consensus principle at least for me the incentive to do substantial review work is largely gone, at least for changes that are not particularly interesting or innovative either technically or cartographically.

The plan to review policy changes after some time is of course not really meaningful if the review criteria are not defined beforehand.

Regarding the concept of do-ocracy and how it applies to this project - @nebulon42 already mentioned that this might not work at all for projects with a design focus. I am not aware of any design projects at the moment following a do-ocratic system. This is an interesting subject though. Maybe @pnorman presents some thoughts on this in his SOTM talk tomorrow.

imagico on 18 Aug 2017

This post made me think about some interesting topics:

"Limited QA" sounds great to me - this way we can always make _some_ mistakes, but we also fix them quickly and the problems get solved fast. Trying to avoid _all_ mistakes takes more and more time and tends to avoid solving problems at all.
I also believe in gathering enough helpful remarks, ideas and warnings, not in formal reviews.
Consensus does not necessary mean "all or nothing", as you suggest.
This project is already do-ocratic - Andy and Steve Chilton are not controlling how their initial design evolves.

kocio-pl on 19 Aug 2017

I am not aware of any design projects at the moment following a do-ocratic system. This is an interesting subject though.

I would be very interested if anybody has some material on collaborative / open design and best practices in that field.

matthijsmelissen on 21 Aug 2017

I haven't found too much - this list looks (roughly) interesting, ~~but it's mostly on paper~~:

https://en.wikiversity.org/wiki/Open_design#Books.2C_articles_and_academic_papers

kocio-pl on 21 Aug 2017

Two interesting articles on @imagico blog which are referring to the subject of this ticket:

I might write my own articles on the same subject to show some other aspects of osm-carto development I see, but it's a great piece of writing - clear, insightful analysis of this project. Thanks!

kocio-pl on 6 Sep 2017

FYI: Andy has just enabled Collaborator status for @sommerluk - welcome on board!

kocio-pl on 18 Sep 2017

As we added collaborators, I am going to close this issue. Feel free to open more specific or related issues.

matthijsmelissen on 14 Oct 2017

For your information: I have changed my Github username from @math1985 to @matthijsmelissen.

matthijsmelissen on 29 Nov 2017

It looks like more people became involved lately both with icon design and proposing PRs. I'm not sure if this was the cause, but I think it helped that I started to explicitly invite people to do what they expect to have in this style, noting that it's not likely that it would be fixed by team members. I guess it's also important that I keep communicating with them - probably giving even the simplest feedback is good ("this should be fixed", "I think this is pretty good"). That's not clear if Docker containers are important, but I guess that without this groundwork we wouldn't see most of these contributions.

I hope that over time people will try to learn osm-carto and fix issues more actively.

kocio-pl on 11 Feb 2018

👍2

Yes, great work from your side @kocio-pl !

matthijsmelissen on 11 Feb 2018

The funny thing is that I was just overwhelmed with requests and lack of time to take care of them, so I basically just wrote about it clearly. It was a surprise for me that people reacted with growing activity, not complaints that it's too complicated...

kocio-pl on 11 Feb 2018

If anybody is interested in CartoCSS, please look at its current (un-)maintained status - JavaScript volunteers wanted: https://github.com/mapbox/carto/issues/495#issuecomment-412987738

kocio-pl on 14 Aug 2018

@kocio-pl wrote (at top): "It's still one man the project relies on for day-to-day operations. In my opinion this is not healthy situation"

As a new / potential contributor, I'm getting the impression that this has become the case again, in a different sense: now one maintainer can make a PR and merge it, even if the majority is against the change.

I believe this will discourage new contributors, especially those (like myself) with limited programming skills, or from different cultural backgrounds.

Right now it feels like the issues that are fixed are those that the maintainers are personally interested in. Outsiders can get a PR approved if they can do the technical work, which requires a certain level of good internet access, a good computer system, English language skills and programming skills.

Also, the confrontational and direct tone of conversation in this project is standard for European/American technology projects, but it may be discouraging people from other cultures and backgrounds from contributing. I believe very men from non-Western countries are contributing, and few women from anywhere.

jeisenbe on 14 Sep 2018

❤1 👍1

@jeisenbe I'm not sure if I fully understand you. Why does one maintainer being allowed to accept his own PR discourage you? This shouldn't affect the way PRs of non-maintainers are treated, but maybe I'm missing something.

@imagico In the other topic you wrote: "reasoning with other opinions and convincing others of the merits of your change was necessary". I don't think it's true that reasoning and convincing is not necessary anymore. However, what has changed is that in the past the proposer needed to convince the others that his change is a good idea, while now the others need to convince the proposer that something is a bad idea. Nobody likes to push bad ideas through, so if things are merged with which you disagree, it means you haven't been convincing enough - either because the merit of your arguments, or because you don't present them clear enough.

matthijsmelissen on 14 Sep 2018

👍2

it means you haven't been convincing enough - either because the merit of your arguments, or because you don't present them clear enough.

There is also a possibility that PR proposer (and merger) and commenter have a different opinion, so they agree about facts and disagree whatever overall effect was beneficial.

To avoid putting unfairly all on commenter - it is also possible that whoever merges given PR was not giving sufficient attention to criticism.

matkoniecz on 14 Sep 2018

👍1

Also, the confrontational and direct tone of conversation in this project is standard for European/American technology projects, but it may be discouraging people from other cultures and backgrounds from contributing.

If you see anything specific that I can improve in my comments - let me know (via email to [email protected] or as comment in a specific PR/issue discussion).

Note that it is partially caused by fact that maintaining open source project is in general unpaid time-consuming hobby (see for example https://nolanlawson.com/2017/03/05/what-it-feels-like-to-be-an-open-source-maintainer/ ).

I believe very men from non-Western countries are contributing

I think that major problem here is economical situation - such hobby takes large amount of time what is not feasible for many people. So as result rich people are more likely to participate in such projects (rich on a global scale).

matkoniecz on 14 Sep 2018

No one person is creating this environment.

Yes, it's a product of the unpaid, volunteer open-source format, and our
shared priveleged status; globally rich and privileged people (eg
European-background white men) are going to be the most involved due to the
format, the language and the history of OSM and this style.

The best we can do is make it as friendly and easy as possible for new
contributors, include people without technical skills.

I've seen several cases where new contributors were offended or confused
when their new issue was closed with a short comment or marked wontfix.

So, when a contributor opens an issue or PR, click on their username before
responding, even if it is an obvious duplicate.
If this is their first contribution time on github, they will need a little
bit of explanation and encouragement.
Eg, instead of saying "this is a duplicate of ####" and closing, explain:
"Thank you for this good suggestion. We have been working on this issue
since , on this other issue page because... "
And include a short explanation for why it isn't yet solved; technical
limitation vs still debating vs someone needs to make a PR

I hope this isn't too much extra work, I certainly value all the unpaid
time that everyone is putting into this, especially the maintainers!

On Sat, Sep 15, 2018 at 6:20 AM Mateusz Konieczny notifications@github.com
wrote:

Also, the confrontational and direct tone of conversation in this project
is standard for European/American technology projects, but it may be
discouraging people from other cultures and backgrounds from contributing.

If you see anything specific that I can improve in my comments - let me
know (via email to [email protected] or as comment in a specific
PR/issue discussion).

Note that it is partially caused by fact that maintaining open source
project is in general unpaid time-consuming hobby (see for example
https://nolanlawson.com/2017/03/05/what-it-feels-like-to-be-an-open-source-maintainer/
).

I believe very men from non-Western countries are contributing

I think that major problem here is economical situation - such hobby takes
large amount of time what is not feasible for many people. So as result
rich people are more likely to participate in such projects (rich on a
global scale).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gravitystorm/openstreetmap-carto/issues/2436#issuecomment-421487654,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AoxshNVeqncZJDfeDa7VEKKhnLbsqyXzks5ubB2zgaJpZM4KwpIq
.

jeisenbe on 15 Sep 2018

👍1

This is very broad problem and I'm interested in it. So let me briefly present some of the current issues:

When I opened this ticket, the project had a problem with keeping activity and I was just a frustrated and motivated contributor. Soon the changes has been made with the team and rules. It was however not enough for a long time and I felt disappointed, as new collaborators did not pick the baton too much. Lately new team of active contributors is taking shape and I'm doing big part of leadership just because no other collaborator is too active, especially with merging and discussing things. I'm happy with this team building experience and my goal is to eventually make this formal, granting them collaborator status. This level is still not achieved yet, as people are still learning tools and good practices, but it's happening. The biggest problem here seems to be the natural split between coding and managing skills/interests. I have no good solution for this yet, but I'm still thinking. Any ideas?
I think that a single most powerful encouragement tool was simply asking question "would you like to solve this (do the coding)?". Only few people try, but it created a feeling that there's nothing to wait for and action are welcome. We had issue ticket devaluation, since people were obviously thinking that opening it will solve their problems (so closing will harm solving it), but it had no effect other than documenting it. This is no longer the case, issues are being monitored, picked, discussed, fixed and closed on a regular basis.
Some other important factors for this revival are simpler way of installing development environment, time based releases, communicating, making decisions and allowing bugs to happen. As strange as it may sound, it helps to make better learning and team experience. I like especially the latest case of fixing pixel aligning of icons, where the people not only started to care about details like SVG code, without enforcing it while discussing PRs, but they have also found similar bugs with earlier icons. For me it's impressive proof that gradual tuning instead of setting high bar for a start works better for both quality assurance and keeping the project alive.
Making project more friendly for the people, encouraging them more to participate and supporting diversity is still possible. The biggest missing piece until now was lack of people representing different cultural (or gender) background, as it's hard and even pointless to pretend to understand people with different needs. I was trying to improve it by announcing planned changes with font rendering for different parts of the world, but it failed. With such a small team even single person makes a big difference and I feel this is good opportunity to try. @jeisenbe - thanks for your comments, would you like to take care of this? Do you have more ideas how to improve community experience when dealing with OSM Carto project? What would you like to do yourself to help with it?

kocio-pl on 15 Sep 2018

@matthijsmelissen - i think you perfectly described the problem of this change in procedure. By not requiring a change to defend itself against critique any more but instead requiring opponents of the change to achieve unanimity among maintainers against it (though to be fair in most cases a consensus among maintainers against the change was usually sufficient) you fundamentally changed the balance of the project.

As said before serious argument aimed at convincing and reasoning as opposed to what i would more characterize as _campaigning_, that is presenting observations meant to sway the public opinion in favor of a change, has mostly vanished from this issue tracker.

To be more precise i should have said: Listening to and considering critical arguments and reasoning is not required any more and because of that attempts to present serious arguments have mostly stopped. As a result you have for example also changes that are re-submissions of previously discussed and rejected changes (like #3372) which are pursued without arguing the previously given reasons for rejection.

The observations of @jeisenbe are somewhat related to that - giving up on maintaining a consensus about the direction of the project led to the development of fairly homogeneous and non-diverse fractions among developers the members of which seek confirmation mostly among their peer group. Communication across the borders of these groups is becoming increasingly dysfunctional. This likely makes the project attractive for people who fit into one of the fractions (and the only active fraction currently is essentially one of European mappers focusing on feature additions in Central European urban areas) but it is unattractive to developers who are not satisfied with developing their changes within their peer group but instead want to participate in a project based on common values and a common vision actually aiming to create a global map for the whole OSM community.

imagico on 15 Sep 2018

Thank you, @kocio-pl

I appreciate the work being done here and I think everyone has the best of
intentions.

Including more people from different countries and cultures is a big
challenge for any project, especially something that looks so technical.

Perhaps there are people working on the Humanitarian style who could be
encouraged to contribute on this style as well? I believe most of them
would still be Westerners, but perhaps with more experience in non-Western
countries.

Cyclists and hikers also have a different perspective on what's important
on the map. Perhaps more contributors from those groups would help balance
out the focus on urban areas?

I will do my part to contact mappers who have already been active here in
Indonesia. And I'll encourage my bike friends back in Oregon to get
involved. I don't think I will end up as a regular contributor, considering
the technical learning curve to make PRs, and my lack of reliable internet
service.

On Sat, Sep 15, 2018 at 2:00 PM kocio-pl notifications@github.com wrote:

This is very broad problem and I'm interested in it. So let me briefly
present some of the current issues:

1.

When I opened this ticket, the project had a problem with keeping
activity and I was just a frustrated and motivated contributor. Soon the
changes has been made with the team and rules. It was however not enough
for a long time and I felt disappointed, as new collaborators did not pick
the baton too much. Lately new team of active contributors is taking shape
and I'm doing big part of leadership just because no other collaborator is
too active, especially with merging and discussing things. I'm happy with
this team building experience and my goal is to eventually make this
formal, granting them collaborator status. This level is still not achieved
yet, as people are still learning tools and good practices, but it's
happening. The biggest problem here seems to be the natural split between
coding and managing skills/interests. I have no good solution for this yet,
but I'm still thinking. Any ideas?
2.

I think that a single most powerful encouragement tool was simply
asking question "would you like to solve this (do the coding)?". Only few
people try, but it created a feeling that there's nothing to wait for and
action are welcome. We had issue ticket devaluation, since people were
obviously thinking that opening it will solve their problems (so closing
will harm solving it), but it had no effect other than documenting it. This
is no longer the case, issues are being monitored, picked, discussed, fixed
and closed on a regular basis.
3.

Some other important factors for this revival are simpler way of
installing development environment, time based releases, communicating,
making decisions and allowing bugs to happen. As strange as it may sound,
it helps to make better learning and team experience. I like especially the
latest case of fixing pixel aligning of icons, where the people not only
started to care about details like SVG code, without enforcing it while
discussing PRs, but they have also found similar bugs with earlier icons.
For me it's impressive proof that gradual tuning instead of setting high
bar for a start works better for both quality assurance and keeping the
project alive.
4.

Making project more friendly for the people, encouraging them more to
participate and supporting diversity is still possible. The biggest missing
piece until now was lack of people representing different cultural (or
gender) background, as it's hard and even pointless to pretend to
understand people with different needs. I was trying to improve it by
announcing planned changes with font rendering for different parts of the
world, but it failed. With such a small team even single person makes a big
difference and I feel this is good opportunity to try. @jeisenbe
https://github.com/jeisenbe - thanks for your comments, would you
like to take care of this? Do you have more ideas how to improve community
experience when dealing with OSM Carto project? What would you like to do
yourself to help with it?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gravitystorm/openstreetmap-carto/issues/2436#issuecomment-421531264,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AoxshN6cl3_jpOIxJO9R4nbvMuevPqtzks5ubIl7gaJpZM4KwpIq
.

jeisenbe on 15 Sep 2018

Cyclists and hikers also have a different perspective on what's important
on the map. Perhaps more contributors from those groups would help balance
out the focus on urban areas?

As far as I know, cyclists and hikers are currently overrepresented, not underrepresented in the team of maintainers.

matthijsmelissen on 15 Sep 2018

As far as I know, cyclists and hikers are currently overrepresented, not underrepresented in the team of maintainers.

For example I joined OSM with goal of mapping bicycle infrastructure in my city and making proper bicycle-oriented map, and one of my projects is to map every single bicycle parking stand placed by a local government.

See https://github.com/matkoniecz/bicycle_report https://github.com/matkoniecz/bicycle_report_generator_for_Krakow https://github.com/matkoniecz/bicycle_map_of_Krakow https://github.com/matkoniecz/bicycle_map_of_Krakow_in_Maperitive for some of my bicycle-related projects.

And mountain hiking together with cycling are among my favourite activities.

matkoniecz on 15 Sep 2018

@jeisenbe Oh, I see. Whatever you think you can do, including advocating OSM Carto other users outside global West, would be still better than us trying to guess what other parts of the world need. I'm interested to see if this could make our team more diverse.

kocio-pl on 15 Sep 2018

i think you perfectly described the problem of this change in procedure.

In my view extending team and change of rules helped the project to keep alive, because original problem was that OSM Carto team in 2016 was a shadow of a team in 2015. It sounds to me as if the change of rules had no reason and was a problem in itself and i think this is unfair. If the project was healthy, there would be no need to change anything, but it was already halting.

As a result you have for example also changes that are re-submissions of previously discussed and rejected changes (like #3372) which are pursued without arguing the previously given reasons for rejection.

Not only 2016 was much different for OSM Carto than 2015, but also 2018 is different than all previous years. I wrote how the database is different now and the style is not independent from the data it tries to visualize. OSM and OSM Carto are not static projects, the changes are constant and it's reasonable to follow them rather then deny to see their consequences.

giving up on maintaining a consensus about the direction of the project led to the development of fairly homogeneous and non-diverse fractions among developers the members of which seek confirmation mostly among their peer group.

Consensus rule together with lack of developers activity led the project close to the halt. I felt it was also showing lack of trust for collaborators. I don't know what was really wrong with this model, but the project stagnation was clearly showing that changes were needed.

I hope that new team will get formal eventually and maybe they will like to have some new rules. It's easier to change the rules in the living project than make people contributing to a dead one.

kocio-pl on 15 Sep 2018

👍1

@matkoniecz - do you think this style has become more hiking- and cycling-friendly in the last two years?

imagico on 15 Sep 2018

Eg, instead of saying "this is a duplicate of ####" and closing, explain

Good point, I will try to do that with newbie users.

matkoniecz on 16 Sep 2018

👍1

Speaking of governing - one of the most powerful governing tools is merging PRs. I wonder why it seems I'm the only one with such permissions who really does this?

Everyone can discuss things, open tickets, create PRs, and even track things (which is typical management stuff - like @Tomasz-W or @polarbearing are doing currently) being just plain GitHub users. Making releases is kind of janitor's work, because this is a single, not controversial, time-based decision, even if it requires having keys to all the important places. Closing discussion is merely tagging it as "closed" and locking is rarely used - moreover both have no direct influence on what gets rendered and how. Assigning new collaborators is also powerful governing tool, however it's very rare too. In a day to day operations merging is where the most of governing decisions are deployed.

kocio-pl on 17 Sep 2018

I wonder why it seems I'm the only one with such permissions who really does this?

In my case - because issue commenting can be done without access to a proper computer (for example - from phone). And when I have access to a proper computer I have many things on a TODO list competing for my attention. openstreetmap-carto is on it, but unfortunately keeps losing.

Also, commenting takes minutes. Review of PR takes for more time.

matkoniecz on 17 Sep 2018

❤1

I just started using new GitHub feature called "Pinned issues" (currently in beta). Since there can be 3 pinned issues and we have no place for general things in this project, I have pinned:

Good first issues (task list meta-ticket) #3298 - for introducing new developers
Roadmap / strategic discussion #1975 - for discussing general goals of this style
Project governing status #2436 - for discussing any issues with the project itself

I hope it makes sense, but feel free to comment.

kocio-pl on 21 Dec 2018

👍3

https://github.com/gravitystorm/openstreetmap-carto/issues/2436#issuecomment-260214722 from 2016:

The way to solve issues is more contributions, not more maintainers.

Well, we have quite different situation now after 2 years. We have constant flow of contributions (including designing new icons), there is a lot of discussions and research too, which is great, but we still lack of active reviewers with merging rights. Me making multiple Changelog edits just to get it straight for release and still doing stupid errors, even if I tried to avoid them, is a clear sign of too much work with checking PRs before merging.

What could help in the meantime, which does not require merging rights:

people doing independent tests of code and rendering of PRs
someone who could take care of updating the Changelog (it could be even better than we do now - see https://github.com/openstreetmap/iD/blob/master/CHANGELOG.md for example)

Any other ideas what else could be improved? Any volunteers?

kocio-pl on 21 Dec 2018

Whats the specific hang up about giving more people maintainer status or not? It would help incentive contributing. Especially with some people thinking that maintainers are the only ones who's feedback matters when it comes to changing PR's etc.

From what I know, the guy who runs iD editor gives people maintainer status after 10 contributions. I don't see why it wouldn't be doable here. Its ridiculous and impractical to expect @kocio-pl to do 99% of it. Plus, I get the impression everyone who currently have Maintainer status is from Europe. It would be helpful if there was an active maintainer on the other side of the pacific that wasn't beholden to European time and could do things in the dead zone when your all asleep or busy. Not to mention, its just healthy to a project if more people do administrative tasks. It should grow with the number of contributors if nothing else.

Adamant36 on 21 Dec 2018

Currently the only person who can grant maintainer ("collaborator" in GitHub) status is the creator and owner of the repo - @gravitystorm (Andy Allan). After he stepped back and moved on to other OSM activities, there was just one time when someone was given this status and it was just by simple message for all the maintainers and approval of this proposition. We have no special procedure for that, and together with very low activity from current maintainers that's probably the core of the problem. I just don't know what happens nor how could it be changed, exactly because there was almost no response lately.

Do you have some more knowledge about iD model of governing project?

kocio-pl on 21 Dec 2018

Currently the only person who can grant maintainer ("collaborator" in GitHub) status is the creator and owner of the repo - @gravitystorm (Andy Allan).

I just want to be clear here that the decision about adding more maintainers is not blocked by me - I'm happy to add any maintainer, whenever there is consensus among the existing maintainers to do so.

I'm not following the project closely at the moment, but I'm happy to add new maintainers if and when there is a decision.

gravitystorm on 27 Dec 2018

Whats the specific hang up about giving more people maintainer status or not?

So I don't have any "hangups", but I do have some of my own concerns.

Firstly, I think moving away from the "every PR needs an approver" model was the wrong choice. I chose that model, even for my own PRs, since that makes everyone equal. Everyone needed a maintainer to review their PR, even PRs made by maintainers. The role of the maintainer was then clear - the maintainers job is only to review other peoples work. And there was no need to become a maintainer if you weren't interested in reviewing other peoples work, since it didn't give you anything special - every PR was equal.

The current situation is different. Now a maintainer is has special rights - if you are a maintainer, you can make any changes you like, without any reviews. So it's obvious now that being a maintainer is special, and even if you aren't interested in reviewing other people's work, you can still feel the need to ask to be a maintainer so that you can merge anything that you are working on quickly and without waiting.

I would prefer to see the project return to the original setup. I don't think having maintainers merge their own work has led to any fundamental improvement to the project. I can understand that it's quicker and easier for maintainers just to merge their own work, but it would be better in the long term to instead find and motivate more maintainers. Everyone's work benefits from review. And I don't want to see contributors feel that the maintainer status is something to earn - it should be something to volunteer for.

In saying all this, I'm only one maintainer among many, and not particularly active either, so if the other maintainers disagree, then the project should go with the consensus.

gravitystorm on 27 Dec 2018

I think moving away from the "every PR needs an approver" model was the wrong choice.

Just to clarify: it is still the case that every PR needs to be reviewed by an (other) maintainer. So "if you are a maintainer, you can make any changes you like, without any reviews" is not true. Maintainers can merge their own PRs now, but only after review.

@gravitystorm Something I'm still struggling with, perhaps you have ideas on that: how would you resolve the situation where different reviewers/maintainers have opposite opinions on whether or not to merge a PR?

matthijsmelissen on 27 Dec 2018

I'd like to add some things to this, because I'm obviously part of this picture, but I prefer to wait few days more so @matthijsmelissen (and maybe others) could write more what they think about rules, new developers and the future of the project. Thanks @gravitystorm for your input.

kocio-pl on 27 Dec 2018

Just to clarify: it is still the case that every PR needs to be reviewed by an (other) maintainer.

Thanks, I stand corrected. My apologies for not understanding the situation.

However, from a brief look through recent PRs I can see examples where there is no review, or reviewer comments are not actually resolved before merging, so I would suggest that there is room for improvement and perhaps the original approach is still better.

@gravitystorm Something I'm still struggling with, perhaps you have ideas on that: how would you resolve the situation where different reviewers/maintainers have opposite opinions on whether or not to merge a PR?

"Build consensus and agreement through discussion and compromise, using a combination of the cartography guidelines and common sense."

Consensus doesn't mean unanimity, but there shouldn't be anything merged here against firm opposition from a maintainer. On the other hand, a maintainer shouldn't block a change without offering a very good reason, or another way forward. If there's opposite opinions on something that's not covered by the guidelines, then we can add more guidelines or update the existing ones.

I'm happy to help if there's ever situations that appear unresolvable.

gravitystorm on 28 Dec 2018

I haven't been involved for three main reasons. The first is that this is one of the more active OSM projects, and what time I have has been devoted to projects struggling or new projects. The second is I've been working with CartoCSS styles professionally, and that really takes away any desire to work with them for fun.

The third is that the project has turned in a direction that holds little interest for me. I can't pin down exactly when this happened, but it was sometime before 3.0.

I recall an email post (by @woodpeck perhaps) to one of the lists pointing out a change that they noticed and I noticed a change at about that point.

I haven't made a big issue of this because I don't know if I'd contribute under a different direction. In fact, there's an argument to be made that I shouldn't contribute, given the project is successful and my time is of more use elsewhere.

pnorman on 29 Dec 2018

I recall an email post (by @woodpeck perhaps) to one of the lists pointing out a change that they noticed and I noticed a change at about that point.

You might mean this post on osm-talk from June this year.

woodpeck on 29 Dec 2018

the project has turned in a direction that holds little interest for me

@pnorman I'd be very happy to hear more about that. Even if you're not planning to contribute, I think it would still be very useful for the current maintainers/contributors (at least for me it is) to hear your vision. Especially since you're following the project from a bit more of a distance, you might be able to see the bigger picture better than we do.

matthijsmelissen on 30 Dec 2018

I believe this is rather subject for #1975. Here I'd like to focus on how to steer the project (the decision framework and power structure).

kocio-pl on 30 Dec 2018

Good point.

matthijsmelissen on 30 Dec 2018

Another thing: we said that we require every PR to be reviewed by one other maintainer (but even an rejecting review is ok). This makes that not reviewing a PR at all has more force than writing a negative review (if there are no other reviews yet). I don't think that's desirable either. I wonder how other maintainers feel about the reviewing rights at the moment.

matthijsmelissen on 30 Dec 2018

As i have expressed many times in the past for me this is not primarily about formal rights but about a culture of critical evaluation of changes and making decisions based on arguments and reasoning - which i consider to be very similar to what Andy probably meant with _build consensus and agreement through discussion_.

Past discussions of this:

https://github.com/gravitystorm/openstreetmap-carto/issues/1630#issuecomment-385162596
https://github.com/gravitystorm/openstreetmap-carto/issues/2436#issuecomment-421548752
https://github.com/gravitystorm/openstreetmap-carto/issues/2291#issuecomment-242908868

But like Paul i am aware this is just my personal opinion and i don't know at all if such a change in work culture alone would lead the style into a direction that would enable and interest me to more actively contribute again here. The cartographic direction has changed massively in the last 1-2 years and consequently it makes sense that those who shaped this new direction develop the vision how to proceed from here. What i try to keep an eye on and if necessary strongly voice my opinion on is if style development fails to act in the basic interests of the OSM community and fulfill its obligations as the standard style of the OSM website.

What i have occasionally wondered in that context recently is if those who currently actively contribute here would actually be more happy and could work better if this style wasn't the OSM standard style and the default style on osm.org so they would not be subject to the obligations and requirements this comes with. I get the distinct impression that many currently active developers have rather little interest in considering and taking into account the breadth of global culture and geography when doing development work on this style and would be more comfortable if that was not mandated by the formal framework.

That might seem a merely theoretical question but as everyone knows i am a strong advocate of more diversity in community produced OSM map styles.

imagico on 30 Dec 2018

You might mean this post on osm-talk from June this year.

Ah, yes, that's it. I'm quoting most of it, since it brings up a few points I want to agree with.

What has happened instead is that the easier-to-handle v2.0 was
reasonably successful in attracting volunteers, and now we have a small
team instead of one person doing the style, which is great. But after a
while this small team has started milking the toolchain for all it's
got, and meanwhile the SQL queries are so complex that they threaten to
nullify any effort that has gone into making the style accessible to new
participants (or people who want to customise it).

At some point we switched from version numbers based on cartography to ones based on technical requirements, so it's hard to pin down where the change happened

So the ease of participating or customising has more or less already
gone down the drain; what's still good about OSM Carto is that at least
you can easily install it as-is on your own infrastructure (I regularly
do that for business clients), but I fear it is only a matter of time
until this aspect of usability, too, will be abandoned, and you will
have to run massive pre-computation jobs in order to even get your map
off the ground...

Ease of install is very important for me. I'd love more reusability, but there are limits imposed by the language we work in. I thought hard over even adding the recommended indexes. If we started requiring custom functions in C, pre-computation, difficult to install programs, or other steps, I'd fork the style and maintain a fork that was easy to install.

Personally speaking, the OSM Carto map has been good enough for me and
all my use cases for years now.

Likewise

If anything, I found the inflation of
icons and special cases a bit irritating.

Same.

I would love it if OSM Carto
could be split into a "bread and butter" style that is easy to work
with, easy on the eye and easy to render, and a "cartography
navel-gazing" add-on where we show off how we can render different track
patterns depending on the pebble size. We could then offer both on
openstreetmap.org (where the bread-and-butter style would be the default).

I think we need something where all the people who want everything rendered can focus. That used to be osmarender. Vector tiles are not a solution here, this is not a technical problem.

in https://github.com/gravitystorm/openstreetmap-carto/issues/2436#issuecomment-450533865

Especially since you're following the project from a bit more of a distance, you might be able to see the bigger picture better than we do.

If I were taking up a style based on osm-carto and sticking close to what I see as the original vision, I'd use the cartography from some point in the 2.x series, with the Mapnik 3 and database schema technical improvements. I'm not sure what the best technical way to do this would be, but the implication would be a lot fewer icons, more shops as dots, fewer items pushed to z19, etc. I'd aim development to be more concerned about cartography of what we have than adding new features.

pnorman on 31 Dec 2018

a lot fewer icons, more shops as dots, fewer items pushed to z19, etc. I'd aim development to be more concerned about cartography of what we have than adding new features.

you mind if I ask where the wants/needs of the mappers and community versus that of the maintainers plays into that? Its something I've been wondering for a while now as someone who has both done the coding for a lot of the new icons, but is also annoyed by them and wanted to focus on cartography more at the same time.

I think though if the icons weren't added that there would just be a string of repeated issues asking for them. Plus, for whatever reason, there doesn't seem to be the will or knowledge on the side of contributors to focus more on cartography. From being around here long enough, including during the transitional period a few years ago (although not as a contributor), it seemed like the cartography had mostly reached a "good enough" state and things naturally turned to more low hanging fruit like icons. Which brought in more people like myself that were able to develop the easier things, but don't necessarily have the time or knowledge to work on bigger picture things.

I'm not sure why they can't coexist. Just because there's a lot of icons now that clutter up the map some places, doesn't mean other things can't also be worked on. To me that's what a general map that has wider none specific usage is about. If its suppose to be customizable etc, then that would only work through implementing a bunch of things that people down stream could then pick to include in their own style or not.

I think a lot of it has to do with prioritizing the style as a mapper feedback mechanism over all else also. If the point of the style is to increase tag usage through rendering, it accomplishes that great. If it its be an attractive intuitive map for passerby's that just want to see a pretty map it isn't so good. I don't think the later is the main usage of the style though. At least not on the main website. There's already pretty apps out there that accomplish that goal way better then we could anyway. At least being a useful feed back mechanism for mappers is an achievable goal.

There's also no easy to decide what is or isn't included. 99% of the time excluding things just leads to pointless arguments and resentment by mappers who aren't cartography nerds or programmers. There's still no clear guideline for what numbers a tag needs to get an icon (and there shouldn't be because it varies). So its just better to include what's requested based on that. The other option is deciding to come up with clear guidelines, rejecting almost everything, and the style not really going anywhere as a result. Although, it would allow a few maintainers that don't actually contribute PRs anymore to stay busy rejecting issues, but my instinct and experience says it wouldn't lead to a cartographic renaissance (whatever that means. Its not like icons aren't cartographic and its only small fraction of PRs anyway. Although they do take up a lot more time and resources then they should).

(there was clearly a need for the z19 thing to and support for it by users. As is evidenced by the many issues related to icon blocking etc that it helped deal with. The only objections to it were by a few maintainers that never posed a viable solution).

Adamant36 on 31 Dec 2018

👍1

@pnorman @Adamant36 These are very important questions, just not for this ticket. It does not help to answer how to manage the project at all, which is also very important problem, so please focus on it here.

kocio-pl on 1 Jan 2019

👍1

we said that we require every PR to be reviewed by one other maintainer (but even an rejecting review is ok). This makes that not reviewing a PR at all has more force than writing a negative review (if there are no other reviews yet).

I think there might be some problem here that I might have caused in the past by not being careful with my language. If there's a review that highlights some problems with the PR, those problems must be resolved, and the original reviewer should confirm that the problems are resolved, before merging.

We shouldn't have the case where a PR receives a review that requests some changes, and then it gets merged anyway because it's "been reviewed". That's not the point of getting reviews! There should be no difference between a "rejecting review" and "not reviewing a PR at all" since neither of those are permission to merge.

gravitystorm on 2 Jan 2019

"Build consensus and agreement through discussion and compromise, using a combination of the cartography guidelines and common sense."

I feel like I need also to take a step back on this and discuss a wider point. I would like the above to be possible, but it's not yet clearly demonstrated that it is actually possible to achieve good results using this method.

An alternative method is that instead of having a peer group of maintainers building a strategy collaboratively, instead the 'vision' could be held by just one person who has a final say in all matters. This could be seen as easier to achieve when it comes to creative works like this project, rather than technical works like software development.

As I said, I'd prefer to see the collaborative peer-group approach that I've outlined work, but we should bear in mind that it's not actually yet proven to work in the long term, and that we could do something entirely different.

gravitystorm on 2 Jan 2019

👍1

Before I start asking more detailed questions, how do you define "review"? I mean what is necessary to say the review was done (for example who can do it)?

kocio-pl on 2 Jan 2019

I find it quite hard at the moment to find pull requests that can be reviewed/merged, versus tickets that are still being worked on. We have quite a lot of long tickets, and it currently takes quite a lot of reading to see what the actual status is.

I'd propose adding the prefix [WIP] (work in progress) to pull requests that still need work - this prefix can be added both by maintainers and authors. (Note that we cannot use tags for this as non-maintainers cannot modify tags.)

matthijsmelissen on 2 Jan 2019

👍1

Before I start asking more detailed questions, how do you define "review"? I mean what is necessary to say the review was done (for example who can do it)?

I don't have any formal step-by-step instructions for what counts as a review, and I don't think they are necessary. A review is when a maintainer makes comments on a pull request, regarding the proposed changes. If the maintainer indicates that they are happy with the changes, then great. If the maintainer indicates that they are not happy (either overall, or on some specific point) then the PR should not be merged until the maintainers concerns have been fixed.

gravitystorm on 3 Jan 2019

OK, that's clear enough for me, so your definition seems to be:

review is not any technical solution (like GitHub request), any comment can be review
only maintainer comments count as review, and I guess you mean people with merging rights

Next important question - what if there's only one active maintainer and he tries to pull the code?

kocio-pl on 3 Jan 2019

Code reviews are a common practice, so I also don't think there are explicit step-by-step instructions. When I'm reviewing sometimes I'll not have a chance to look at the code line by line so will just review the cartography, and indicate so.

Reviews aren't limited to maintainers, but I would expect a review by a maintainer before merging. In fact, we should be having more reviews from non-maintainers. Concerns from non-maintainers shouldn't be dismissed, but a maintainer's comments carry more weight.

Generally reviews should be done using the functionality GitHub provides for them, since it makes it much easier to track them.

pnorman on 5 Jan 2019

You know me well enough and I thought it's clear from the context that I don't try to learn the basics here? I look at review requirement as failing element of the OSM Carto governing process, that's why I ask such simple questions. For example I don't try to define our release policy, since it "just works" now.

The problem with review is - if it's required, what if nobody is willing to do that? Who has the possibility/responsibility to do it? What decisive fallback might be used instead? I'd like to find a solid solution, because this is the weakest link currently.

kocio-pl on 5 Jan 2019

“The problem with review is - if it's required, what if nobody is willing
to do that?”

This can also happen to PRs from contributors, who do not have the ability
to merge their own PR. So avoiding review is not a solution for us.

The solution is to increase the number of active maintainers, if this
becomes a significant problem.

The current list should be enough, but it seems that a number of
maintainers are no longer reviewing PRs.

On Sun, Jan 6, 2019 at 2:06 AM kocio-pl notifications@github.com wrote:

You know me well enough and I thought it's clear from the context that I
don't try to learn the basics here? I look at review requirement as failing
element of the OSM Carto governing process, that's why I ask such simple
questions. For example I don't try to define our release policy, since it
"just works" now.

The problem with review is - if it's required, what if nobody is willing
to do that? Who has the possibility/responsibility to do it? What decisive
fallback might be used instead? I'd like to find a solid solution, because
this is the weakest link currently.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gravitystorm/openstreetmap-carto/issues/2436#issuecomment-451672366,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AoxshDvpjlNjA2SoDb9tKz-MRkqqIEG0ks5vANuHgaJpZM4KwpIq
.

jeisenbe on 5 Jan 2019

@jeisenbe and other non-maintainers - i have recently looked over many of the more recent PRs and got the impression that longer delays in merging after development and discussion were rare more recently.

If you have have made a PR and development and open discussion are concluded i am pretty sure most of the maintainers would be willing to look at it and review your change - at least if it is not a feature addition. Several of the maintainers are very critical regarding addition of new feature meanwhile because more recent inflationary additions which are seen in conflict with the goals of maintainability of the style and readability of the map. But if you have a bug fix or a design improvement that is not a problem.

You can also directly ask for a specific maintainer to review your work. The communication volume on this issue tracker is sometimes quite high and not everyone follows every PR and issue to immediately notice when there is a PR in need of review. Not everyone will always be able to provide an exhaustive review and merge the change but you will probably often get at least some suggestions or assessment on either cartography or technical quality.

One thing i noticed looking at more recent PRs is that it has become a relatively common practice to perform extensive design discussion and planning of changes on issues and then have an _open and done_ PR with no or very little comments. This is not good. The PR is where you propose your change to the project and this is where reviews and discussion of the change should happen and not on an issue where it is possibly intermixed with the discussion of maybe dozens of other ideas how to address a problem. Well presenting your PR with reasoning for your change, discussion of disadvantages and solid research of the context is of advantage as well.

Another thing i noticed looking at more recent PRs is that hardly any PR is rejected any more. This is not a good development. Having bad ideas and developing bad ideas to the end is an essential part of successful design work. If you think you can identify all of your bad ideas early in the process you are mistaken. Taking myself as example - i learned more from the failure of each of the three PRs i made to this project that were not merged than from any of the 20 ones that were merged. But of course to learn from your mistakes you (a) need to make them and (b) need to become aware of them. This is why you need to make also PRs that could be rejected and maintainers need to be willing to reject PRs when advisable.

I have mostly stopped reviewing PRs here because my comments could be and were overruled by other maintainers without consensus - which is obviously not a nice thing to have if you invest the time to assess a change. But @gravitystorm has now in https://github.com/gravitystorm/openstreetmap-carto/issues/2436#issuecomment-450818948 indicated that he would like to see this change and so far no one has objected so it might be possible to get to a more consensus based work culture again.

imagico on 6 Jan 2019

i have recently looked over many of the more recent PRs and got the impression that longer delays in merging after development and discussion were rare more recently.

Yes, this is true. I don't personally think there is a big problem at
the moment. (I did have a couple of PRs open for over a month last
week, but one was recently rejected and another was merged, so now
there is only one completed PR that is over a month old. This seems
reasonable.)

But I wanted to mention that if this does become a problem, it's not a
solution to have one maintainer merge their own PRs, because this will
not improve the situation for PRs which are submitted by contributors
who are not maintainers.

On 1/6/19, Christoph Hormann notifications@github.com wrote:

@jeisenbe and other non-maintainers - i have recently looked over many of
the more recent PRs and got the impression that longer delays in merging
after development and discussion were rare more recently.

If you have have made a PR and development and open discussion are concluded
i am pretty sure most of the maintainers would be willing to look at it and
review your change - at least if it is not a feature addition. Several of
the maintainers are very critical regarding addition of new feature
meanwhile because more recent inflationary additions which are seen in
conflict with the goals of maintainability of the style and readability of
the map. But if you have a bug fix or a design improvement that is not a
problem.

You can also directly ask for a specific maintainer to review your work.
The communication volume on this issue tracker is sometimes quite high and
not everyone follows every PR and issue to immediately notice when there is
a PR in need of review. Not everyone will always be able to provide an
exhaustive review and merge the change but you will probably often get at
least some suggestions or assessment on either cartography or technical
quality.

One thing i noticed looking at more recent PRs is that it has become a
relatively common practice to perform extensive design discussion and
planning of changes on issues and then have an _open and done_ PR with no or
very little comments. This is not good. The PR is where you propose your
change to the project and this is where reviews and discussion of the change
should happen and not on an issue where it is possibly intermixed with the
discussion of maybe dozens of other ideas how to address a problem. Well
presenting your PR with reasoning for your change, discussion of
disadvantages and solid research of the context is of advantage as well.

Another thing i noticed looking at more recent PRs is that hardly any PR is
rejected any more. This is not a good development. Having bad ideas and
developing bad ideas to the end is an essential part of successful design
work. If you think you can identify all of your bad ideas early in the
process you are mistaken. Taking myself as example - i learned more from
the failure of each of the three PRs i made to this project that were not
merged than from any of the 20 ones that were merged. But of course to
learn from your mistakes you (a) need to make them and (b) need to become
aware of them. This is why you need to make also PRs that could be rejected
and maintainers need to be willing to reject PRs when advisable.

I have mostly stopped reviewing PRs here because my comments could be and
were overruled by other maintainers without consensus - which is obviously
not a nice thing to have if you invest the time to assess a change. But
@gravitystorm has now in
https://github.com/gravitystorm/openstreetmap-carto/issues/2436#issuecomment-450818948
indicated that he would like to see this change and so far no one has
objected so it might be possible to get to a more consensus based work
culture again.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/gravitystorm/openstreetmap-carto/issues/2436#issuecomment-451703178

jeisenbe on 6 Jan 2019

I did have a couple of PRs open for over a month last week

Note i was not talking about the time a PR is open in total, i was talking about the time from end of development and discussion until it is merged or rejected. This seemed more recently often just a few days and hardly ever more than two weeks.

If there were non-maintainer PRs during the last year ready and waiting to be be reviewed with no maintainer comments for more than a month and no stated reason why this is on hold please point me to them.

But I wanted to mention that if this does become a problem, it's not a solution to have one maintainer merge their own PRs, because this will not improve the situation for PRs which are submitted by contributors who are not maintainers.

Yes, there are a lot of different matters being touched in recent discussion here and while there are some interconnections this is not all the same of course.

imagico on 6 Jan 2019

i am pretty sure most of the maintainers would be willing to look at it and review your change - at least if it is not a feature addition.

What exactly is the issue with feature additions? Yeah, some of them like adding a bunch of new icons might have been over kill (I assume that's what your talking about), but adding features like waste water plants was relatively a good idea.

I don't see why maintainers shouldn't review new features even if they don't like them either. Its better things are reviewed, rejected, and maybe be refined later based on the feedback then not be reviewed at all simply because its a feature and maintainers don't like those.

As a side to that, one issue I find particularly frustrating is when a bunch of work is put into an issue in the ticket, but then copious amounts of further work is necessary in the PR because someone decided to jump in with an opinion there, instead of participating in the original discussion. Especially if the PR is then ultimately rejected.

Maybe I'm ignorant to the difference between an issue and a PR, but to me the point where a PR comes into the equation should be when most of the design aspects of the issue have been worked out. I know that the maintainers can't follow every issue discussion, but most things are decided in issues through rigorous discussion. A lot of contributors and issue openers don't subsequently participate in the PR either. So id appreciate more clarity on what the differences between the two are and how putting time into testing things, along with listening to feedback from contributors can be properly balanced between them.

In that vain, I don't see why more maintainers can't chime in at the point where the issue is created to say its something they don't think should happen. I know that can't happen in every case, but I'm pretty sure some past issues could have been rejected a lot sooner in the process then they were.

There should be a stop gap to keep a maintainer from swooping in to close an issue that's about to be merged and has been open for like 4 years without anyone criticizing it. As it currently stands, @kocio-pl is the main (if not only) maintainer that both participates regularly in issues and also gives feedback on PRs. A maintainer's duties shouldn't start and end at the point of merging something or not.

Adamant36 on 6 Jan 2019

i have recently looked over many of the more recent PRs and got the impression that longer delays in merging after development and discussion were rare more recently.

It depends on how recent moment you took. Longer delays are rare indeed, since most of the discussion is done in issue tickets and this is just the last stop, as you have noticed, but _most recently_ even in the PR tickets we have more (sometimes unconclusive) discussions.

Several of the maintainers are very critical regarding addition of new feature meanwhile because more recent inflationary additions which are seen in conflict with the goals of maintainability of the style and readability of the map. But if you have a bug fix or a design improvement that is not a problem.

I hope you could tell (in the proper place, like #1975, to not go offtopic) about why do you think it's conflict at all, because I don't agree and I even don't know justification.

Yet what I have seen is that mainly simple bugfixes get merged by other maintainers, but without even involving in discussion. Which is easy to understand, but double worrying.

kocio-pl on 6 Jan 2019

Taking myself as example - i learned more from the failure of each of the three PRs i made to this project that were not merged than from any of the 20 ones that were merged. But of course to learn from your mistakes you (a) need to make them and (b) need to become aware of them.

Maybe we have different needs and learning paths then? Here is my personal experience:

I've learned from rejection of my PRs mainly that my work is not welcome and that being more stubborn and less creative is the way to go. In the end I got strong impression that mistakes are expensive and I can't afford making them in the long run. And even then it was 50/50 chance, IIRC.

The best learning experience for me was - and still is - when somebody tells "this should be fixed this way or could be done in a different way - here's how". That makes me want to do more work (and more mistakes, since they are cheap). This gives me (a) and (b), but also (c) more fun, (d) better team work and (e) problem is solved.

kocio-pl on 6 Jan 2019

I've learned from rejection of my PRs mainly that my work is not welcome and that being more stubborn and less creative is the way to go.

That’s also a question of personal attitude. I’ve contributed quite a long time to this repository before becoming maintainer, and I had PRs rejected, but I did never feel “not welcome”. I’ve tried to learn something; and, though maybe I don’t always agree, understand other people’s reasons for the reject and get a better feeling for the bigger picture.

sommerluk on 6 Jan 2019

Trying to keep the discussion on topic - i have not made statements of policy here, i have made some explanations and observations that could help understanding why several of the maintainers are not currently doing much reviewing of changes and what might influence that in terms of work culture. Everyone is free to ignore that and everyone is free to suggest differently.

For explanation why maintainers do not review changes they disapprove - this is mostly a matter of courtesy towards other maintainers who have different preferences. In a consensus based decision making system it is essential to not exercise your right to disagree when it is not fundamental for you. In other words: I expect my objections to a change - when voiced - to be taken into account in substance and not be overruled. But this in return means that when i don't want to insist on it i let others who have a different opinion make decisions i disagree with (but there none the less needs to be someone who does this and takes responsibility).

Keep in mind maintainers are volunteers here just like anyone else. My motivation for doing review work (and in sum i might have done more of that before i became a maintainer than afterwards) was to learn something and get inspiration from the work of others and from discussing it with those who make it, understand their decision making process etc. In return i share my views and give people feedback about their work. That for me is the essence of cooperative design work. Others might have different motivations.

My observations regarding the critical attitude concerning addition of new features of several maintainers are a statement of fact. I could support this with public statements in that direction but i don't think that's really necessary. Feel free to discuss this in a separate issue but you will need to convince people with arguments and evidence and not just a simple _i like new features and i don't see why anyone would not like them_.

imagico on 6 Jan 2019

The problem with review is - if it's required, what if nobody is willing to do that? Who has the possibility/responsibility to do it? What decisive fallback might be used instead? I'd like to find a solid solution, because this is the weakest link currently.

If the PR doesn't get reviewed, then it needs to wait until a maintainer reviews it. If there's no maintainers willing to review a given PR - even to decline it - then that suggests that there's an underlying problem that the maintainers need to resolve first.

I'm not sure what you have in mind by "decisive fallback" - possibly you mean that a PR is automatically merged or declined after X time without review. But I don't think either of those would be good for the project. We have 7 maintainers at the moment, each of whom can review any PR. If we get to the stage where no PRs are being reviewed in reasonable timeframes, then we can figure out the underlying causes at that point.

Who has the possibility/responsibility to do it?

Just to reiterate, all the maintainers have the ability and responsibility to review PRs, although please bear in mind as @imagico mentions, that everyone is a volunteer here, so patience and understanding are often required.

gravitystorm on 7 Jan 2019

I don't see why maintainers shouldn't review new features [...]

I don't see why more maintainers can't chime in at the point [...]

I realise this is only a turn of phrase, but it's not a particularly friendly one. "What can I do to help with [something]?" is a better way to phrase statements, rather than "I don't see why other people don't do [something]".

gravitystorm on 7 Jan 2019

Thanks for the answer, that sets the basic framework for me. Although I still feel it's failing, it's clear for a start, so I'd like to evaluate that in the next few months.

I'm not sure what you have in mind by "decisive fallback" - possibly you mean that a PR is automatically merged or declined after X time without review.

No, I meant _any_ fallback mechanism - what to do if that does not work?

I claimed that at the beginning, that merging stuff after 1 month of lack of review is a good balance against PR clash (not too easy, to be not tempting, but still doable) and sadly that was most of the time, so the problem is real. I just didn't like to hint you anything to not start dispute if it's bad or good solution, just hear the best solution you can think of.

If we get to the stage where no PRs are being reviewed in reasonable timeframes, then we can figure out the underlying causes at that point.

What is "reasonable timeframe" for you? For me it's 1 month. I guess I will ask then here what to do.

Just to reiterate, all the maintainers have the ability and responsibility to review PRs, although please bear in mind as @imagico mentions, that everyone is a volunteer here, so patience and understanding are often required.

No need to reiterate something that is perfectly clear for me, I really understand that and I also feel that nobody should be forced to make a review he does not want/feels like doing - that would be plain horrible! I just wanted to remind that non-maintainers (developers, reporters) are volunteers too and their time and work is as valuable as ours, so it would be good to strike some balance we lack currently (that's my opinion).

kocio-pl on 7 Jan 2019

Maybe you guys could make @jeisenbe a maintainer to do basic tasks like label issues if he wants. It seems like those types of things are getting neglected lately and they are important to keep up in my opinion. It looks like new issues haven't been labeled in almost three months.

Adamant36 on 26 May 2019

@Adamant36 - thanks!

But I don't think I could make that commitment at this time. I don't have a good enough server or internet connection to review PRs that require loading the planet, and I don't think I have enough experience.

jeisenbe on 28 May 2019

👍1

For information - @jeisenbe has now been given maintainer status on this repository.

See #3846.

Note - as said on various occasions before - being a maintainer is not a prerequisite for reviewing pull requests. Anyone can do and is invited to do that. Reviewing changes is not something that requires a lot of resources. Setting up a testing environment can be somewhat tricky but it does not require powerful hardware.

imagico on 22 Aug 2019

👍1

being a maintainer is not a prerequisite for reviewing pull requests. Anyone can do and is invited to do that. Reviewing changes is not something that requires a lot of resources.

True. @Adamant36 has reviewed the cartographical changes in a number of PRs and issues, and there are a number of other contributors here who make helpful suggestions, even without doing a full review of the changes. While it does take some time to download and set up the test rendering environment, it's fairly user-friendly with Docker.

I'm running the test renderings via Docker on a mid-2012 MacBook Pro with 6 GB of RAM. One year ago I had never used a command-line application or Github. It took a little time to get up to speed, but I believe almost anyone can participate in improving this project, if they have the time. Not so much harder than figuring out how to use JOSM.

jeisenbe on 22 Aug 2019

❤2

I think this RFC on 'rough consensus' is a very interesting read related to our decision making process.

matthijsmelissen on 21 Sep 2019

Thanks, might be interesting read, but it's long. Do you think the index summarizes it well? What are your general ideas or comments about that?

Lack of disagreement is more important than agreement
Rough consensus is achieved when all issues are addressed, but not necessarily accommodated
Humming should be the start of a conversation, not the end
Consensus is the path, not the destination
One hundred people for and five people against might not be rough consensus
Five people for and one hundred people against might still be rough consensus

kocio-pl on 21 Sep 2019

The linked document isn't too long for a native speaker, but I understand that it might be a difficult read it all if English is not one's first language.

I describes a somewhat different situation but it has a few good points, which I will try to summarize.

The situation described is about the Internet Engineering Task Force (IETF), which has several Working Groups which discuss various internet infrastructure and engineering problems, and each has a chairperson. They sometimes meet in person, where semi-anonymous "votes" about issues are sometimes done by literally humming, other times there are votes taken via mailing list. This is rather different than our situation.

However, some features are the same: like a working group, the maintainers here are tasked with improving this style and investigating issues that are brought up by the larger community. Sometimes decisions made here are controversial, but we strive to make decisions based on consensus, rather than by fiat or voting. Often there are trade-offs that have to be made, especially for changes to cartography.

_The document starts out by stating:_

"we don't let a single individual dictate decisions

"Nor should decisions be made by a vote

"Nor do we want decisions to be made in a vacuum without practical experience.

"Instead, we strive to make our decisions by the consent of all participants, though allowing for some dissent (rough consensus), and to have the actual products of engineering (running code) trump theoretical designs"

_The last thing, about "actual products of engineering" being more important than theoretical designs is not so relevant, since we rarely have debates about what underlying code structure should be used, but about the end product: the cartography._

_But the other points, which describe consensus-based decision-making, are relevant_

Lack of disagreement is more important than agreement:

_This part is key, because it defines what "consensus" means:_

"Engineering always involves a set of tradeoffs.

"It is almost certain that any time engineering choices need to be made, there will be options that appeal to some people, but are not appealing to some others. In determining consensus, the key is to separate those choices that are simply unappealing from those that are truly problematic.

"If at the end of the discussion some people have not gotten the choice that they prefer, but they have become convinced that the chosen solution is acceptable, albeit less appealing, they have still come to consensus.

"Consensus doesn't require that everyone is happy and agrees that the chosen solution is the best one. Consensus is when everyone is sufficiently satisfied with the chosen solution, such that they no longer have specific objections to it."

_Comment: the important thing is that specific problems and objections are addressed and resolved, not that everyone thinks a certain color is the best-looking, for example._

"after the initial discussion of the pros and cons of the available choices, it is most important to ask not just for objections to a particular proposal, but for the nature of those objections.

... "Following up with, "What are the reasons you object to choice A?" is also essential.

_Comment: This means that if a maintainer or another contributor reviews a PR or objects to a solution to an issue, they should give their specific reasons for opposing the choice, and explain why their preferred solution will solve the problem. An answer of "I don't like this" is not helpful._

"a solution that has no objections, but also has no base of support and is met with complete apathy, is not a solution that has any useful sort of consensus. Consensus does require the active engagement and eventual support of those who are working on the solution."

_Comment: For us, this suggests that a maintainer should not merge their own PRs without a review since lack of any negative comments does not prove that the PR is a good idea._

_The next section is about compromise, and consensus versus voting / horse trading:_

"engineering always involves balancing tradeoffs, and figuring out whether one engineering decision makes more sense on balance compared to another involves making engineering "compromises"

_Comment: for example code complexity versus good mapper feedback versus the best rendering_

"However, there is another sense of "compromise" that involves compromising between people... For example, a minority ... might object to a particular proposal, and even after discussion still think it is deeply problematic, but decide that they don't have the energy to argue against it and say, "Forget it, do what you want".
...
"Even worse is the "horse-trading" sort of compromise: "I object to your proposal for such-and-so reasons. You object to my proposal for this-and-that reason. Neither of us agree. If you stop objecting to my proposal, I'll stop objecting to your proposal and we'll put them both in."
...
"These sorts of "capitulation" or "horse-trading" compromises have no place in consensus decision making"

_Comment: These are good examples. Often we will be personally happier by being friendly and offering "you can merge this PR, if I can merge mine", or thinking "it's not worth bad feelings to argue about this", but such compromises can lead to bad results for the project_

_Summary_: "Coming to consensus is when everyone (including the person making objection) comes to the conclusion that either the objections are valid, and therefore make a change to address the objection, or that the objection was not really a matter of importance, but merely a matter of taste."

_I’ll address the other sections later, but this is the most important one._

jeisenbe on 23 Sep 2019

TL/DR: "Coming to consensus is when everyone (including the person making an objection) comes to the conclusion that either the objections are valid, and therefore make a change to address the objection, or that the objection was not really a matter of importance, but merely a matter of taste."

jeisenbe on 23 Sep 2019

Whoops - clicked on close by mistake.

Still, I'm not sure what the result of this issue should be or how we get to closing it.

pnorman on 23 Sep 2019

This issue has certainly drifted over time. Right now I think it's a
reasonable place to discuss how we should make decisions and what it
means to be governed by consensus.

jeisenbe on 23 Sep 2019

For me it doesn't matter if it will be this ticket or a new one. On the one hand the title is perfect, on the other hand this might be too much to scroll (already 108 messages) and over 3 years the actual problems has changed few times, so a follow-up ticket might be OK.

kocio-pl on 23 Sep 2019

Closing, since the original concerns about lack of sufficient number of maintainers has been addressed for now, and the discussion about consensus-based decision making can continue in #3951

jeisenbe on 26 Oct 2019

👍1

Openstreetmap-carto: Project governing status

Most helpful comment

All 110 comments

Related issues