Editor’s note: We adapted this content from HDFS's Critera for Committership Document
Maintainers are responsible for the growth and forward projection of the project. They review and merge code changes, complete roadmap planning, help cultivate and maintain a healthy community, and more. There are many meaningful ways to contribute to Skooner, which can lead to becoming a maintainer.
Here are few criteria that current maintainers look for from potential new maintainers: A history of sustained contribution to the project. This is a way for a contributor to demonstrate their expertise in an area, and thus their ability to help review and commit contributions by others in that same area. Sustained contribution also demonstrates commitment to the project by showing that an individual will continue contributing even after they become a committer. High-quality contributions. As experienced contributors, committers set an example for others in the project, and help inculcate a culture of high-quality contributions. For code contributions, this means clean code that is generally bug free and passes precommit checks. For reviews, this means thorough and actionable feedback, and a +1 vote (even non-binding) only when there is a high degree of confidence in the change. Community involvement. Contributors are always expected to be polite, constructive, and respectful of others during community interactions. Disagreement can (and will) happen over technical issues, but the discussion should remain friendly and focused on technical merits. Committers have the additional responsibility of mentoring newer contributors, as well as helping to grow the community through actions like responding to questions on Slack.
Here are few criteria that current maintainers look for from potential new maintainers:
- A history of sustained contribution to the project. This is a way for a contributor to demonstrate their expertise in an area, and thus their ability to help review and commit contributions by others in that same area. Sustained contribution also demonstrates commitment to the project by showing that an individual will continue contributing even after they become a committer.
- High-quality contributions. As experienced contributors, committers set an example for others in the project, and help inculcate a culture of high-quality contributions. For code contributions, this means clean code that is generally bug free and passes precommit checks. For reviews, this means thorough and actionable feedback, and a +1 vote (even non-binding) only when there is a high degree of confidence in the change.
- Community involvement. Contributors are always expected to be polite, constructive, and respectful of others during community interactions. Disagreement can (and will) happen over technical issues, but the discussion should remain friendly and focused on technical merits. Committers have the additional responsibility of mentoring newer contributors, as well as helping to grow the community through actions like responding to questions on Slack.
There are multiple paths to becoming an maintainer. Here are a few hypothetical example paths:
- Kamala works at a large company that has many different Kubernetes clusters. While integrating and installing Skooner, she realizes that there are a number of issues and holes in the documentation. She opens new issues for each bug. She’s able to fix some of the bugs, but leans on the community to help patch the other issues, while doing extensive debugging/refactoring to see what works. Kamala then works with Nancy, the release manager, to make sure that these changes are incorporated into the next monthly versioned release.
- Bill works at a small- to medium-sized company that has Skooner deployed. He also is a web developer. Bill finds accessibility issues on the website. He files the issues and submits patches. Bill then joins the community calls and Slack channel to chat about website improvements, from internal search to mapping. Through these calls and messages, he then starts to assign different tasks based on the skills of other contributors. He wants to get the ball rolling on a full scale overhaul of the website. Bill creates his own fork to collaborate on. Bill continues to project manage the website overhaul, reviewing and merging code from other contributors into his fork. Once the project is “complete,” he submits his fork to merge into main. At this point Bill is invited to become a maintainer. Once Bill is a maintainer, he continues to push website improvements, while cultivating community and coaching newer contributors.
- Sue is a technical writer interested in Kubernetes and Skooner. She has an in-depth knowledge of Skooner but notices there are holes and errors in the documentation. Sue starts with fixing outdated information from previous versions and updates incorrect examples by finding and reaching out to the subject matter experts/maintainers. She is able to update and add to the documentation and comes to have a deep understanding of Skooner. Sue is then knowledgeable enough to start answering questions that come through the Slack channel and mailing list, doing this autonomously and without additional guidance. This demonstrates her deep knowledge of the project, attention to detail, independence, and focus on community. At this point Sue is invited to become a maintainer.
- Samson is a developer advocate at his company. He is focused on connecting users to the correct projects. Samson is able to organize (virtual) events, is immersed in the larger open source community, is a connector. In short, Samson cultivates community. He takes the initiative to join the monthly open community calls and Slack channels. Samson works with subject matter experts and current maintainers to understand what kind of events they want to become involved in and speak at. He then creates an event playbook that outlines how to get involved with those targeted communities and how a representative from Skooner can host an event. Samson also collaborates with Marie, a maintainer and the lead designer for the project, to create slide templates - complete with a standard set of talking points. At this point Samson is invited to become a maintainer. However, his work doesn’t stop there. In addition to the events he oversees, he also has an ongoing collaboration with Sue to create blog articles to evangelize Skooner’s new features.
- Marie is a designer. She is also passionate about open source. She finds Skooner during Hacktoberfest when she sees an open issue for a new logo. Marie talks to the current maintainers, sends out a survey on Slack. She incorporates feedback and creates three iterations of a logo. Marie presents it to the community and perfects the logo that the community chooses. Once she submits the logo, she notices that the project doesn’t have a design guide or color palette. Marie carves out time in the next open community call to discuss these items. After she gets feedback on both items, Marie creates and submits both the color palette and design guide. She also makes it known that she wants to be the lead designer for Skooner, providing a list of assets that need to be created that she believes will help make Skooner more recognizable. Marie then starts to recruit other designers to help create assets. She manages and triages tickets and has a steady flow of iterations from contributors being submitted. At this point she is invited to become a maintainer.
Examples of some of the duties we’d like maintainers to take on include, but are not limited to:
- review code
- give talks
- write blogs
- merge PRs
- provide release support/release management
- propose new features/be involved in roadmap planning
- attend open community calls
- answer questions in Slack
While we won't ask a maintainer to do all of the above, we do hope that they will take on multiple duties.
This is how we will recognize you within the community:
- Page on website that lists committers/maintainers/release managers
- add to README.md