Add emeritus to owners guidelines

[mrbobbytables]

Adds "emeritus" to owners. This should be safely ignored by prow, and something we can build future tooling around. The intent is to provide a means for contributors who have potentially shifted roles or may be less active for a period of time to remove themselves from automated assignment, but still have an entry there if another opinion is needed.

The suggested change is just to mimic the owner spec under the emeritus keyword. This would make it easy for people to swap over, but less useful for future tooling. An alternative might be to mimic + do something like this:

emeritus:
  approvers:
  - name: bob
    date: 2019-04-22

Which would make it easier to build a report or dashboard on.

ref: kubernetes/kubernetes#76269 (comment)
ref: kubernetes/test-infra#10226 (comment)
ref: https://youtu.be/MS0AB0Sm6iA?list=PL69nYSiGNLP2x_48wbOPO0vXQgNTm_xxr&t=578

/cc @dims @nikhita @cblecker @spiffxp

[nikhita]

Thanks Bob!!! 🎉

Which would make it easier to build a report or dashboard on.

I like the alternative version more because it can help us in auditing later.

[spiffxp]

I’m wary of the date field, blame or source control can be used for this. The sigs.yaml fields lack this

I’m also not clear why mirror the spec, I think the only emeritus we care about is approvers, no?

[mrbobbytables]

I’m also not clear why mirror the spec, I think the only emeritus we care about is approvers, no?

That is really what we care about, yes -- My general thought there was more to play to the social aspect of it. People generally don't want to remove themselves from something once they're there. Being in an owners file is considered climbing the ladder, removing completely is a step down. Being added as emeritus still leaves them in there.

[cblecker]

Thinking about it, I don't think we need emeritus reviewers. I also agree with @spiffxp that we don't need a date.

[mrbobbytables]

👍 I'll update to just target approvers.

[spiffxp]

more comments

[nikhita]

/cc @fejta
because you have opinions around this? (kubernetes/test-infra#10226 (comment))

[fejta]

What more does this accomplish than what we can do already:

approvers:
# - fejta (emeritus)
- mrbobbytables
- nikhita
- spiffxp

Prior art: https://github.com/kubernetes/test-infra/blob/5406eea909597700cfe778d2d3fddf421f5284c1/prow/OWNERS#L8

[mrbobbytables]

It has been used informally in a few places. Trying to put some language in here for wider use and encourage folks to self-remove; along with adding a potential avenue for future tooling.

[fejta]

One might interpret this to mean that prow will not use emeritus_approvers to assign people work while still granting emeritus_approvers the ability to approve code.

If so then this seems even better than being a regular approver -- all the same power without the hassle of helping others.

[mrbobbytables]

Can call that out more explicitly. Something like:
"GitHub usernames listed under the emeritus_approvers key can no longer approve code (use the /approve command) and will be ignored by prow for assignment."

[fejta]

The specific request in kubernetes/test-infra#10226 (or at least my understanding of it) is to provide a way to give people the power to approve code without the responsibility of ever getting assigned any boring work. I think this is an unhealthy social pattern that we should avoid.

It is unclear whether this is attempting to make a glorified yaml comment (functionally equivalent to removing the approver). If so then my concerns are minimal -- although I would prefer a comment as it would be much harder to teach prow to empower a comment than the emeritus_approvers list.

In terms of the social aspect, I like the idea of encouraging people to remove themselves from the approver list. We could automate this by looking for people who have neither contributed nor reviewed code under a given path for a certain period of time and create a PR that adds them to the emeritus list (using whatever mechanism).

[mrbobbytables]

It is unclear whether this is attempting to make a glorified yaml comment (functionally equivalent to removing the approver). If so then my concerns are minimal -- although I would prefer a comment as it would be much harder to teach prow to empower a comment than the emeritus_approvers list.

It is more inline with the yaml comment. Adding it as an key instead of a comment was more so future tooling could potentially be built around it.

In terms of the social aspect, I like the idea of encouraging people to remove themselves from the approver list. We could automate this by looking for people who have neither contributed nor reviewed code under a given path for a certain period of time and create a PR that adds them to the emeritus list (using whatever mechanism).

💯

[fejta]

Official comment that prow ignores SGTM

[fejta]

/lgtm

[spiffxp]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mrbobbytables, spiffxp

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• contributors/guide/OWNERS [spiffxp]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment