cncf/tag-contributor-strategy

CNCF Technical Advisory Group on Contributor Strategy -- maintainer relations, building up contributors, governance, graduation, and more.

CNCF TAG Contributor Strategy

Contributor Strategy is a Technical Advisory Group (TAG) responsible for contributor experience, sustainability, governance, and openness guidance to help CNCF community groups and projects with their own contributor strategies for a healthy project.

If you are looking for how-to resources produced by the TAG, please visit contribute.cncf.io or have a look at the contributor, goverance, and related templates.

For people new to this space, you can learn more about the purpose, objectives, and responsibilities of CNCF TAGs.

The TAG Contributor Strategy charter outlines the scope of our group activities. To get involved, our Contributing Guide lays out more details.

• Meetings

• Communicating with Us

• Members

  • TAG Chairs
  • Tech Leads
  • TOC Liaisons

• Working Groups and Teams

  • Governance WG
  • Contributor Growth WG
  • Mentoring WG
  • Maintainer's Circle
  • Inclusiveness Team
  • Deaf and Hard Of Hearing WG

• Project Board

• Contributor Strategy Overview Diagram

• Valued TAG Members

Meetings

We have one general meeting a month, along with meetings for our working groups. Go to the CNCF calendar to see when we meet next.

• Meeting minutes and agenda
• All meetings are recorded and can be accessed on the CNCF TAG Contributor Strategy Youtube channel.
• Meeting Link: zoom.us/my/cncftagcontributorstrategy
  • Meeting ID: 574 406 1161

Communicating with Us

Anyone is welcome to join our open discussions of TAG Contributor Strategy projects and share news related to the group's mission and charter. Much of the work of the group happens outside of TAG Contributor Strategy meetings and we encourage project teams to share progress updates or post questions in these channels:

• Mailing list

  • The mailing list is used for decisions, announcements, and broad communications on record for the entire TAG.

• #tag-contributor-strategy on CNCF Slack

  • Real time communication is great! Chat with us here but we might ask you to open an issue or remind us on the mailing list so we can have a record.

• File an Issue

  • Working on a project? Have an idea for something we/you should work on? Talk about a change you'd like to propose?

• Attend our meetings

  • We meet once a month, and we'd love to have you join us!

Members

TAG Chairs

• Dawn Foster (@geekygirldawn), CHAOSS Project
• Josh Berkus (@jberkus), Red Hat
• Catherine Paganini (@CathPag), Buoyant

Tech Leads

• Ali Ok (@aliok), Red Hat
• Riaan Kleinhans (@Riaankl), Linux Foundation

TOC Liaisons

• Emily Fox (@TheFoxAtWork), Apple
• Dave Zolotusky (@dzolotusky), Spotify

Working Groups And Teams

TAG Contributor Strategy has working groups and teams to effectively collaborate and coordinate efforts towards achieving common goals and objectives, as well as to distribute tasks and responsibilities among its members for efficient execution. This approach allows for a more streamlined and organized approach to managing complex projects within the CNCF ecosystem.

Governance WG

Charter

Contributor Growth WG

Charter

Mentoring WG

Charter

Maintainer's Circle

Charter

Inclusiveness Team

Status: Proposed

Deaf and Hard Of Hearing WG

Charter

Project Board

All the activities of TAG Contributor Strategy as well as our Working Groups and Initiatives are tracked on our Project Board. We invite you to explore the board to stay updated on our ongoing endeavors. If you have a particular Issue or PR you'd like to contribute to, please feel free to join us in our efforts.

Contributor Strategy Overview Diagram

Valued TAG Members

A big thank you to all the previous contributors of this TAG! Your hard work and dedication have helped to make this project a success. Your valuable contributions have enabled us to develop a strong contributor strategy and build a thriving open-source community. Thank you for all that you have done!

tag-contributor-strategy's Issues

suggested topic for maintainers circle: values/principles

value creation, principles, creating community norms and culture, etc.

Create a Recruiting Contributors Playbook

1 - do some discovery on what works and doesn't with other cncf projects
2 - more research
3 - collaborate on a playbook
4 - win.

//will update this issue with more information soon

[Discovery Umbrella] Inventory and Things

Streams that will kick us off and set us up for success. We can set separate detailed issues for each with their respective owners.

Things we are going to need to move forward:

• #15 Resources page

• create short, focused survey [beating the keep to our scope drum] to send to project maintainers #19
  paris/karen

• draw out the contributor related items needed for graduation and other should and nice to haves to start on contributor health check due diligence for TOC
  Josh/Gerred/Stephen/Paris

People to meet with:

• GB Reps: Matt and Michelle. Talk about how we can work together to feed this group with some of the contributor related things coming from past and current discussions with maintainers. The GB Reps will also deal with matters that are out of scope with us so make sure we find common ground vs combining efforts. We shouldn't be in or out of their way - need a happy middle.
  (potential artifact: list of contributor related needs, add to charter roadmap where necessary or add to the 'future roadmaps' section so others can pick up that might want to work on it.
  Gerred

• talk to matt about how he wants updates, info, etc.
  chairs

• talk to cheryl about getting a program bootstrapped for contributor<->end user
  bootstrap with cncf members, open to other end users
  start a separate issue
  paris/stephen/ihor/karen

What else?
Reminder: our SIG is high risk for scope creep. Stay cautious :)

Logo options for TAG ContribStat

Our designer has dropped a PDF of various different designs, let me know if any of these are directions we want to go in!
tag-contributor-logos-v1.pdf

maintainers.cncf.io: should we create a page here?

right now it's being used to host the public maintainers list for TOC voting purposes but I can invision this as a page where maintainers of projects can grab information, form community, and have a one stop shop for everything that they need from the ecosystem.

it can continue to host the public spreadsheet with a note about what it is, host the cncf/project-templates, all maintainers-circle information and maybe a curated events list.

this could be nested under cncf.io/people or cncf.io/community

what do folks think? other ideas?
Discussion from two meetings:

• good idea, will be good to surface the content that we create and get things out of github
• house the following:
  • cncf/contribute
  • cncf/project-templates
  • maintainers list
  • upcoming events for contributors / maintainers
  • maintainer circle information
  • highlights on contributors?

maintainers circle topic: recruiting contributors

in similar area as #18 - maintainers want to hear stories from other maintainers in this subject

Help existing projects learn about what the CNCF can help with

For maintainers who missed or didn't get the latest onboarding materials for the CNCF, perhaps because their projects were accepted very early on, they may not be aware of all the nice things the CNCF can do for them. Let's write up an advisory doc and mention it in some of our key templates so that they are aware

https://www.cncf.io/services-for-projects/

create a resources page

our meta resources page with links that we will pull information from for us to do our work

examples:
other sites that have oss templates for contributors and governance
governance and contributor research links
todo group applicable links
new contributor best practices, etc

should live in this repo vs contribute

suggested topic for maintainers circle: inclusive language

k8s is brewing up a working group for inclusive language changes in the project. we should surface this work and others from different communities to create best practices.

this could be a good first topic for maintainers circle.

Rename SIG ContribStrat --> TAG ContribStrat

I've been known to do a little search/replacing in my day, so I'll take this up now that the vote has passed.

Things to think about:

