Maintainers Circle Proposal
parispittman opened this issue · comments
Leadership circles help in large environments where many people operate independently. In this specific case, maintainers at 40+ CNCF projects. //add more summary here
Goals:
- Training
- Collaboration points on strategic issues; tackling size:L OSS issues
- Camaraderie / bringing people together
- Listening (to build better programs, relationships, and sustainability efforts)
- Share Best Practices
- Highlight successes
NonGoals:
- Sell to you - zero tolerance
Next Steps
- Recruit (paris, stephen, COULD BE YOU - comment here!)
- Define maintainer here (zach) / update README with this information
- "A maintainer is anyone recognized as a maintainer of a project by that project's standards."
- We will include 2-3 examples of project maintainer definitions on the readme, too.
- someone who commits, has an overview of their project area or whole project, usually the final responsibility
- Update goals above and create a robust README (paris)
- send welcome email to dev lists.
- set up inputs and outputs: slack channel and ways to get a hold of each other - submitted CNCF servicedesk ticket for #maintainers-circle
- Bring in Liz, gb reps (michelle, matt), and others to see how we can all work together on similar goals under the same umbrella. they have n cadence meetings with similar maintainer crowd for governing board representation - see if they can come to thursdays meeting - continue this on a separate issue
What does done look like for this issue?
When we have a "come hang out with us" email ready to ship and approved by the group
Open Ended Questions
- //add more here
stephen and i will take this and bootstrap it
@parispittman 👋 I'm happy to boost you and Stephen here. What do you need?
Is 40 a limit, or is it just the number of projects we currently have?
@zacharysarah need help collaborating on definition of a maintainer here so that we can put out a call on the lists. the thing is at the cncf level the word maintainer means a specific thing to voting (in TOC elections as example) which is a much smaller population of folks than I was scoping. I'm thinking folks who have reviewing/approving perms, write access to repos, etc. This is hundreds in Kubernetes but that's ok - not everyone is going to be interested in this stuff and we can make it accessible. I do want to limit though because then we would be talking thousands and want to scope this to help those that can make sustainability decisions and those that need the camaraderie/support/etc. ideally this would go on the README in the folder. down to help with your word prowess? :)
also @justaugustus i updated the above checklist with some stuff and added some foundational things; @zacharysarah - what else are we missing at this stage? thinking high level right now before we open the gates.
need help collaborating on definition of a maintainer here
Hoo boy this is a tough one. There's a wide variation in how projects define and identify maintainers, and whether their maintainers are identifiable as maintainers at all.
For example, compare the GOVERNANCE.md files for:
-
Containerd: "Maintainer" is clearly defined, maintainers are called maintainers
-
Vitess: "Maintainer" isn't defined, uses PMC for leadership instead, but CNCF TOC still refers to maintainers in Vitess graduation criteria (??)
Any definition we create will almost certainly generate friction and pushback from some element of the community, for reasons that may be 💯 valid and 💯 unhelpful.
TLDR: That's a great question, let me think about it.
/cc @caniszczyk
and definitely don't want to push our definition of maintainer on to others either fwiw @zacharysarah ! for this purpose, it's folks that we are providing leadership guidance, etc. if we make the definition then folks can self ID in, we won't check IDs at the door :)
Any definition we create will almost certainly generate friction and pushback from some element of the community, for reasons that may be 💯 valid and 💯 unhelpful.
agreed, one of the things the contributor growth working group can help cover is defining what the projects have and help build up some consistency without generating friction.
folks that we will want to attend -
cncf project maintainers:
(whatever word they self ID into; maybe we can comb a few more projects like you did above for vitess and containerd and see what else we are missing)
- maintainer
- approver
- owner / subproject owner
- reviewer (anyone can technically provide a review or feedback; trying to capture the folks that maintainers look to growth; in a role labeled reviewer of some variety)
For a definition of maintainer, how about:
A maintainer is anyone recognized as a maintainer of a project by that project's standards.
It's tautological, but what do you think?
hm not bad i say @zacharysarah! heh- included this in the body of the issue.
we could list some of the ones we know as examples, too, that show some of the differences so it might paint a clear picture that way.
will set separate issues for some of the items above and get moving on those.
+1 to the tautology of it all!
I think an additional heading of "You might be a maintainer for your project if..." and some pointers to help someone self-ID, would be dope too. :)
Update - submitted cncf servicedesk ticket for #maintainers-circle slack channel creation
/close - launched first stage