How to contribute? Dead PRs?

[Zaczero]

Description

I am struggling to understand why some many PRs are left unmerged.

#9483
#9482
#9454
#9424
#9315
…
to name a few.

So many features and fixes are waiting... for what exactly?

I did read https://github.com/openstreetmap/iD/blob/develop/CONTRIBUTING.md but it did not answer any of my questions.

I really want to contribute to iD but this is a massive blocker for me.
I do not want to waste my time just to have a dead PR.

Please help my understand what's the procedure for having a PR merged.

Screenshots

No response

[tyrasd]

Hey. (I've converted this issue to a discussion, as it is on a more meta level, and nothing one can be "fixed" like a regular issue).

I can't give you a simple answer to your question, unfortunately. The contributing guidelines are mostly correct from a technical standpoint, but I think it is to some extent missing the "social" aspect. As the maintainer of this rather large project, I wish I could tackle every PR and issue immediately, but in practice, I do need to prioritize things. Maybe my approach is not the best – heck, it almost certainly isn't – but I do not like to comment/decide on issues/prs without a well founded opinion. And it can take a surprising amount of time to think through even seemingly simple issues… I don't want to sound ignorant on this, but frankly, many issues are simply "low priority" from an "overarching" point of view. In some other cases an approach to solve an issue can be overly ambitious, which can also lead to stale PRs, e.g. as seen in #8826.

I really want to contribute to iD but this is a massive blocker for me. I do not want to waste my time just to have a dead PR.

I feel you on this. Here's the best advice I can give you to prevent wasting your time. If you intend to contribute something substantial (i.e. not just a trivial bug fix, or similar): Talk about what you're planning to do, before you start coding. Draw a few sketches, outline the use cases, come up with user stories. Especially talk to other mappers and be open to feedback. In respect thereof, I am personally also open to – at the one hand – give out advice, and – on the other hand – hear your personal issues and pains when using iD. Feel free to reach out to me any time either privately (e.g. user tyr_asd, on osm.org or discord, or osmus.slack.com, etc.), or publicly (e.g. #id channels on discord/slack, or community.osm.org). I'm always trying to do my best to respond with my honest opinion and advice.

🙇‍♂️

[Zaczero]

Personal Opinion 👀

I think iD is too cautious in its development. I believe you should approve PRs more frequently without waiting for everyone's input. I trust your knowledge in iD development and OSM standards, so most of your decisions should be fine. Waiting for feedback from everyone, especially when this isn't advertised, slows down the project and can push people away.

Not every PR needs to be perfect. If a feature works well and doesn't have serious issues, it could be better to approve it and then address improvements in separate issues. In my view, it seems like a PR must be near-perfect to get approved in iD, and that's rare.

The community could benefit more from using features that aren't perfect rather than having no features at all. We just want to map efficiently. Most users aren't too concerned about aesthetics, like with JOSM. Don't wait for everything to be perfect before moving forward.

[mxxcon]

Especially when it comes to fixes and enhancements that are purely within iD and don't affect tagging... Such as #9454/#9545

[ZeLonewolf]

My impression @tyrasd is that you personally don't have enough bandwidth to give a project this size the attention that it needs to service an overwhelming number of open PRs. It's necessary to build a community and a maintainer team that can assist you in an effort of this size. What I would really like to hear is a plan for how to helm this ship at an executive level. If it all depends on you alone to perform heroic efforts, I don't think that's an effective way to manage a large project.

[Zaczero]

@ZeLonewolf I have to disagree:

overwhelming number of open PRs ... I don't think that's an effective way to manage a large project

This is not really the case. Simply take a look at the frequency of new pull requests being opened here. The project is indeed big, but the level of activity is manageable for a single person with a salary.

hear is a plan for how to helm this ship at an executive level

I believe the current approach is quite OK. However, I think the issue lies in tyrasd playing it a little too safe and not trusting his own experience enough. People are eager to develop and contribute, but the lengthy periods for feature releases, lack of feedback, and abandonment of other significant features in pull requests is demotivating and drives people away.

The problem with the approach of waiting for community feedback is that it requires an active community, which is not currently the case. If tyrasd wishes to continue with this approach, I believe the first good step would be to promote discussions on community forums, focusing on the most significant new issues rather than each one of them (like a hybrid approach). Knowing the OSM community, this would be the best way to gather feedback rather than relying solely on random issues on GitHub without a clear request for feedback.

TL;DR of how I see it:

Current system,
Small, medium, big issues: tyrasd waits for feedback on GitHub, which never happens.

New system,
Small, medium issues: tyrasd decides by himself - he is an experienced dev and mapper.
Big issues: tyrasd waits for feedback on both GitHub and community forums. A dedicated section is created on the forums specifically for gathering feedback on these big issues.

[Dimitar5555]

I do not agree with @ZeLonewolf. The problem is that even relatively simple to solve issues stay open for months or years. For example #8775 stayed open for almost two years and it would've been still open if I haven't pinged Martin. Do we have to ping him on all 83 open PRs and all 1.1k open issues so that they can be solved?! If he had any desire to do something bigger, we would've seen it in the past almost two years.

@tyrasd If you still want to develop iD please do so. Start with anything but try to focus only on it, since it will quickly turn into yak shaving. Yak shaving is necessary, but it can wait a bit until you've resolved the particular issue. If you think that you can't develop iD anymore (because of personal/health related or any other reason), you can always contact the OSMF and see what can be done. Stepping down from this role is always an option if you can't resolve the thing that stops you from contributing. Of course I can't know whether you've already talked with the OSMF and what's happening in your life. What I know is that it's morally wrong to take salary not doing any work (or doing lower than the bare minimum).

I know that I'm a bit direct but If we sit around and do nothing the roof may fall before anything gets resolved.

[pnorman]

I had a look at PRs without reviews. A lot of them do not require a maintainer to review, but could be done by anyone. In many cases, no javascript knowledge was required. This is good news, as it means anyone can contribute.