but I was wondering if it's a useful metric to have a minimum number of people with commit access. Maybe just one great developer would be enough for a small project, but what if they decide to stop contributing? Do you think it's important to have redundancy in commit access? Yes, absolutely. I think it's really important to have redundancy in commit access. It's definitely not a good situation if you only have one person who has commit access and they disappear. So, having at least a couple of people who can review and merge code is really important for the long-term sustainability of a project. And it's also good for spreading out the workload and reducing the risk of one person becoming a bottleneck for all the contributions. So, I definitely recommend having redundancy in commit access, even for small projects. It's just a good practice. Hi, great talk. Thank you for that. Just curious, if it would be useful to have an evolving, governance style, like periodically documenting governance and evolving that over time, or should we be clear one time and just onboarding instructions? Yeah, I think that's a good question. I think it definitely helps to have an evolving governance style. I think it's hard to get everything right at the start. And as the project grows and evolves, your governance may need to change to reflect that. And it's also good to get feedback from the community and adjust your governance if needed. So, I would say start with something clear and simple and then be willing to adapt and improve on it over time. And that also helps to involve the community in the process and make them feel included in the decision-making. So, I definitely recommend having an evolving governance style. Hi, I have a question about governance. How can you ensure the long-term sustainability of a project if maintainers are usually hired and leave a particular project after some time? Yeah, that's a really good question. It can be challenging when maintainers are hired and leave the project. I think one thing that can help with this is having clear documentation and processes in place. So, if maintainers leave, there is a clear path for new maintainers to step in and take over their responsibilities. And this is where having a contributor ladder or some kind of leadership path can be really helpful. It can also help to have more than one maintainer for different parts of the project, so that if one maintainer leaves, there is someone else who can step in and take over. And of course, it's always good to have documentation and knowledge sharing among maintainers, so that there is a smooth transition when someone new takes over. But it can be a challenge, and it's definitely something that needs to be considered for the long-term sustainability of a project. Hi, thank you for your talk. So, I had a question about motivation. You said that clear communication and reducing friction are key to motivate contributors. What are some practical steps we can take to achieve that and make contributors feel welcome and included? Yeah, that's a great question. So, I think the first step is to have a clear and welcoming community guideline or code of conduct that sets expectations for behavior in your project. This can help create a safe and inclusive environment for everyone. Additionally, having well-maintained documentation, clear onboarding guides, and good communication channels can all help reduce friction for contributors and make it easier for them to get involved. It's also important to have regular communication with contributors, to acknowledge and appreciate their contributions, and to provide feedback and guidance when needed. And finally, creating opportunities for contributors to get involved in decision-making and leadership positions can also help them feel valued and motivated to continue contributing. So, those are just a few practical steps that you can take to create a welcoming and inclusive environment for your contributors. Hi, thank you for your talk. I have a question about maintaining contributors' interests over the long term. How can we ensure that contributors remain engaged and motivated to continue contributing to a project? Yeah, that's a great question. Engaging and maintaining contributors' interests over the long term is definitely a challenge. One thing you can do is provide clear goals and milestones for your project. This can help give contributors a sense of purpose and progress. Regular communication and updates about the project's roadmap and future plans can also help keep contributors engaged and excited about the project. Providing opportunities for professional growth and learning, such as mentoring and leadership programs, can also help maintain interest and motivation. And of course, acknowledging and appreciating contributors' work and contributions is really important. Recognizing their efforts and publicly thanking them can go a long way in keeping them engaged and motivated to continue contributing. Hi, great talk. Thank you for that. I have a question about mentoring. How can we encourage maintainers to become mentors, especially if they are already overworked and busy? Yeah, that's a great question. Mentoring can be a time-consuming task, and it can be challenging to encourage maintainers to take on that role, especially if they are already overworked. One approach is to communicate the benefits of mentoring, not just for the person being mentored, but also for the project as a whole. Mentoring can help distribute the workload and reduce bottlenecks, and it can also help groom future leaders for the project. Additionally, you can provide resources and support for mentors, such as training materials, guidelines, and templates, as well as regular check-ins and feedback sessions to ensure that they have the necessary support to be successful mentors. It can also be helpful to recognize and appreciate mentors' efforts and publicly acknowledge their contributions, which can help create a culture of mentoring within the project. So, those are a few strategies for encouraging maintainers to become mentors. Hi, thank you for your talk. I have a question about metrics. What are some key metrics or indicators that we can use to measure the sustainability and health of an open source project? Yeah, that's a great question. So, there are several metrics that you can use to measure the sustainability and health of an open source project. One key metric is the number of active contributors. This can give you an indication of community engagement and the overall health of the project. You can also look at the number of regular contributors, those who contribute consistently over time, as well as the number of core contributors, those who make significant contributions and take on leadership roles within the project. Another important metric is the bus factor or the lottery factor, which measures the number of people who are critical to the project's success. Without enough contributors who can maintain and develop the project, the bus factor can be high, indicating a potential sustainability issue. Responsiveness is another important metric to consider. This measures the project's ability to review and merge contributions in a timely manner. A high backlog of pull requests or a slow response time can indicate the need for more contributors or better resource allocation. Documentation is also an important aspect to consider. You can measure the quality and comprehensiveness of your project's documentation, as well as the time it takes for new contributors to get up to speed. Finally, it can be useful to measure the diversity and inclusivity of your contributor community. This can include factors such as gender, ethnicity, and geographical diversity, as well as the adoption of inclusive practices and policies. So those are just a few key metrics that you can use to measure the sustainability and health of an open source project. Hi, excellent talk. I have a question about contributor ladders. How should we define the roles and responsibilities for contributors, reviewers, and maintainers? And how do we decide which privileges should come with each role? Yeah, that's a great question. So defining the roles and responsibilities for contributors, reviewers, and maintainers can be done with input from the existing community members. You can start by looking at the work that each role currently involves and document that as the responsibilities for that role. So for example, what are the tasks and activities that contributors, reviewers, and maintainers typically perform? Once you have defined the responsibilities, you can consider the qualifications and requirements for each role. What skills and knowledge are needed to fulfill those responsibilities? And what criteria should be met to move from one role to the next? As for privileges, those should align with the responsibilities of each role. For example, contributors may have the privilege to submit pull requests and participate in discussions, while reviewers may have the privilege to approve or request changes to pull requests, and maintainers may have the privilege to merge code and make decisions about the project's direction. The specific privileges can be defined based on the needs and requirements of your project. And it can be helpful to have a feedback and review process in place to ensure that the roles and responsibilities, as well as the associated privileges, are fair and well-defined. So those are a few steps that you can take to define the roles, responsibilities, and privileges for contributors, reviewers, and maintainers. Hi, great talk. I have a question about maintaining an inclusive community. What are some best practices or strategies to ensure that a project is welcoming and inclusive to contributors from diverse backgrounds? Yeah, that's a great question. Ensuring that a project is welcoming and inclusive to contributors from diverse backgrounds requires an intentional effort. One important step is to have a clear code of conduct or community guidelines that sets expectations for behavior and ensures a safe and inclusive environment for everyone. Additionally, it can be helpful to provide resources and trainings on diversity and inclusion topics to educate community members and raise awareness about unconscious bias and other barriers that can prevent a welcoming environment. It's also important to actively reach out to and encourage contributions from underrepresented groups. This can include participating in outreach programs and events targeted at diverse communities, as well as providing mentorship and sponsorship opportunities specifically for individuals from marginalized populations. Another strategy is to create affinity groups or subcommittees within your project that focus on diversity and inclusion. This can provide a platform for individuals from diverse backgrounds to share their experiences and perspectives, and help inform the project's policies and practices. Finally, listening to and incorporating feedback from community members is crucial. Regularly seeking feedback and input on inclusivity and making changes based on that feedback can help create a more welcoming and inclusive community. So those are just a few best practices and strategies to ensure that a project is welcoming and inclusive to contributors from diverse backgrounds. Hi, thank you for your talk. I have a question about contributor growth strategies. What are some strategies or techniques that project maintainers can use to encourage more people to contribute to their projects? Yeah, that's a great question. So there are several strategies that project maintainers can use to encourage more people to contribute to their projects. One strategy is to have good first issues or help-wanted labels on your project's issue tracker. These labels can help new contributors find tasks that they can work on, and provide a low-barrier entry point to get involved. Another strategy is to be proactive in asking for help. You can reach out to individuals with specific requests, such as reviewing a pull request or answering a question in a forum. This shows that you value their expertise and are specifically asking for their help. Providing clear onboarding documentation is also important. This helps new contributors get started quickly and understand the expectations for contributing to the project. Additionally, acknowledging and appreciating contributors' work is really important. Recognizing their efforts publicly and thanking them can go a long way in encouraging them to continue contributing. And finally, it's important to foster a sense of community and belonging within the project. Creating opportunities for contributors to connect with each other, such as through meetups or virtual events, can help build relationships and make contributors feel more connected and engaged. So those are just a few strategies and techniques that project maintainers can use to encourage more people to contribute to their projects. Hi, thank you for your talk. I have a question about contributor burnout. How can we prevent contributor burnout and create a sustainable community for our open source project? Yeah, that's a great question. Preventing contributor burnout is really important for creating a sustainable community. One strategy is to distribute the workload and make sure that there are enough contributors to share the responsibilities. This can be done by encouraging and grooming new contributors to take on more responsibility over time. Having a clear contributor ladder with defined roles and responsibilities can help with this. Setting realistic expectations for contributors and maintaining a healthy work-life balance is also important. Encouraging contributors to take breaks when needed and supporting their well-being can help prevent burnout. Additionally, acknowledging and appreciating contributors' work and publicly thanking them can go a long way in making them feel valued and motivated to continue contributing. It's also important to have a feedback and review process in place to ensure that contributors' voices are heard and their contributions are recognized. Finally, creating a positive and inclusive community where everyone feels welcome and included can help prevent burnout and create a sustainable environment for your open source project. So those are just a few strategies to prevent contributor burnout and create a sustainable community for your project.

Okay, so that was our last question. Thank you all for your attendance and your great questions. If you have any other questions, feel free to reach out to me and enjoy the rest of the conference. Thank you.