Add process to remove maintainers that don't fulfill their duties

[serathius]

When asking CNCF for support due to reduced community activity we stumbled upon a problem, governing board was surprised that project is unmaintained if there is so many maintainers listed.

Feedback from CNCF governing board was to improve accuracy of maintainers list so it reflects only active maintainers. Self nominating process it not enough and we need to start enforcing moving maintainers to emeritus status. Period of 9 months to take maternity leave into account.

Signed-off-by: Marek Siarkowicz [email protected]

cc @ptabor @ahrtr @spzala @gyuho @mitake @jingyih @jpbetz @hexfusion @wenjiaswe @xiang90 @bdarnell @tbg @lilic @wilsonwang371

[serathius]

Note, possibly we should do the same for reviewers, but first we need to define their responsibilities.

[codecov-commenter]

Codecov Report

Merging #14238 (188ea54) into main (525d53b) will decrease coverage by 0.19%. The diff coverage is n/a.

@@            Coverage Diff             @@
##             main   #14238      +/-   ##
==========================================
- Coverage   75.35%   75.15%   -0.20%     
==========================================
  Files         456      456              
  Lines       36916    36919       +3     
==========================================
- Hits        27818    27747      -71     
- Misses       7364     7423      +59     
- Partials     1734     1749      +15     

Flag	Coverage Δ
all	75.15% <ø> (-0.20%)	:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
server/auth/simple_token.go	80.00% <0.00%> (-8.47%)	:arrow_down:
server/etcdserver/api/v3lock/lock.go	61.53% <0.00%> (-8.47%)	:arrow_down:
client/pkg/v3/tlsutil/tlsutil.go	83.33% <0.00%> (-8.34%)	:arrow_down:
client/v3/experimental/recipes/queue.go	58.62% <0.00%> (-6.90%)	:arrow_down:
client/v3/experimental/recipes/priority_queue.go	60.00% <0.00%> (-6.67%)	:arrow_down:
client/v3/namespace/watch.go	87.87% <0.00%> (-6.07%)	:arrow_down:
server/etcdserver/api/v2discovery/discovery.go	63.31% <0.00%> (-5.88%)	:arrow_down:
server/lease/lease.go	94.87% <0.00%> (-5.13%)	:arrow_down:
server/storage/mvcc/watchable_store.go	84.42% <0.00%> (-4.35%)	:arrow_down:
client/v3/leasing/cache.go	87.77% <0.00%> (-3.89%)	:arrow_down:
... and 19 more

Help us with your feedback. Take ten seconds to tell us how you rate us.

[hexfusion]

In the context of removal what is the process for reactivation? Can we elaborate/flesh this out a bit?

Folks shift projects, jobs etc.

I can see the motivation for cleaning up the list.

[jpbetz]

Yes, I feel like I'm in the same boat as @hexfusion. I'm not active on the project and so I'd like to change status to something that reflects that, and also help ensure the active maintainers are easy to find and are appropriately recognized. I can imagine that I might return to work on the project again in the future, so having some idea how that process would work would be valuable to me, and probably quite a few others on the list.

[ahrtr]

Basically I am on the same page as @spzala . The point is the existing maintainers have already demonstrated great expertise and big contribution to the community, they should be always welcome if they want to contribute back to the project.

The only minor comment is we still need to clearly clarify the process on how to add any maintainer from emeritus list to the maintainer list. If someone (assuming A) in the emeritus list want to be added back into the maintainer list, then my thought is that A is supposed to follow the process something like below,

• Keep active in the community at least one month;
• A doesn’t need to be nominated by any existing maintainer; Instead A can raise a ~issue~ PR in the community himself/herself, and cc all existing active (all inactive maintainers should have already been moved to the emeritus list) maintainers, and list all his/her contribution at least in the past month;
• If there is no any objections in 3 working days (I believe there will be no any objections if A indeed has already been active for at least one month), then A will be added back to the maintainer list.

[spzala]

Thanks @ahrtr I agree with the overall thoughts and that we need to put this in the process. We know and trust that any emeritus maintainer/reviewer who can get back to active contributions means it, and so I think we should keep the process very simple (I am open to any more ideas but this is what I think):

• When an emeritus maintainer(s) is back to contributing to the project and wants to be back to take the maintainer/reviewer role, they will open a PR to add themself back to the MAINTAINERS file.
• Per two or more existing maintainer reviews or lazy consensus of a working week or three days (as you suggest), a current maintainer will merge the changes and make needed GitHub admin-related changes.

[serathius]

Note: with @spzala approval we have started the 3 weeks lazy consensus timeout.

[serathius]

We passed the lazy consensus time (3 business weeks). Feedback from @hexfusion and @jpbetz was also incorporated, allowing emeritus maintainers to imminently regain their status when they renew their contributions.

With 3 maintainers approval we can merge the change.

[ptabor]

My small after-thought (influence also by recent issue), is that maybe we should keep RAFT maintainers as is. There is no activity, as project is considered stable/done, but when help was needed they act. In particular @tbg is advising(#14370), coding(#14413) reviewing (#14538),

[tbg]

It looks like I was removed from the etcd-maintainers project a few days ago, which means I can't approve raft PRs any more, just checking that this was intentional since the above message indicates a desire to keep me on that team.