New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Project governing status #2436

Open
kocio-pl opened this Issue Nov 13, 2016 · 59 comments

Comments

Projects
None yet
10 participants
@kocio-pl
Collaborator

kocio-pl commented Nov 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico Nov 13, 2016

Collaborator

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.

Collaborator

imagico commented Nov 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@wmyrda

wmyrda Nov 13, 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.

wmyrda commented Nov 13, 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.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Nov 13, 2016

Collaborator

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.

Collaborator

pnorman commented Nov 13, 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.

@wmyrda

This comment has been minimized.

Show comment
Hide comment
@wmyrda

wmyrda Nov 13, 2016

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

wmyrda commented Nov 13, 2016

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

@matthijsmelissen

This comment has been minimized.

Show comment
Hide comment
@matthijsmelissen

matthijsmelissen Nov 13, 2016

Collaborator

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.

Collaborator

matthijsmelissen commented Nov 13, 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.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Nov 13, 2016

Collaborator

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

Collaborator

pnorman commented Nov 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Nov 14, 2016

Collaborator

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.

Collaborator

kocio-pl commented Nov 14, 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.

@imagico

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico Nov 14, 2016

Collaborator

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.

Collaborator

imagico commented Nov 14, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gravitystorm

gravitystorm Nov 15, 2016

Owner

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.

Owner

gravitystorm commented Nov 15, 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.

@kocio-pl kocio-pl added the general label Nov 15, 2016

@kocio-pl

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Nov 15, 2016

Collaborator

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.

Collaborator

kocio-pl commented Nov 15, 2016

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 kocio-pl closed this Nov 15, 2016

@matthijsmelissen

This comment has been minimized.

Show comment
Hide comment
@matthijsmelissen

matthijsmelissen Nov 15, 2016

Collaborator

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?

Collaborator

matthijsmelissen commented Nov 15, 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?

@kocio-pl

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Nov 15, 2016

Collaborator

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.

Collaborator

kocio-pl commented Nov 15, 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.

@imagico

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico Nov 15, 2016

Collaborator

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

Collaborator

imagico commented Nov 15, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@gravitystorm

gravitystorm Nov 16, 2016

Owner

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

Owner

gravitystorm commented Nov 16, 2016

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

@matthijsmelissen

This comment has been minimized.

Show comment
Hide comment
@matthijsmelissen

matthijsmelissen Apr 2, 2017

Collaborator

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.

Collaborator

matthijsmelissen commented Apr 2, 2017

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.

@kocio-pl

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Apr 16, 2017

Collaborator

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.

Collaborator

kocio-pl commented Apr 16, 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

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Jul 1, 2017

Collaborator

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.

Collaborator

kocio-pl commented Jul 1, 2017

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 kocio-pl reopened this Jul 1, 2017

@matthijsmelissen

This comment has been minimized.

Show comment
Hide comment
@matthijsmelissen

matthijsmelissen Jul 1, 2017

Collaborator

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.

Collaborator

matthijsmelissen commented Jul 1, 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.

@kocio-pl

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Jul 31, 2017

Collaborator

I think review requirement just doesn't work in this project. Even big changes like #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.

Collaborator

kocio-pl commented Jul 31, 2017

I think review requirement just doesn't work in this project. Even big changes like #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

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Jul 31, 2017

Collaborator

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

Collaborator

pnorman commented Jul 31, 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

@kocio-pl

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Jul 31, 2017

Collaborator

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.

Collaborator

kocio-pl commented Jul 31, 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.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Aug 1, 2017

Collaborator

For an example of a review where I commented but didn't approve/request changes, openstreetmap/iD#4166 (review). 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.

Collaborator

pnorman commented Aug 1, 2017

For an example of a review where I commented but didn't approve/request changes, openstreetmap/iD#4166 (review). 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

This comment has been minimized.

Show comment
Hide comment
@sommerluk

sommerluk Aug 7, 2017

Collaborator

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…

Collaborator

sommerluk commented Aug 7, 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…

@imagico

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico Aug 16, 2017

Collaborator

Following up from #2601 with #2601 (comment) and #2601 (comment):

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.

Collaborator

imagico commented Aug 16, 2017

Following up from #2601 with #2601 (comment) and #2601 (comment):

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

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Aug 16, 2017

Collaborator

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.

Collaborator

kocio-pl commented Aug 16, 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.

@nebulon42

This comment has been minimized.

Show comment
Hide comment
@nebulon42

nebulon42 Aug 16, 2017

Contributor

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.

Contributor

nebulon42 commented Aug 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@matthijsmelissen

matthijsmelissen Aug 16, 2017

Collaborator

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.

Collaborator

matthijsmelissen commented Aug 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@matthijsmelissen

matthijsmelissen Aug 16, 2017

Collaborator

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.

Collaborator

matthijsmelissen commented Aug 16, 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.

@kocio-pl

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Aug 17, 2017

Collaborator

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.

Collaborator

kocio-pl commented Aug 17, 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.

@matthijsmelissen

This comment has been minimized.

Show comment
Hide comment
@matthijsmelissen

matthijsmelissen Aug 17, 2017

Collaborator

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?

Collaborator

matthijsmelissen commented Aug 17, 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?

@nebulon42

This comment has been minimized.

