Clarify how to make progress on a PR

[reyang]

Changes

This was discussed in the 7/27/2020 specification SIG meeting.
The goal is to have a better clarity on how to make progress on PRs.

[cijothomas]

LGTM.
Left couple of minor, non blocking comments.

[carlosalberto]

what percentage of their lifetime do they spend waiting for a maintainer to merge them after having enough approvals?

I don't think that happens that much. What happens sometimes is that a maintainer or approver requests changes, hence blocking the PR.

[anuraaga]

I don't think that happens that much.

The recent official triage during SIG has sped things up a lot from what I've seen, but I also worry about the scalability of it. This is so recent though that the current best practice for my team is still, "to get a PR merged, join the SIG meeting" - I hope this can go away as the new triage process shows fruit, but I wouldn't be so optimistic about this quite yet.

[carlosalberto]

@anuraaga I disagree. Most PRs with enough approvals have been merged properly. The problem is mostly with unsolved issues or lack of reviews, which indeed sadly forces authors to join the SIG call to ask for attention (on which we still need to do a better job).

[arminru]

I'd also add that any significant change should be clearly mentioned in a separate comment to not go unnoticed.
If the PR turns into a different direction after approving reviews, those should be dismissed and asked for a re-review.

[carlosalberto]

(Same as the previous comment)

[anuraaga]

I was reminded of this again after seeing

#606

Sorry to say it again but I'm a bit surprised maintainers would contend that PRs get merged properly. I have seen too many times they get stuck because approvers / maintainers don't take charge and get them through. Pinging a reviewer for more input is the easiest way to kill a PR currently since often that input doesn't come.

So I propose this PR doesn't go far enough - it still puts too much burdern on the contributor, the language even seems to lean towards "the contributor is probably wrong". It's the maintainer's responsibility to move things along (either yes or no, the result is not as important). For this to be a community, I think we need process here that puts more responsibility on maintainers. BDFL model makes this the easiest, but lacking that we need something that can still come close or contributors will just go away when they try something but no one proactively helps make it happen.

[carlosalberto]

it still puts too much burdern on the contributor, the language even seems to lean towards "the contributor is probably wrong". It's the maintainer's responsibility to move things along (either yes or no, the result is not as important). For this to be a community, I think we need process here that puts more responsibility on maintainers.

I disagree partially - for sure, maintainers need to be more proactive on handling (stale) issues and PRs, but we expect OTel organization members/approvers to put their own cycles to move their issues/PRs forward. For example: it's very common that the author gets busy and forgets about the PR (I can already see a few of them currently open), or they simply forget to provide feedback.

For external contributors that's something else - but we can worry about that once we hit GA (I'm pretty sure we will get a lot of external users feedback/requests changes).

[bogdandrutu]

Blocking this PR since it is not the right place to change community membership decisions.

[Oberon00]

@bogdandrutu Where would be the right place to discuss this? I think TC approval and a community repository PR will certainly be needed, but I believe that discussing this (also) here is best for visibility.

[bogdandrutu]

I think the right place is in public in a community issue, because the gouvarnance is responsible to define that role

[bogdandrutu]

I know I wear two hats here but would prefer other members of the GC to have visibility into this, and they usually don't follow this repo

[carlosalberto]

Let's just remove the 'offending' part and discuss it somewhere else (most likely as an issue the community repo, as outlined by @bogdandrutu ) so we can move forward this PR.

[Oberon00]

Suggested change

	on each other), the owner should try to get people aligned by:
	with each other), the owner should try to get people aligned by:

[bogdandrutu]

This is hard to enforce by GitHub, but I am fine with this in general

[carlosalberto]

Agreed. We can look into this in the medium future.

[carlosalberto]

We were meant to merge this last week, but as they say: better late than never!