Efficiently working together

[westnordost]

Hello regular contributors! This was intended as a comment at #3449 (comment) but I figured it is better to outsource it into a discussion. @matkoniecz asked me about what can be done to more efficiently work together, e.g. create less tickets and less need for communication.

Your Tickets

Every ticket created captures time of those who monitor and triage issues. Let's try to be more brief:

• if no technical review is required (e.g. implementation is trivial) and no content review is required because it either has been discussed before or it is a clear improvement that needn't be discussed, no PR is required for those that have write-access
• if you want to add a minor improvement that is trivial to implement, consider if it is worth the time to first create a ticket for it. In the past, we often had one issue and one PR even for the most trivial contributions
• in tickets, be brief and to the point. Try to use pictures to illustrate things rather than long explanations
• the quest suggestion template is meant for users / newcomers. If as a contributor you know that a particular quest idea you have in mind satisfies all the requirements and you don't need input / feedback from other contributors or me, you can move directly to the implementation, skipping the creation of an issue for this alltogether

Your Pull Requests

The iterative process of reviewing and requesting changes, reviewing again etc. ensures a good quality of the end result. But it is very time intensive, so let's keep the number of iterations and the amount of discussion in it to what is necessary:

• generally, the code should speak for itself. If you need to comment your own PR, maybe you should put that comment in the code instead, or even better write the code in a way that it is self-explanatory what it does and why (if possible)
• try to not mix different work in one PR. It is harder to review and slows down the review process, especially if there are things to complain about
• when you implement something non-trivial, try to create a PR only when you are done or need help or feedback. In the latter case, create it as a draft PR and @-address the person(s) you have questions for. Alternatively, you can ask in the chat (#stretcomplete on slack).
• try to request a review only when you are done. Not when you are basically done but need to work on some details. When re-requesting a review after changes were requested, make sure that all points that have been raised before have been addressed. I.e. you should also tap on the "resolve conversation" button for things that are resolved
• as a (co-)reviewer, be brief and try to keep discussions and requests to extend the PR to a minimum, i.e. what is necessary to complete the PR. For additional things, another PR could be created. It's okay to mention it, but the PR author should not be pushed towards doing stuff that can easily be done in another PR as well.

Other Peoples Tickets

Oftentimes, users don't provide all necessary information for bugs, don't use the search function or are too lazy to fill out the templates. You can help triage:

• bounce the question back to the issue creator if things are missing and add the "feedback required" label
• in extreme cases, issues can be closed immediately with a very short comment (e.g. "please fill out the issue template properly") if the user blatanly didn't make any effort to create a proper ticket and had no respect for our time
• as an oldbie contributor, you may have a very good grasp of what is in and what is out of scope of this project so you may close certain feature requests directly, maybe based on previous will-not-fixes or because you know the limitations of the app. Other things you may be able to answer

Free Exchange of Ideas

Stephen mentioned it already, GitHub discussions is not ideal for everything. But even discourse isn't. To quickly toss around ideas in a free exchange of ideas, whether one thing may be worth implementing or not, brainstorming, quick questions and stuff like that, a less persistent medium may be more efficient. I suggest you all join me on OSM slack in #streetcomplete.

---

This is all that comes to my mind right now.

[smichel17]

I don't check Slack regularly, but I will receive an email notification if you @mention me, so please do that if you want my attention there.

[smichel17]

no PR is required for those that have write-access

I'm ambivalent about this, under almost any circumstances. Instead, what about immediately merging an own PR? That way there is no action required (and a merged-own-PR signals that in-depth review is not required), but there is still a notification and a place to add comments or refer back to, if necessary.

Edit: tried this in #3454

[westnordost]

Wouldn't matter for me because I don't get any notification for new issues or PRs anyway (I turned notifications except mentions off)

[smichel17]

I know that how active I am here is related to how much I go mapping. I was wondering whether the influx of issues which triggered this discussion was something seasonal, so I went looking for a way to visualize the issues over time.

I found https://9-volt.github.io/bug-life/?repo=streetcomplete/StreetComplete. It's not exactly what I was hoping for, and it's not zoomed in enough to see monthly trends, but perhaps it's interesting nonetheless. You need to authorize the app to work around rate limits in order for it to load, so here's a screenshot. The big drop is from 2020-09-04 to 2020-09-10.

[rugk]

Can one display the release son the timeline? A hypothesis could also be that after (large?) releases more issues come in…

[matkoniecz]

You would need to implement it - as this project is abandoned ( https://github.com/9-volt/bug-life )

EDIT: maybe there is some option for that?

[rugk]

Hmm I saw it in their example but uff, sad.

[rugk]

BTW for coding I can really suggest the Clean code cheetsheet .

About the comment with code comments hehe.

[rugk]

Side-note: Also conventional commits can be useful in combination with changelog generation out of this, even if they just keep it clean and can at least be used as a base. But yeah, just FYI.