Yearly maintainer list cleanup

[jku]

Teodora stepping down as maintainer got me thinking that we should clean up the maintainers list periodically:

• I think both docs/MAINTAINERS.txt and especially the actual permissions lists (so github project, pypi, etc) should only list the maintainers who are actively using the elevated powers (so approving and merging PRs, creating releases, configuring services).
• this is basic security posture: anyones account can be compromised, so fewer elevated permissions leads to fewer project compromises
• all services should have > 2 active maintainers to minimize bus factor (and prevent project being locked out from critical services by accident)

Maybe a clearly separate "Emeritus maintainers" section in docs/MAINTAINERS.txt would be nice and would make moving psychologically easier? I would suggest a rough rule if you've not used elevated permissions in the past year or don't plan to use them during the next year, you might be a Emeritus Maintainer.

As an additional thing: it's not easy to check if the actual permissions are appropriate (as an example I don't think I can see who even has Github maintainer status) so maybe we should make a yearly issue to manually check them?

2022-01-24 situation looks like this:

• docs/MAINTAINERS.txt: @awwad, @mnm678, @trishankatdatadog, @lukpueh, @SantiagoTorres, @joshuagl, @jku, @sechkova (+@JustinCappos as consensus builder)
• github: ???
• PyPI: @jku, @joshuagl, @JustinCappos, @lukpueh, @SantiagoTorres
• ReadTheDocs: @jku, @sechkova, @joshuagl
• coveralls: ???

Teodora has already said she's moving to other things but how about others? E.g. @awwad, @SantiagoTorres any objections to becoming emeritus maintainers?

@lukpueh would you mind filling in the question marks on the list? Also would you like to make an account at readthedocs.org and let me know the account name so I can add you as maintainer?

[trishankatdatadog]

• this is basic security posture: anyones account can be compromised, so fewer elevated permissions leads to fewer project compromises

Agreed, I've already raised this issue before, but got radio silence.

[JustinCappos]

I'm supportive of this. Would like to see what @awwad and @SantiagoTorres <https://github.com/SantiagoTorres> think. Justin

…

On Mon, Jan 24, 2022 at 9:29 PM Trishank Karthik Kuppusamy < ***@***.***> wrote: - this is basic security posture: anyones account can be compromised, so fewer elevated permissions leads to fewer project compromises Agreed, I've already raised this issue before, but got radio silence. — Reply to this email directly, view it on GitHub <#1793 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGROD2JTOOI72JCPHD2SBLUXVH2PANCNFSM5MVKO7VQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[SantiagoTorres]

Overall I think this is something worth considering. Looking at the list here, I think we need to seek a bus-factor/overly-lax-access-control sweetspot. Not backed by much evidence, but i think wseeking 2/3 people may be the best.

FWIW I'm happy to step down if this makes everybody more comfortable.

[trishankatdatadog]

I'm okay with anyone being in the active maintainers list so long as they are recently active (which we should define).

[jku]

FWIW I'm happy to step down if this makes everybody more comfortable.

I wasn't trying to pick on you specifically btw: just picked names that I think I haven't seen merging or approving PRs lately

[mnm678]

This is a great idea. Folks can always rotate back in if/when they have more time for the project. I think 2-3 people makes sense in general, but it might be nice to have 4-5 when there is a minimum approval threshold to make sure that people can go on vacation and such.

[SantiagoTorres]

I wasn't trying to pick on you specifically btw: just picked names that I think I haven't seen merging or approving PRs lately

Haha yeah, I understand :) I was trying to be upfront about my standing on the line if we need to cut someboddy...

Then again, I'm also happy to review more over here if we're feeling low on eyes

[JustinCappos]

I honestly don't have a problem with Santiago or Sebastien staying on if they are interested and monitoring this conversation. They have good ideas / opinions when issues, etc. arise. I think the point was more if they've moved on and tuned out we should perhaps drop them.

…

On Tue, Jan 25, 2022 at 1:32 AM Santiago Torres ***@***.***> wrote: I wasn't trying to pick on you specifically btw: just picked names that I think I haven't seen merging or approving PRs lately Haha yeah, I understand :) I was trying to be upfront about my standing on the line if we need to cut someboddy... Then again, I'm also happy to review more over here if we're feeling low on eyes — Reply to this email directly, view it on GitHub <#1793 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGROD3WCIDXFD3FDLSU6MDUXWEKRANCNFSM5MVKO7VQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[jku]

I honestly don't have a problem with Santiago or Sebastien staying on if they are interested and monitoring this conversation. They have good ideas / opinions when issues, etc. arise.

Maybe there is a disconnect here, because that sounds like you believe I suggested something I did not intend to. I know I sometimes skip the reasoning to go direct to conclusions so I'll try to make my position clear:

• I value the experience of everyone who's been working on this tech, now or before. It's also vitally important to make contributions easy for both old and new contributors: I absolutely don't want to create barriers or push anyone away
• sharing experience (and contributing in many, many other ways) does not require pypi.org upload permissions
• more people with pypi.org permissions increases the risk for all users of this project

[jku]

I wasn't trying to pick on you specifically btw: just picked names that I think I haven't seen merging or approving PRs lately

Haha yeah, I understand :) I was trying to be upfront about my standing on the line if we need to cut someboddy...

Then again, I'm also happy to review more over here if we're feeling low on eyes

Too few eyes does not seem like a pressing issue just right now but diversity could certainly be better (quite a few of us are from VMware after all) so that would definitely be appreciated... That said, reviewing code does not require github maintainer permissions and even merging does not require pypi.org permissions. I'm actually quite happy to see a "culture of review" in the project currently: practically all active contributors currently do reviews.

[JustinCappos]

Okay, thanks Jussi for your clear and compelling point. I agree that the distinction makes sense and we should drop github maintainer permissions for Santiago and Sebastien. Should we keep them in python-tuf/docs/MAINTAINERS.txt or is it not worth the confusion? I don't have strong feelings.

…

On Tue, Jan 25, 2022 at 4:16 PM Jussi Kukkonen ***@***.***> wrote: I wasn't trying to pick on you specifically btw: just picked names that I think I haven't seen merging or approving PRs lately Haha yeah, I understand :) I was trying to be upfront about my standing on the line if we need to cut someboddy... Then again, I'm also happy to review more over here if we're feeling low on eyes Too few eyes does not seem like a pressing issue just right now but diversity could certainly be better (quite a few of us are from VMware after all) so that would definitely be appreciated... That said, reviewing code does not require github maintainer permissions and even merging does not require pypi.org permissions. I'm actually quite happy to see a "culture of review" in the project currently: practically all active contributors currently do reviews. — Reply to this email directly, view it on GitHub <#1793 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGRODY5GJSN3LS6WT63VP3UXZL4FANCNFSM5MVKO7VQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[joshuagl]

I think an emeritus maintainer status helps indicate folks who have, and may continue to have, a large influence while making it clearer who are the folks with elevated permissions and who they can expect a response from when .

I'm okay with anyone being in the active maintainers list so long as they are recently active (which we should define).

Agree that we should define this. Typically projects define inactive contributors as someone who has not made a contribution within a fixed period of time i.e. Kubernetes defines inactive contributors as someone who hasn't made a change for 18 months.

Therefore, if we're proposing an annual maintainer list review an inactive maintainer would be one who has not used their elevated maintainer privileges in the prior year?