One of the focuses for maintainers is to build welcoming communities. There are already best practices for maintainers so lets learn from others and see what works for us!
No the maintainers are not expected to produce code. The main goal is to serve and welcome the community by directing to someone who can help or helping them yourself. Here are some ideas the maintainer can provide value:
- coding as needed to lead by example, work towards the project goals, fill the gap
- documenting to make the lower the learning curve for new contributors
- triaging issues to help contributors more easily find work
- review PRs to mentor contributors as well as set a quality standard
- responding to comments in a timely manner to keep the community alive
- welcoming others to contribute which may include the ideas above
The maintainers can decide who is responsible for backlog grooming. Each project may look different. Maintainers and even contributors can help with the backlog grooming. If we want the project to be welcoming, there should be issues or items with enough requirements to making the contributors want to contribute and provide value.
I have no expectations at the moment. The goal is to serve the contributors in any way that is reasonable with your available time or possibly share the load and collaborate with the other maintainers.
I'm torn. I love in person design sessions. However, I would like to keep the concept of open source with a distributed first approach and everything is transparent to the community. I think as long as we document or summarize, we should be okay. This is something, we may just find out from experience on what works.
You don't need to as I the way I think about open source. When I was jumping on a project with unfamiliar tech stack, the maintainers help me get going, teach me, or provided resources. However, I can see Tech Friday topics based on the needs of the contributors to where other Improvers can get value as well.
Are we expected to facilitate just the development of the raw skill, or should we be aiming also at refining their technique (best practices)?
It depends on the maintainers and what practices and standards y'all want to put in place for the project.
Github. Depending on the need, Slack may be used but be very mindful on the type of conversation. Is the conversation something that someone else might want to know? Then having that conversation on an issue in github is preferred as it is documented there.
Absolutely. Maintainers is a shared commitment. We do our best to respect each others' availability and help each other out as we can. My gut criteria when starting this initiative was to have at least three maintainers so that there isn't a burden on any one individual. We have seven, which is amazing.
As a guess how many hours a week do you expect the maintainers to contribute (on an individual basis) to cover the expected need?
No idea. This is an experiment. The expected 48 hour response time is something I notice others put a rule out to respect the contributors. My goal is to develop a welcoming community so not sure how much time that takes. We have a team of seven so I hope a couple of hours is sufficient. Total guess.
How many contributors are we planning to cover, or are we expecting to be fixed in the number? (Or can every and any one participate?)
Anyone can participate. However, I can see us strategically emailing or reaching out when we can handle more contributors. Don't forget that contributors can be very valuable in helping out on the project with any of the maintainer's responsibilities. It is a matter of teaching, welcoming, and trust. This experiment is only in Houston. However, if someone else from another enterprise joins in, we should always be welcoming.
The maintainers of the project can decide.