This originally was about @dkayiwa merging PRs/modifying tickets for projects he doesn’t actively work on. Commenting is fine, actively triaging is not when you don’t know the roadmap for the project (granted there isn’t a published one right now for ID dashboard – the original issue that sparked this)
But let’s start a discussion about it. Sometimes PRs sit open for various reasons which a person outside the project wouldn’t get.
@r0bby, i think this is probably my mistake of not first explaining to the community what am doing.
In summary, am trying to look into our process of ensuring that we respond to volunteers in a manner that is timely enough to encourage them to contribute. To make them feel that we care about their efforts.
So along the way, i noticed that when they join, they choose different projects to work on, some of which am not directly responsible for, or even involved in. And this is a perfect example of the ticket that sparked this discussion: https://issues.openmrs.org/browse/ID-92
This is one of my findings:
Some claim tickets, start working on them, and take longer than i would expect. In such a case, i ping enquiring if they are still working on them. They can respond by saying, not any more. Then i make the ticket available for others. Could it be that they just forgot about it, then they can resume. Is it a blocker that they faced, then they can get help. And more…
In other cases, i have found tickets where they got blocked and even asked for help, but may be the one in charge possibly never got to know because they are not watching the ticket, or even just forgot because of the busy schedule and other things. So my ping comes in as a reminder. Some times my ping is as simple as, “hey, how is this going?”
For pull requests that remain open for long, my ping helps to ensure that the volunteer and the one responsible for merging are aware of why it is still open. That way it does not turn out to be like the cases of some pull requests raised long ago and we never attended to them, or took very long to respond.
On the contrary, we actually encourage as many as possible to review pull requests, even for projects they are not involved in. Some reviews can be as simple as syntax checks, logic error checks, code style, etc. Of course, they will not merge, as this is up to the project owner.
The more reviews a volunteer gets, the more they feel that the broader community cares about their precious contributions!
Yeah ID-92 is gonna stay for now. ID Dashboard is more or less in a code freeze – the less to sass conversion will likely happen sometime later after I deploy 2.1(the current state of the git master branch) and possibly be deployed as 2.2 or maybe 2.1.1 or similar. I really need to get the roadmap out of my head and somewhere public. So it being claimed for now is fine as I don’t want changes to ID dashboard unless they are absolutely necessary and don’t introduce regressions.
By all means – but merging without consulting is bad The more eyes the better. Some of the GCI PRs for ID Dashboard are one case. We left them open because we had to review them, one by one and pick and choose the best.
I don’t know the specific examples of merging without consulting, but I definitely agree that is bad practice.
That being said, I’ve been thankful for the work that @dkayiwa has been doing triaging and pinging on old tickets/pull requests… frankly, we’ve got a lot of leftover ■■■■ out there, and I’m glad someone is trying to prod us to get it in order. Even if it means a bunch of emails with old tickets for me to review when I get in in the morning…
Now that I know what he’s doing – I’m fine with it – but i’m still gonna leave this here. I know I violated this rule when I merged something to one of the projects I wasn’t involved with and broke things…so yeah we all make mistakes – Great work @dkayiwa