Show comment
Hide comment
@nebulon42

nebulon42 Aug 17, 2017

Contributor

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.

Contributor

nebulon42 commented Aug 17, 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.

@imagico

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico Aug 18, 2017

Collaborator

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.

Collaborator

imagico commented Aug 18, 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.

@kocio-pl

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Aug 18, 2017

Collaborator

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

kocio-pl commented Aug 18, 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.
@matthijsmelissen

This comment has been minimized.

Show comment
Hide comment
@matthijsmelissen

matthijsmelissen Aug 20, 2017

Collaborator

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.

Collaborator

matthijsmelissen commented Aug 20, 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.

@kocio-pl

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Aug 20, 2017

Collaborator

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

Collaborator

kocio-pl commented Aug 20, 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

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Sep 6, 2017

Collaborator

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!

Collaborator

kocio-pl commented Sep 6, 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

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Sep 18, 2017

Collaborator

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

Collaborator

kocio-pl commented Sep 18, 2017

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

@matthijsmelissen

This comment has been minimized.

Show comment
Hide comment
@matthijsmelissen

matthijsmelissen Oct 14, 2017

Collaborator

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

Collaborator

matthijsmelissen commented Oct 14, 2017

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

@matthijsmelissen

This comment has been minimized.

Show comment
Hide comment
@matthijsmelissen

matthijsmelissen Nov 29, 2017

Collaborator

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

Collaborator

matthijsmelissen commented Nov 29, 2017

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

@kocio-pl

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Feb 11, 2018

Collaborator

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.

Collaborator

kocio-pl commented Feb 11, 2018

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

This comment has been minimized.

Show comment
Hide comment
@matthijsmelissen

matthijsmelissen Feb 11, 2018

Collaborator

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

Collaborator

matthijsmelissen commented Feb 11, 2018

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

@kocio-pl

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Feb 11, 2018

Collaborator

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

Collaborator

kocio-pl commented Feb 11, 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

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Aug 14, 2018

Collaborator

If anybody is interested in CartoCSS, please look at its current (un-)maintained status - JavaScript volunteers wanted: mapbox/carto#495 (comment)

Collaborator

kocio-pl commented Aug 14, 2018

If anybody is interested in CartoCSS, please look at its current (un-)maintained status - JavaScript volunteers wanted: mapbox/carto#495 (comment)

@jeisenbe

This comment has been minimized.

Show comment
Hide comment
@jeisenbe

jeisenbe Sep 14, 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 commented Sep 14, 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.

@kocio-pl kocio-pl reopened this Sep 14, 2018

@matthijsmelissen

This comment has been minimized.

Show comment
Hide comment
@matthijsmelissen

matthijsmelissen Sep 14, 2018

Collaborator

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

Collaborator

matthijsmelissen commented Sep 14, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@matkoniecz

matkoniecz Sep 14, 2018

Collaborator

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.

Collaborator

matkoniecz commented Sep 14, 2018

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

This comment has been minimized.

Show comment
Hide comment
@matkoniecz

matkoniecz Sep 14, 2018

Collaborator

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

Collaborator

matkoniecz commented Sep 14, 2018

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

This comment has been minimized.

Show comment
Hide comment
@jeisenbe

jeisenbe Sep 15, 2018

jeisenbe commented Sep 15, 2018

@kocio-pl

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Sep 15, 2018

Collaborator

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?

Collaborator

kocio-pl commented Sep 15, 2018

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

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico Sep 15, 2018

Collaborator

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

Collaborator

imagico commented Sep 15, 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.

@jeisenbe

This comment has been minimized.

Show comment
Hide comment
@jeisenbe

jeisenbe Sep 15, 2018

jeisenbe commented Sep 15, 2018

@matthijsmelissen

This comment has been minimized.

Show comment
Hide comment
@matthijsmelissen

matthijsmelissen Sep 15, 2018

Collaborator

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.

Collaborator

matthijsmelissen commented Sep 15, 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.

@matkoniecz

This comment has been minimized.

Show comment
Hide comment
@matkoniecz

matkoniecz Sep 15, 2018

Collaborator

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.

Collaborator

matkoniecz commented Sep 15, 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.

@kocio-pl

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Sep 15, 2018

Collaborator

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

Collaborator

kocio-pl commented Sep 15, 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

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Sep 15, 2018

Collaborator

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.

Collaborator

kocio-pl commented Sep 15, 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.

@imagico

This comment has been minimized.

Show comment
Hide comment
@imagico

imagico Sep 15, 2018

Collaborator

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

Collaborator

imagico commented Sep 15, 2018

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

@matkoniecz

This comment has been minimized.

Show comment
Hide comment
@matkoniecz

matkoniecz Sep 16, 2018

Collaborator

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

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

Collaborator

matkoniecz commented Sep 16, 2018

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

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

@kocio-pl

This comment has been minimized.

Show comment
Hide comment
@kocio-pl

kocio-pl Sep 17, 2018

Collaborator

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.

Collaborator

kocio-pl commented Sep 17, 2018

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.

@matkoniecz

This comment has been minimized.

Show comment
Hide comment
@matkoniecz

matkoniecz Sep 17, 2018

Collaborator

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.

Collaborator

matkoniecz commented Sep 17, 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment