search

gravitystorm / openstreetmap-carto

A general-purpose OpenStreetMap mapnik style, in CartoCSS
Other
1.54k stars 823 forks source link

Project governing status #2436

Closed kocio-pl closed 5 years ago

kocio-pl commented 7 years ago

I'm a bit worried about governing status of this project.

This is not only current problem, however long and stalled PR queue is the most visible effect. This alone would not bother me if we have ongoing discussion - it's perfectly clear that some code needs more insight and debate, and I consider the time to do this as the most important part of review process. But in many cases we have passed the point of oblivion - discussion is no more active and it's getting hard to recollect the arguments. Moreover decisions are not being made and the code is not merged, nor even dismissed.

We kind of stopped moving, which is bad for any project if it's not close to be perfect. And we're not there yet - for me there are a lot things to change and more people joining us also tells me we have nice potential here. With osm-carto community getting stronger the problem of project governance model is getting more and more evident for me.

We have 4 collaborators made equal by the (repo) creator. Yet @gravitystorm is in practice not active here for a long time, rarely even giving some advice or expressing his thoughts on general issues. @matkoniecz is not committing anything for about half of year now, which is also quite long. @pnorman is recently more active, but he tends to follow purely technical issues (like code quality, performance or general database framework). Which leaves us with just @math1985 as the only active collaborator trying to cover all the fields, like communication, decision making and merging code. With his activity drop for 6 weeks it's no wonder this project is stalled.

I'd like to be perfectly clear - there's nothing wrong with people activity shift (or even going away) in open projects. The real problem is that our governing structure does not reflect the reality. Even if Matthijs will be back with the same superpowers, it's still one man the project relies on for day-to-day operations. In my opinion this is not healthy situation.

What are your thoughts on this topic?

imagico commented 7 years ago

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.

wmyrda commented 7 years ago

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.

pnorman commented 7 years ago

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.

wmyrda commented 7 years ago

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

matthijsmelissen commented 7 years ago

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.

pnorman commented 7 years ago

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

kocio-pl commented 7 years ago

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.

imagico commented 7 years ago

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.

gravitystorm commented 7 years ago

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:

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.

kocio-pl commented 7 years ago

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.

matthijsmelissen commented 7 years ago

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?

kocio-pl commented 7 years ago

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.

imagico commented 7 years ago

@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.

gravitystorm commented 7 years ago

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

matthijsmelissen commented 7 years ago

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:

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

kocio-pl commented 7 years ago

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 commented 7 years ago

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.

matthijsmelissen commented 7 years ago

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.

kocio-pl commented 7 years ago

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.

pnorman commented 7 years ago

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

kocio-pl commented 7 years ago

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.

pnorman commented 7 years ago

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.

sommerluk commented 7 years ago

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…

imagico commented 7 years ago

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.

kocio-pl commented 7 years ago

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:

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.

nebulon42 commented 7 years ago

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.

matthijsmelissen commented 7 years ago

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 commented 7 years ago

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

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.

kocio-pl commented 7 years ago

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.

matthijsmelissen commented 7 years ago

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?

nebulon42 commented 7 years ago

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.

imagico commented 7 years ago

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.

kocio-pl commented 7 years ago

This post made me think about some interesting topics:

matthijsmelissen commented 7 years ago

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.

kocio-pl commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

matthijsmelissen commented 7 years ago

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

matthijsmelissen commented 6 years ago

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

kocio-pl commented 6 years ago

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.

matthijsmelissen commented 6 years ago

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

kocio-pl commented 6 years ago

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 commented 6 years ago

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

jeisenbe commented 6 years ago

@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.

matthijsmelissen commented 6 years ago

@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.

matkoniecz commented 6 years ago

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 commented 6 years ago

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 matkoniecz@gmail.com 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).

jeisenbe commented 6 years ago

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 matkoniecz@gmail.com 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 .

kocio-pl commented 6 years ago

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 - 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?

imagico commented 6 years ago

@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.