Merge branch 'main' into fix-builds

Signed-off-by: Bryan Behrenshausen <bryan.behrenshausen@sas.com>

Author: semioticrobotic

attracting-users/building-diverse-open-source-communities-by-making-them-includive-first.md

@@ -144,9 +144,9 @@ Rather than keeping Redis's prior BDFL style, Gottlieb and Agra built a new, lig
 
 Regardless of your own project's governance model, you must include a way to train key contributors to assume leadership roles. This achieves three key goals:
 
-1.  Helping new contributors learn how they can grow
-2.  Rewarding contributors who own key aspects of the project
-3.  Preventing maintainer burnout
+1. Helping new contributors learn how they can grow
+2. Rewarding contributors who own key aspects of the project
+3. Preventing maintainer burnout
 
 This last point is noteworthy: Sanfilippo said when he stepped down from Redis that despite his passion for coding, he never aspired to maintain a project. Without new leaders to step up—and documentation sharing how contributors can assume such roles—maintainers risk either working on projects when they no longer want to or having the project stall. Likewise, the project risks missing an opportunity to give interested contributors a chance to step up.
 

attracting-users/index.md

@@ -0,0 +1,10 @@
+# Attracting Users
+
+```{toctree}
+:maxdepth: 1
+
+README
+communication-norms-in-open-source-software-projects
+building-diverse-open-source-communities-by-making-them-includive-first
+```
+

getting-started/building-a-strategy.md

@@ -174,9 +174,9 @@ Hopefully, your investments in an open source software community will lead that
 
 Some of these key metrics might include:
 
-- The number of bugs fixed and the number of changes accepted over a specific time period (it's not bad for a project to have a lot of bug reports. every project has bugs, so a steady stream of bug reports shows that people are using the product—but the bugs should get fixed!)
-- Numbers of project downloads (many people download a product to try it out and then discard it, so use other measures if possible to gauge the real growth of the user base—for instance, the number of people participating on forums and the number of questions asked)
-- Your community's mix of contributor experience (have the right mix of project members, some who have been on the project for a long time and can provide institutional memory, along with more recent recruits who provide new energy)
+* The number of bugs fixed and the number of changes accepted over a specific time period (it's not bad for a project to have a lot of bug reports. every project has bugs, so a steady stream of bug reports shows that people are using the product—but the bugs should get fixed!)
+* Numbers of project downloads (many people download a product to try it out and then discard it, so use other measures if possible to gauge the real growth of the user base—for instance, the number of people participating on forums and the number of questions asked)
+* Your community's mix of contributor experience (have the right mix of project members, some who have been on the project for a long time and can provide institutional memory, along with more recent recruits who provide new energy)
 
 ## Conclusion
 This chapter offered an overview of essential considerations one should make when determining whether to start an open source software community and deciding how best to architect that community.

getting-started/essentials-of-building-a-community.md

@@ -0,0 +1,12 @@
+# Getting Started
+
+```{toctree}
+:maxdepth: 1
+
+README
+community-101
+essentials-of-building-a-community
+building-a-strategy
+new-project-checklist
+```
+

getting-started/index.md

@@ -77,23 +77,23 @@ Your project will have any number of contributor pathways specific to it, but th
 
 *Community-focused* pathways are opportunities for contribution that may not require specialized technical knowledge on the part of participants. These are pathways focused on helping new contributors document the project, raise awareness of and market the project, plan community meetings and events, etc.—all extraordinarily important aspects of a project's eventual success. Examples include:
 
-1.  Documenting workflow and governance processes
-2.  Onboarding and mentoring new members
-3.  Localizing content into various languages
-4.  Copywriting (for website, newsletters, blogs)
-5.  Managing social media
-6.  Organizing events
+1. Documenting workflow and governance processes
+2. Onboarding and mentoring new members
+3. Localizing content into various languages
+4. Copywriting (for website, newsletters, blogs)
+5. Managing social media
+6. Organizing events
 
 *Technically focused* contributor pathways, on the other hand, are contributions requiring specialized knowledge of software development (often in a particular computing language). These pathways are focused on enchancing or refining the body of software a community maintains. Examples include:
 
-1.  Adding new features and documentation
-2.  Fixing existing bugs and triaging issues
-3.  Refactoring existing work to improve it
-4.  Performing quality assurance
-5.  Improving user interface and user experience
-6.  Release engineering
-7.  Creating and maintaining project roadmap
-8.  Code and user interface localization
+1. Adding new features and documentation
+2. Fixing existing bugs and triaging issues
+3. Refactoring existing work to improve it
+4. Performing quality assurance
+5. Improving user interface and user experience
+6. Release engineering
+7. Creating and maintaining project roadmap
+8. Code and user interface localization
 
 When assessing your project's contributor pathways, ask yourself: Does your project currently offer new (and existing) contributors opportunities to contribute rewardingly to (or even take ownership of) work in each of these areas? If not, one general way to begin expanding your project is by making concerted efforts to formalize, refine, document, and advertise these contributor pathways.
 

growing-contributors/community-manager-self-care.md

@@ -89,11 +89,11 @@ If this matches your projects's version of sustainable, then a mentoring program
 
 Self-sustainability is an important focus for a mentoring program. And don't think anyone goes from "mentoring people" to "a mentoring program" by accident. Here's the argument:
 
-1.  If we can agree that lowering the barriers for entry into a project is key to bringing in new people; and
-2.  If we can agree that people coming into a new project benefit from having one or more people they feel permitted and even encouraged to ask questions and learn from; and
-3.  If we can agree new people having lackluster or negative interactions with existing project members is likely to drive the new people away; and
-4.  If we can agree that having a person (mentor, friend) for new people to turn to is a way to prevent the driving-away and especially prevent *silent segfaults* (people just disappearing with no explanation);
-5.  Then we can see that doing mentoring with even a tiny bit of repeatable process support is going to yield better, more satisfying results than an ad-hoc process.
+1. If we can agree that lowering the barriers for entry into a project is key to bringing in new people; and
+2. If we can agree that people coming into a new project benefit from having one or more people they feel permitted and even encouraged to ask questions and learn from; and
+3. If we can agree new people having lackluster or negative interactions with existing project members is likely to drive the new people away; and
+4. If we can agree that having a person (mentor, friend) for new people to turn to is a way to prevent the driving-away and especially prevent *silent segfaults* (people just disappearing with no explanation);
+5. Then we can see that doing mentoring with even a tiny bit of repeatable process support is going to yield better, more satisfying results than an ad-hoc process.
 
 Once you agree that even a lightweight program is better than an ad-hoc process, we're going in the right direction. With this in mind, here are a few absolute must-have elements to include in your mentoring program.
 

growing-contributors/constructing-an-onboarding-experience.md

@@ -0,0 +1,15 @@
+# Growing Contributors
+
+```{toctree}
+:maxdepth: 1
+
+README
+from-users-to-contributors
+what-is-a-contribution
+constructing-an-onboarding-experience
+creating-a-culture-of-mentorship
+project-and-community-governance
+understanding-community-roles
+community-manager-self-care
+```
+

growing-contributors/creating-a-culture-of-mentorship.md

@@ -36,13 +36,13 @@ If no one is working on a document, and the community or project leaders support
 
 At this point, make a formal announcement, such as by creating an issue. A due date is recommended, to provide some pressure to finish the document. Remember that a document needs to be reviewed, which could add several weeks to the project. It is also useful to create milestones, which could include:
 
-1.  Start writing
-2.  Circulate first draft
-3.  End of review period for first draft
-4.  Circulate final draft
-5.  End of review period for final draft
-6.  Submitted for approval
-7.  Approved and published
+1. Start writing
+2. Circulate first draft
+3. End of review period for first draft
+4. Circulate final draft
+5. End of review period for final draft
+6. Submitted for approval
+7. Approved and published
 
 To be accepted into a project, the leadership or advisor group responsible for the project must approve it. These leaders should be liberal in approving documentation projects, because any new document that is relevant to a project will usually prove useful to at least some members.