• simple search/replace
• potential link-breaking:
  • repo name (shouldn't break in the case of a single rename): #100
  • Zoom meetings
  • Calendar things?
  • mailing list
  • website references

cc: @parispittman @jberkus @amye
(FYI and for anything I'm missing off the top of my head)

Maintainers Circle Proposal

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

Create a discovery survey for contrib programs and gov

Updates:

Survey questions

Communication timeline:

start Monday June 21

1. • send to project dev/maintainer lists and one of us should personally reach out as a welcome
     • Paris
     • need owners/volunteers to visit some community meetings for a personal note, and/or reach out to individual communities -dev/contributor/maintainer lists
       • April is taking grpc
       • Carolyn/Karen - Helm
2. • toc meeting; josh/paris will include in the update
     • josh/Paris to own - this is July 7th; also send to toc list and toc slack channel
3. • project dev/maintainer and cncf applicable slack channels (#toc, etc)
     • Paris; if you'd like to take your projects channel feel free
4. • ambassadors - private slack channel
     • April
5. • post to cncf blog and twitter;
     • Julie created a draft; needs review
     • should go last and after all projects have been contacted personally or on mailing lists

communication that should be personally modified based on the send out:
https://hackmd.io/WFp3xWgWSM6ijzluQ3CZtQ?edit

——-

the scope of this is to be used:

• as a form to be filled out, or
• focus group questions

goals:

• dig deeper into the contributor programs and governance of cncf projects
• collecting best practices, whats not working
• in survey form, no more than 5-8 minutes; survey fatigue is real
  resources:
  don't ask repeat questions from here https://github.com/cncf/surveys/

timeline:
ASAP

Write advisory document on how to run an OSS election

Per today's Gov meeting, more TBD.

Launch Contributor Growth Subproject

notes: p0 = priority before the rest and then 1, 2 and so forth

streams to get us off the ground, subsequent issues to be filed:

• help with templates (contributor guide, developer guide, cheatsheets, etc) (carolyn, karen, paris, could be you? respond in comments) p0
• conduct some small discussions/talks/webinars on topics that we already have queued (comment with topics that you have decks/presentations for) - paris set separate issue p0
• contributor ladder building (carolyn, karen, could be you? respond in comments) p0
• recruiting contributors: plans of action, communication best practices (paris, hippie, could be you? respond in comments) p1
• role handbook templates, building of roles outside of the usual contributor ladder (p1) (paris, carolyn, karen, could be you? respond in comments)
• project management guidance (project boards, processes, automation, github actions that could help?) (carolyn, possibly priority1-2)
• some kind of survey/issue to collect information for all of the projects to discover what programs, templates, and more that relate to these efforts. what works/programs they like, what doesn't work/programs that need improvement. goals: add more of what works to our resources list (needs owner)

what's done for this issue

• this issue will close with a README somewhereTBD
  • make our group clear in the README (why, where they can get help for specific things ie - sig-contribex in k8s, who owns what?)
• who is kicking off what/owners of things
• what does the first thing we accomplish look like? definition of 'done' for things?
• folks will assess in the next 1-2 weeks; try to deliver on a Thing in 2-4 months
• send a note to TOC and maintainer about AMA - contributor growth q&a (probably through the ama at our 4th thursday meetings?
  • let's go with this for now; change as necessary

Notes: https://github.com/cncf/toc/blob/master/process/due-diligence-guidelines.md#project

Kick off meeting will be April 13th at 530pm UTC [comment here if you need an invite; join the mailing list: [email protected]]. We will regularly meet with the larger group at our usual bi weekly time. Our first meeting is to talk out our initial steps and the above questions.

project health?

a few folks from various projects have asked: what's project health? without going into a hole of why it's not great to list stars and things as health, it would be good to discuss how other folks have measured project health, define it (even broadly), to help with the requirement and discuss the project health dashboard that devstats provides: https://all.devstats.cncf.io/d/53/projects-health-table?orgId=1

[Meta Bootstrap] All things us - what we need to launch this SIG

all things bootstrapping and getting us off the ground - administrative or otherwise (mostly admin though)

• chairs should discuss meeting facilitation, zoom keys, et al
  JOSH/PARIS (auto record, goes to youtube) - done

• biweekly is the result. working groups that spin up organically with their own meetings is fine but lets try to keep meetings down to a minimum. mailing list and slack for discussions, github issues for collaboration. [add this to the README]
  2 meetings a month - one will be 30 mins of AMA dedicated to contributors/maintainers of CNCF projects "office hours"

• need to create the following for the root:

• README.md - stephen

• CODE OF CONDUCT - ihor

• CONTRIBUTING.md / engagement / how to engage with us - paris

• some kind of owners/codeowners/contributors.md - gerred/josh/stephen

• settings.yaml - josh

• folder for the maintainers circle documentation - paris

• assessment folder for the due diligence documentation - josh

Draft community/contributor management guidance

working here: https://hackmd.io/wZleAQC2SPCtQoUzZFNOJw

There needs to be a requirement for graduated projects with more than 1k contributors for community support as it's a lasting function that needs continuous support.

There are a number of ways to do community management for an open source project, including cncf services. Let's draw those out in a doc and list what they are, why, benefits, etc. good end goals could be a) a doc for guidance and b)eventually come up with a recommendation for TOC for graduated projects.

examples of graduated project strategies:

• should there be a part time, full time community manager(s)?
• should there be committees, working groups, sigs = some kind of group that would cover community (ex: sig-contributor-experience)
• are community operations are included in all roles or some roles that are defined and have ownership?

working here: https://hackmd.io/wZleAQC2SPCtQoUzZFNOJw

Draft revisions to Multi-Org Requirement for Graduated Projects

The TOC has asked to write a doc that presents clarified "diversity" requirements for project graduation.

The current requirements say simply:

Have committers from at least two organizations.

This has become problematic in several project reviews, because there is no consensus on what "committer" means in this context. It also really doesn't cover the complexity of some of our more established projects.

As such, I've created a gdoc for us to edit into what we think the requirement should be (comments only, request edit ability through gdocs).

@thisisnotapril

Advisory document on non-code roles

Since we want to advocate for acknowledge non-code roles in the project, we should have a guide that discusses the value of the roles, types, and how to ensure they are on equal footing with other roles.

Rename master branch to main

Need to fix this.

@carolynvs, let me know what steps are required to not break the website.

How to moderate a meeting

We should provide guidance for leads on why moderated meetings are more inclusive and improve participation. Then provide guidance on:

• how to select a moderator (probably should not be someone very active in the conversation if possible)
• rotate the role so it's not always the same person
• how to "raise your hand", queue up people to speak
• Coach the moderator on interrupting someone who is talking too much, or out of turn
• Identifying people who want to speak, e.g. someone who is unmuting their mic/video
• Repeating and answering questions in chat
• etc

Determine set of initial labels

We need to set up some labels for this repo, to be canonicalized in settings.yml. Here's my suggestion for some:

• wg-whatever: each WG should have its own label
• new-wg: proposals for not-yet-approved WGs
• infra: issues/PRs related to github, chat, ML management
• needs help: issues/PRs that are stuck and need new people
• good first issue: the usual meaning
• meeting: items that need to be discussed in the next SIG meeting

Draft Maintainers Circle Welcome Email

• create a welcome email to send to the maintainer lists including an action (example: join the maintainer slack channel) (merged with #19)
• Try and recruit at least one voice per project (this is optional but will be good to have someone/small group to keep in constant contact about contributor related matters) and keep a record somewhere TBD (need clear ownership on this)
• think about what we would want the first meeting to look like or whatever it is that we are delivering. whats a good valuable first step? (need clear ownership on this and discussion)

WG Governance Content Tracking

The primary duty of WG Governance is developing a variety of content to help projects develop governance.

This is a tracking issue to track which content we've created so far.

Advisories

These are general advisories to projects on developing their own governance. There is considerable overlap here with Contributor Growth docs.

• What is Governance (jberkus)
• How to write a How To Contribute (carolynvs and team)
• How to create a contributor ladder (parispittman and team)
• How to write role definitions, with examples: (cointrib Growth, josh to coord)
  • member
  • contributor
  • leader
• How to do leadership selection, with examples: (dawn foster and team)
  • committer-based
  • self-selecting council
  • elections
  • how to make your leadership more diverse
• basic policies and procedures for projects (jberkus)
• security issue handling guidelines (SIG-Security?) (Jennifer)
• How to shut down/archive a project (April)
• How to keep your communications open (April)
• Resource list (in progress)
• goverance.md (good ideas in https://sustainers.github.io/governance-readiness/)
• charter (Dawn)

Requirements

These are documents specifically on fulfilling the CNCF requirements for each project stage. They will also involve adding depth to each requirement, which will need to be approved by the TOC.

Sandbox:

• have how to contribute document (link to template, mostly)
• adopt the CoC and CoC enforcement (needs to work with CNCF staff)
• Adopting the CNCF CoC and IP Policy, a practical guide

Incubating:

• have basic leadership & selection documentation
• three end-users
  • getting end-user participation
  • definition of an end user

Graduated

• have full governance documentation
  • how to contribute
  • full role definitions (min. member, contributor, leader)
  • contributor promotion (ladder)
  • security issue handling
  • if project uses DCO/CA, full docs
• multi-organization requirement
  • attracting outside maintainers
  • adding a varied Steering Committee

ContribStrat GitHub Management

To better facilitate issue creation/maintainance and pinging ContribStrat on issues/PRs, I'm seeing a few potential improvements:

• Add SIG ContribStrat members to CNCF GH org (allows easier pings and issue assignment)
• Create GH teams:
  • sig-contributor-strategy
  • sig-contributor-strategy-leads
• Grant leads access to administer this and the community repo suggested
• Project board(s) for the team

This currently just a rough list, but I wanted to get the conversation started.

cc: @parispittman @jberkus @gerred @amye @idvoretskyi
ref: #3

host guide for maintainer circle

create a guide and sample script for future hosts of maintainer circle

Update chairs listed in the README

I believe I saw that Gerred has stepped down and Stephen has joined the co-chairs?

values and principles framework

create a guidance doc for values and principle building, changing, and gaining consensus; how to have a meeting that would build that framework.

ask Sarah Novotny to help contribute! [came from maintainers circle]

🔅crowdsource your expertise here

trainings, presentations, talks, workshops on contributor strategy and governance topics are all super valuable to deliver as a service to cncf projects at scale or based on individual need.

let's take an inventory of material that is already floating around that we can assess and deliver. decide if it needs any modifications, etc.

governance:

contributor growth topics:
not your avg mentoring talk (paris and josh)
growing your contributors: going beyond /help-wanted and /good-first-issue
new contributor talk (carolyn)
new contributor workshops (kubernetes)

First #maintainers-circle planning

Collect all planning information for the September launch of #maintainers-circle as a birds of a feather style initial meeting

Goals:

• get everyone together, introductions, insert some kind of hallway track
  • go into break rooms/smaller discussion rooms for introductions and hallway track
• at least two sessions to accommodate time zones

Agenda:

• set expectations: what's a "circle", things you'll see/hear/do, define safe space
• break out into smaller groups in break rooms ("circles") to do introductions and curated discussion
• announcements/open mic space

Logistics:

• First two weeks of September - TBD
• @jberkus to check to see if we can use a platform that red hat uses, Paris/group to check in with cncf on platforms we could use post KubeCon, fall back option is zoom

Cadence:

• Once a month

Open Ended Questions

• recruit volunteers to help

Create a resources page

our meta resources page with links that we will pull information from for us to do our work

examples:

1. other sites that have oss templates for contributors and governance
2. governance and contributor research links
3. todo group applicable links
4. new contributor best practices, etc
5. past survey data and other applicable things we can get from cncf, gb reps, et al and create an artifact in this repo so we can reference

• https://github.com/cncf/surveys/ (maintainer survey)
• https://github.com/cncf/surveys/tree/master/ambassador/2020/h1

6. link to mega -dev lists page for easy referencing when communicating with other projects

Create community taxonomies

This is more of a discussion but wanted to get it out of my head and into the open.

We’ve all heard and probably even participated in, the discussions and debates around what projects should and shouldn't be in CNCF, if you should adopt certain projects, if a project is really open source, when it's ready for graduation/what does sandbox mean, etc. Open governance is our mission/“way" which is defined by these characteristics and principles:
transparency, participation, multi-org/people governing, etc
https://github.com/cncf/toc/blob/master/PRINCIPLES.md

The problem therein is there are many ways to run, operate, and govern your community within the bounds of open governance. Not all projects need to be Kubernetes, which includes the community overhead. What if we were to classify projects by type to help with comparing similar to similar instead of small maintainer project forever to 50k Kubernetes contributor practices.

@dims brought us the badging idea that we’ve extended a bit here and after reading Nadia’s book on Managing OSS ; this inspired this line of thinking. Nadia breaks down projects into Federations (K8s and nodejs are examples), Toys, Clubs, and Stadiums. Projects can absolutely go through different stages and reach different groupings, kind of like maturation.
"a projects contributor growth is a function of its technical scope, support required, ease of participation, and user adoption" - Nadia Eghbal. These items could be the classification mechanisms.

badges would look like
federation: steering
federation: owners files
project-type: governance-type

another resource for this thinking: https://changelog.com/podcast/408 - 45:00 in

If we were to explore the realm of creating such a classification system, here are some questions that immediately spring to mind:

• Do all CNCF Projects need to be a Federation at graduation? Other acceptable project types?
• Are there any groupings that should not be in CNCF because they don’t meet open governance requirements? Example - do/can Toys meet that bar?
• who wants to help? :)

Publish good first issue guidance

I had originally written guidance for kubernetes on how to curate 'good first issue' and 'help wanted': what criteria should be met before we apply those labels, what information we should put into those issues to make them useful and distinct, etc.

Since then I have some additional guidance that can help maintainers with the task of keeping a set of issues with those tags. I'd like to start with my original contribution to k8s (it's since been copied around a bit in git and has lost authorship) and make it generalized and non-specific to k8s/prow.

https://github.com/kubernetes/community/pull/2226/files?short_path=a04fa8b#diff-a04fa8b575accb1e7d4d2e3b652d2fa5

This should be submitted to the cncf/contribute repository.

Values Template and Supporting Advice

While discussing the values section of the governance template, we realized that there is more information that we would like to encourage projects to learn about, get training on and document, such as how conflicts in the community are resolved, leadership training, etc. It would be helpful to have a values template+guide that prompted maintainers to learn about running an inclusive project, find resources for training or maintainer circle information, and document the projects values.

We still need to consider how to include info like this where it's not required by the TOC but is a strongly encouraged activity.

Piloting Orbit

The Orbit team is interested in learning more from the CNCF and Kubernetes community about how they deal with contributor ladders and metrics, and potentially mapping their model to the k8s contributor model: orbit-love/orbit-model#29

We had some CNCF projects pilot their tool through their respective organizations and it's been found useful to provide insights on new potential contributors/maintainers. We also demo'd the tool recently at k8s contribx to get volunteers:

https://docs.google.com/document/d/1qf-02B7EOrItQgwXFxgqZ5qjW0mtfu5qkYIF1Hl4ZLI/edit

Interested people from Contribex:
Matt Broberg
Kaslin Fields
Jonas Rosland
Jenny Warnke
Paris Pittman
Bob Killen

Use our new logo

We now have a cute logo #120 and we should use it everywhere!

• README
• Website
• Mailing list

Contributor Growth WG Content Tracking

Templates

Some of these files have specific casing as required/recommended by GitHub. Most/all of our templates should be saved to the project-templates repository after it is ready.

• LICENSE
• README.md @scotty-c
• CONTRIBUTING.md @carolynvs
• CODE_OF_CONDUCT.md @carolynvs (default to cncf one) - cncf/project-template#4
• OWNERS file
• Goverance.md (goverance WG will handle this)
• Contribution_Ladder.md @iennae @karenhchu
• Onboarding Framework @cpretzer and YOUR NAME HERE. Help out! :-)
• Reviewing.md @karenhchu @carolynvs
• CRM Overview and Runbook @CathPag
• Contributor Growth Framework @CathPag
• Issue Templates
  • Bug
  • Question
  • Documentation Request
  • Proposal / Enhancement / Feature Request
  • Chat in Slack/Forum/Mailing List (It doesn't open an issue, it redirects to a better forum)
• Pull Request Template
• Release process

More brainstorming to come at our next Contrib Growth WG Session on Tuesday

Advisories

• Labeling issues / "Good first issue" and "Help wanted" #61
• Series perhaps on mentoring or fostering people through the contributor ladder
• Pull Request Lifecycle
• Defining the community values, beyond a code of conduct. How to foster those values and deal with people who are participating according the strict letter of the CoC but are not following the values of the community, or are harming the community. -> redirect initial conversations to the maintainers circle?

template/guidance graduation review umbrella comment issue

collecting comments and lgtm's for our first docs that need graduation reviews so other projects can start using them. much of this has already been PR'ed into the cncf/project-template repo, hence the need for an umbrella GitHub after-the-fact issue. this is in response to the email sent to the contributor strategy mailing list. Copy the following list below in your review comment and indicate - lgtm (looks good to me), no opinion/comment, [insert your comments/change requests] - for each.

Graduation Reviews: (last call)

• https://github.com/cncf/project-template- everything in there now
  reviews:
  • CONTRIBUTING.md
  • GOVERNANCE-elections.md
  • GOVERNANCE-maintainer.md
  • GOVERNANCE-subprojects.md
  • GOVERNANCE.md
    ------ (in another repo)
  • contributor-ladder.md

Governance Advisory Documents:

• Leadership Selection
• What Is Governance

targeting end of week Jan 8/9 for final community review and next steps with Saad and Matt.

Launch Governance Subproject

Project Dilligence is one of the three goals of the SIG. This includes:

• Project Governance
• Contributor workflows
• Project Health
• Acceptance and Graduation Requirements

One of our first tasks will be Project Governance. Among the goals for this are:

• Draft general principles of good project governance
• Advise TOC on governance requirements for new projects
• Advise TOC on governance requirements for graduation
• Draft recommendations and process advice for building open governance
• Review project governance structure and documents and provide direct feedback

In order to do this, we need to:

• Collect volunteers for the committee
• Create GH stuff for the committee (directory, group, perms, labels, etc.)
• Decide on coordination (meetings? how often? slack channel or mailing list?)
• Set actual deliverables and initial contributors

Building a Great Project Guide

Projects at any level can always improve. Either they are looking for new contributors, want to foster an inclusive community, improve their docs, add a more structured governance, etc.

Let's make a guide on the website that lays out some stages of great things to do for a project. Point out things to do from the beginning, other things to add later when the project reaches more mature levels.

This should point people to documents in the TOC, our project templates, past talks from kubecon, and maybe new pages that discuss specifically how to a certain task like "get more contributors".

Describe pull request workflow

Describe the required PR Workflow, including approvers etc.

contribute.cncf.io design changes to align with new CNCF brand

At CNCF we've recently published some brand guidelines that distill the key design elements from cncf.io. As you probably have seen, we have a number of sites on subdomains (community, jobs, radar, etc.), in addition to this contribute site, that vary greatly in their design. We've written these brand guidelines in an effort to create brand recognition and establish a more consistent user experience among all CNCF sites.

I'm not aware of the full history of this contribute site and all the people involved but can I talk with someone about getting it to align with these brand guidelines? We are happy to do the work necessary but just want to make sure we hear out all concerns, perspectives, and get buy-in.

Create a contributing template

• Define a scope and goals for what should be included in a template contributing.md
• Evaluate examples of good contributing guides in the wild with the working group
• Create a template that meets our scope and goals

Carolyn will kick off a document shortly to get us started

charter changes

• delete the roadmap section since we are out of the bootstrapping stages (and other bootstrapping related info)
• add a better roadmap that articulates where we are going at a high level
• Gerred chair info / mention that we do toc voting for chairs

Committer vs Maintainer

Goals for this issue:

• list where we see the use of committer and maintainer; try and identify intent
• decide if one should be used over the other or in certain applications
• spark ideas around a role definition bank or FAQ or the like

Possible solution:

• Go with the definitions in the #Resources list; opt for maintainer in most cases as its more inclusive to all “trusted” committers and not just the only code committer misconception. It would also match with projects submitting MAINTAINERS.md to requirements and projects can still define committer as part of their contributor roles.

Why we need clarity:

• committer/maintainer company diversity requirement crafting #29
• Using the right term and building the right programs for contributor growth like role building, contributor ladders, etc
• give guidance to projects on which one to use and why

Uses:

• committer: incubation and graduation requirements and expectations list committer process and other items
  • https://github.com/cncf/toc/tree/master/process#ii-stages---definitions--expectations
  • https://github.com/cncf/toc/blob/master/process/graduation_criteria.adoc#incubating-stage
• maintainer:
  • cncf uses this for toc election voting,
  • toc maintainer seat
  • maintainer surveys,
  • service desk access,
  • (and more.)
  • There is a public list. [link]
  • Many of the projects have MAINTAINERS.md files and others have OWNERS.
  • pull request proposal process for projects -> proposals/pull_request_template.md mentions making a maintainers list and more

Resources:

• https://opensource.guide/leadership-and-governance/
  Lists contributor, committer, and maintainer as similar yet different words with maintainer being a more inclusive committer as someone with high trust and doesn’t submit code/feature work/etc.
• #1 - lists discussion around the terms for the creation of the maintainers circle

Notes:

• to throw another wrench, Kubernetes doesn’t use either term. Approver and sub project owner would be the closest.
• contributor is a close word but seems to have general consensus on usage and definition
• some people say they are interchangeable. Discuss.

Provide examples of how to recognise first-time or significant contributions to projects

As a successful 🎉 first-time contributor to a project, it's really good feels to get recognition for that contribution.

There are some examples out there of how this is done, either via release notes, blogs or contributors.md

We should collect some of these examples and encourage projects to think how they sustain and promote ongoing collaboration

Consistent election procedures and tools

Not sure this is the right place for it but figured I would file it. Kubernetes uses the CIVS service to conduct elections. This is tied to email addresses (which we manually have to reconcile with github) and is generally not an ideal way to run an election.

We've been bouncing the idea of a git-focused election for a while. That is a small webapp (elections.cncf.io/$projectname) and then log in with a github account. The app then checks for your appropriate membership in github groups, and then presents you with a ballot where you arrange the candidates in your order of preference and then submit.

This is something that I think lots of projects in the cloud native landscape could reuse, and many projects do use CIVS for voting (Debian has been using it for years), so I was thinking maybe it's time someone made a modern replacement that can be used without using email (which leads to lost ballots, bounces, etc.)

punch list for contributors.cncf.io site

combo'ing multiple issues and giving some priority / map out an MVP. this is a draft issue.

preview site: https://website--cncf-contributor-strategy.netlify.app/

issues: #47, cncf/contribute#38, cncf/toc#547

• Update docsy theme so that our "edit this page" links work with having content in multiple repositories
• Document how to edit the website (either our content or contributors)
• Linked definition of maintainer, contributor + add "I'm aspiring to be or am a contributor" "I'm aspiring to be or am a maintainer"
• Merge changes to cncf/contribute from Carolyn's fork
• Once the site goes live configure google search
• Guidance documents around building good projects / bubble up cncf/project-templates repo #133
• Detail and assistance documents around meeting CNCF requirements for graduation levels #134
• Maintainer circle page
• Information on accessing CNCF services for projects / link to the cncf services page #135
• highlight projects with contributor needs (looking for new contributors in a certain area, etc) - this can help end users with the ambiguous questions of where to contribute at scale / maybe automate this somehow #136
• bubble up cncf/contribute repo
• bubble up the maintainers list #137
• link to cncf community calendar / calendar with just contributor and maintainer applicable events / highlight project meet our contributors, governance meetings, etc #138
• contributor stories and/or profile highlights here / include link to cncf community spotlight #139
• community terminology and explanations #140
• in memoriam page #141
• highlight the ways to contact folks / keep in touch not only with the SIG but each other aka mention [email protected] list, #maintainers-circle (grouped into #135)
• pictures! #142

[idea] Create cncf/community repo

In the Kubernetes project, we have the https://github.com/kubernetes/community, which serves as one of the primary ingresses points for contributors.

It would be cool to have something analogous within the CNCF GitHub org.
I currently see https://github.com/cncf/contribute, which is close and could potentially be renamed/used for this purpose.

cc: @parispittman @jberkus @gerred @amye @idvoretskyi
ref: #3

Define end-user for promotion criteria.

In cncf/toc#438, @resouer points out:

We have a MUST criteria of "3 independent end users" for incubation level project: https://github.com/cncf/toc/blob/master/process/graduation_criteria.adoc#incubating-stage.

The definition of "End Users", according to CNCF End User Community, is: companies
that use cloud native technologies internally, but do not sell any cloud native services externally.

So the first issue is we don't have a clear definition of "End Users" in the graduation criteria doc.

The second issue is, there are many projects whose adopters are mostly vendors instead of "End Users" based on the definition above.

Most examples are spec projects, e.g. CloudEvents which is already a CNCF incubation level project. Another example is Cloud Native Buildpackwhich is currently under review in SIG App Delivery.

This seems like an issue for ContribStrat, so I'm opening it here.

So I would like to bring the discussion to TOC and wider community to revisit this criteria and discuss how we honor it during daily review practice.