# Community Strategy for Executable Books
The goal of this document is to describe the major strategic and structural areas we must develop in order to evolve the small, grant-driven "Executable Books Project" into a sustainable "Executable Books Organization". It will be intentionally vague about some things, because these should be decided after discussion and iteration with the team. It is an evolution of the original ideas described in [the Executable Books meta documentation](https://executablebooks.org).
For the last ~1.5 years, the Executable Books Project (EBP) has operated as a team of collaborators funded off of a single grant led by John S. (@jstac), with co-PIs Chris H. (@choldgraf) and Greg C.(@gregcaporaso). This has resulted in development across several repositories in the [`executablebooks/`](https://github.com/executablebooks) GitHub organization. We have followed informal practices as a small and independent team.
We are entering the final year of the grant, and assume we won't have the same dedicated funding in the future. We must decide how we'd like this project to evolve, and what steps it will take to get there. If we wish for the project to sustain and grow its impact, we must develop a strategy for ensuring the sustainability of the project after this initial grant-funded period.
Our goal is to formalize these ideas in order to avoid [the Tyranny of Structurelessness](https://www.jofreeman.com/joreen/tyranny.htm), and create a playing field where new stakeholders and contributors can join our projects, contribute, and become co-leaders.
This document is structured around these major strategic areas of organization / community:
- define the mission and values of the organization
- define our governance and decision-making process
- define our code of conduct and mechanisms for its enforcement
- define some community practices
- describe our organizational designation
Together, these major areas describe the transformation of the Executable Books Project into the Executable Books Community (referred-to below as Executable Books, or EB).
## Mission and values of the community
The mission of Executable Books is to foster an open community and an ecosystem of open source tools that facilitate authoring, communicating, and sharing open computational narratives.
The community has these core values:
**Sharing power with many stakeholders**: EB values the perspectives of many stakeholders, and is not beholden to any single one. It is governed by individuals rather than organizations, makes efforts to share power and responsibility between individuals, and recognizes that working as a team leads to healthier communities and better tools.
**Inclusion and diversity**: EB values a broad and diverse community of multiple perspectives. It commits to building an inclusive culture of positivity, creativity, and collaboration where all feel included and welcome to participate. It recognizes that some people are less-comfortable contributing to open communities like this, and commits to supporting them and creating welcoming and safe atmospheres for their participation.
**Delightful user experiences**: EB values tools that are enjoyable to use, and that are reliable and stable for the usecases that we support. This requires having a strong focus on the end-user's perspective and needs, as well as ensuring that our codebase is high-quality and adheres to best-practices to ensure the maintainability and stability of our tools.
**Modularity and composability**: EB values tools that work well on their own or as a part of a broader whole. We wish to provide extension points, API's, and levels of abstraction that allow our tools to be re-used and combined in novel ways.
**Interoperability and standards**: EB values tools that can be used broadly across many communities. It builds upon pre-existing tools, and commits to contributing improvements upstream, when possible. It particularly values interoperability with the `jupyter` ecosystem of tools and standards.
This mission and these values are the north star of the Executable Books community, and define work that we do and the commitments we make in how we do this work. We recognize that some values may occasionally be in tension with one another, but we nonetheless commit to honoring them all in our work.
We must define the mechanisms we use to make decisions, and make (some) power structures explicit. Governance must balance between efficient decision-making and inclusive and participatory processes that balance many perspectives.
We must answer the questions "who decides?" and "how do they decide?". At a minimum we must define a **community-level governing body** for decisions that affect (and must be followed by) the entire community. This body should then define subsets of the community where it delegates authority.
For the purposes of describing governance, we recognize these groups within the EB community:
- **Steering Committee**: Creates high-level project strategy and policy across all repositories. This group has the final say on matters.
- **Maintainers**: Have merge rights on one or more repositories, spend time stewarding projects, teaching others, and growing contributors into maintainers.
- **Contributors**: People who have contributed anything of value to the project, including code, documentation, being helpful in discussions, reporting bugs, sharing content they create, etc.
### Principles of governance
Here are a few principles of governance that influence the processes that we follow:
**Decisions should reflect the community's wishes**. EB is a community of peers, and this must flow into our decision-making. Decisions that affect the community should be made with input and consent from the community. Even when individuals have explicit authority, they should prioritize getting discussion and feedback from other stakeholders in the community, and use consensus-seeking to get buy-in from others (see below).
**Practice servant leadership**. EB maintainers are stewards of the community's mission and values. Authority and power should be wielded with humility and a commitment to the community, not as a means of furthering individual agendas and preferences. Power should be shared throughout the community over time, not concentrated and held onto for long periods of time.
**Seek consensus, ask for consent**. We strive to arrive at [consensus](https://thedecider.app/consensus-decision-making) about decisions, but recognize it may not be possible. If consensus is difficult to reach, we follow [consent-based decision making](https://www.sociocracyforall.org/consent-decision-making/) in order to move forward. If there are major objections before moving forward, address concerns and iterate until these objections are resolved. Ensure that others in the community are aware and invited to participate in these discussions, and create a safe and productive space for discussion.
### Steering Committe
**Expectations and responsibilities**: The Steering Committee is the final say in the EB community. It makes decisions about organization-wide policy, stewards the Code of Conduct, and ensures that the project lives up to its mission and values. It is expected to keep up-to-date with major developments in the community, and to provide direction for major strategic decisions. It acts as a deciding vote if there are major unresolvable objections to a decision.
**How they make decisions**: The group makes decisions through majority vote, with a tie-breaking vote cast by a designated Steering Council lead in the event of a tie.
**How membership changes**: New Steering Committee members are added by a nomination from a Steering Committee member, followed by a >= 2/3 "yes" vote from the Steering Committee. New members should have demonstrated merit through continued service to the community, or be of particular strategic value to the project (as determined by the other Steering Council members). Steering Committee members are encouraged to step down after 2-3 years, to allow new community members to serve in leadership roles. This group should try to remain around 5-8 people in size.
**Bootstrap members**: The initial Steering Committee consists of the Principle Investigators of the Executable Books Project (John S. as lead, and Chris H. and Greg C. as co-Is). It should quickly vote to expand the steering committee to grow to between 5 and 8 people in size.
**Delegation of authority**: The Steering Committee delegates most decision-making to the maintainers of projects and repositories. The next section goes into more detail.
The Steering Committee delegates most day-to-day decisions to the Maintainers in the EB community. For example: decisions about merging, opening/closing issues, etc are the responsibility of the project's maintainers. This group has flexibility to make these decisions as they prefer, so long as they do so within the policies defined by the Steering Committee.
**Expectations and responsibilities**: The maintainers of the project are responsible for carrying out most development efforts, engaging in design discussions and technical decision-making, reviewing one another's work, and in engaging contributors and mentoring them to become maintainers.
**How they make decisions**.
- For minor decisions that do not have major impact in functionality, maintainability, or cross-project implications, they may be made unilaterally.
- For significant changes to a project, discuss with other Maintainers and Contributors to decide the best path forward. While this is a complex process, we agree to make decisions inclusively, and to follow the guidelines described in the section below.
- For major decisions or cross-project decisions, follow an **Enhancement Proposal** process to solicit structured feedback from a wide array of community members and stakeholders. See the sections below for more information.
**Guidelines for decision-making**.
Here are a few guidelines for how EB Maintainers should make decisions.
These aren't strict rules, but best-practices that encourage collaboration and discussion without becoming too slow.
- **Open an issue first**. Before making a Pull Request, open an issue to so that others have context. Invite conversation from others and conduct discussion inclusively so that others can participate.
- **Be collaborative**. Engage with the ideas of others in a constructive fashion. Meet them where they are, and try to build on one another's ideas in a "yes-and" fashion. It is important to remember that Maintainers typically have a better understanding of the software; so ensure to provide context and explanation when providing constructive critical feedback.
- **Seek consensus, ask for consent**. When a decision is being discussed, explicitly state what it is and invite others to respond. Strive to accommodate everyone's ideas in discussion, and seek compromise. If there are unresolveable objections, break logjams with a Steering Council vote (this should happen rarely).
- **Leave PRs open for a few days**. A pull request that resolves an issue should be open for at least two working days for review from other maintainers. It's not forbidden to self-merge PRs, but it's generally not a good idea - instead, ask for reviews from others early and often.
- **Merge after approval**. If any other maintainer approves the change, it may be merged. If any other maintainer objects, iterate until no objections remain or a consensus is reached. Use your best judgment to carry out these processes in an inclusive manner that lets others have a chance to understand and provide feedback.
- **Discussion should scale with impact**. The more impactful the change, the more ideas and voices should go into decision-making. Use your best judgment about whether it's best to wait for more discussion. If it's a _really_ impactful decision, consider opening an enhancement proposal.
**How membership changes**: Maintainers may be added through a proposal from a pre-existing maintainer. This proposal should include a rationale for why the new individual would make a good maintainer of the project, why they have shown an ongoing interest in contributing over time, and why they are a good match for our community's values and mission. This proposal should remain open for 5 working days, for other maintainers to provide feedback and ask questions. If there are no objections at the end of 5 days, then the new maintainer is added.
**Bootstrap members**: The GitHub users that have merge rights to EB repositories are the current maintainers of the project.
Contributors make up the entirety of the Executable Books community. Anyone who has meaningfully participated in an Executable Books space is a contributor (including the Maintainers and Steering Committee). Contributors do not have any explicit responsibilities or authority, but they are a crucial part of the EB community. All Maintainers and Steering Committee members should regularly solicit feedback from the Contributors of the EB community.
### Emeritus maintainers
Healthy communities respect the bandwidth and responsibilities of its members, and encourage one another to step down in graceful fashion if it no longer makes sense to actively contribute to the project. Any EB maintainer may ask for "emeritus" status at any time. This relieves them of any responsibilities for maintaining, developing, or participating in the community. Any emeritus member may be re-instated as a maintainer if they wish to resume these responsibilities.
### Appendix: Inspiration for governance and organizational structure
Below are a few resources that have inspired the ideas in this document.
- [The GitHub Minimal Viable Governance model](https://github.com/github/MVG/blob/main/org-docs/CHARTER.md) describes basic governing principles and groups that should exist in an open source project.
- [The Four Opens](https://openinfra.dev/four-opens/) from the open infrastructure project (and most notably adopted by [the OpenStack community](https://www.openstack.org/four-opens/))
- [The Rust governance](https://www.rust-lang.org/governance) has a lot of useful patterns to follow for RFCs, roadmapping, and inclusive project governance.
- [The Jupyter Project governance](https://jupyter.org/governance/intro.html) has a basic governance structure that was created when Jupyter was around the same size as the EB community. It in the midst of refactoring this governance due to its increased complexity, but we are not there yet.
- The [Executable Books principles and constraints](https://executablebooks.org/en/latest/) were created at the onset of this project, and continue to serve as inspiration for this proposal.
## Code of Conduct
The Code of Conduct is a community's most important mechanism to ensure that community members create an atmosphere that lives up to our values.
Currently our community has informally adopted the [Contributor Covenant](https://github.com/executablebooks/.github/blob/main/CODE_OF_CONDUCT.md) as our Code of Conduct. The Steering Committee should do the following:
1. Conduct a community-wide RFC process to invite comment about the use of this CoC for the EBP community.
1. Decide whether to make changes to this CoC, or to officially adopt it for the community.
1. Create an official reporting process and CoC committee to address CoC reports.
This is a complex process so this proposal does not propose any specific changes or CoC language. However, here are some examples of Codes of Conduct that we may wish to take for inspiration:
- The [Recurse Center Code of Conduct](https://www.recurse.com/code-of-conduct)
- The [Jupyter Code of Conduct](https://jupyter.org/governance/conduct/code_of_conduct.html)
- The [PyLadies Handbook](http://kit.pyladies.com/en/latest/organizer/difficult/responding.html)
- The [example conference anti-harassment policy](http://geekfeminism.wikia.com/wiki/Conference_anti-harassment/Policy) on the Geek Feminism Wiki, created by the Ada Initiative and other volunteers.
- [Projectinclude's guidelines for Codes of Conduct](https://projectinclude.org/writing_cocs).
## Community practices
Community practices are the policies and workflows that we use to interact and coordinate with one another. The specific practices should be defined by the Steering Committee, in consultation with the Maintainers of the project. In this section we define the major principles that should drive our community practices.
### Principles of community practices
**Be welcoming, collaborative, and positive**. The most important quality of any open source community is that it should be enjoyable and positive to contribute for anyone, particularly those who are most vulnerable. We encourage creativity, positivity, open sharing of ideas, collaboration, and dynamism. If people have different opinions, we engage one another as equals and recognize that we're ultimately working together towards the same mission. No community member should ever be made to feel that they are inferior or that they don't belong, provided that they follow our Code of Conduct and act in good faith.
**Practice community stewardship**. EB commits to stewarding its projects as a community, and aims to build processes and structures that share responsibility amongst its members. Any core package that relies on a single person is in a failure mode. Development or maintenance of core packages should not be one person's responsibility unless there is a clear pathway towards passing this responsibility onto others over time.
**Balance best-practices and accessibility**. Contributors come from a range of backgrounds, experiences, and comfort levels. We should adopt community practices that balance Quality Assurance with accessibility to this broad audience. We do so by distinguishing between best-practices (as defined in [the contributing guide](https://github.com/executablebooks/.github/blob/master/CONTRIBUTING.md)) and *required* practices (a subset of our best-practices). We commit to mentorship and training across all best-practices to help boost the skills of new members, and draw hard-lines for contributions only when our _required practices_ are not met.
**Encourage upward mobility**. The goal of our community should be to empower users to become contributors, to mentor contributors to become maintainers, and to encourage maintainers to grow into leadership roles within the project. The most important dynamic in our community should be that those with less experience or power feel comfortable and supported in their upward growth within the project. Those in leadership roles should take care to make space for new ideas and perspectives, and to encourage shared leadership across the community.
### Enhancement proposals
For decisions with major impact across the EB community and its stakeholders, we use an Enhancement Proposal process to solicit structured feedback and encourage discussion.
The goal of enhancement proposals is to ensure that a decision's impact is considered across all of our stakeholders, as well as to ensure that we have considered all of the important questions to ask when deciding whether / how to move forward.
Most Enhancement Proposals will be accepted or rejected via a vote from the Steering Committee, though in some cases this authority may be delegated to a subset of the community (e.g., for a proposal that affects only a single project but would benefit from an Enhancement Proposal process nonetheless).
The Steering Committee should design and approve an enhancement proposal process, in partnership with the EB Maintainers. The specifics of this process are outside the scope of this document, but it will likely be heavily inspired by similar processes in adjacent communities. For example:
- The [Rust RFC process](https://github.com/rust-lang/rfcs) does a nice job of balancing fluidity/movement with deliberative discussion and decision-making.
- The Python community has a well-known [PEP process](https://www.python.org/dev/peps/).
- The PyData ecosystem has a common practice of an "enhancement proposal" process. For example, [NumPy NEPs](https://numpy.org/neps/), [Jupyter JEPs](https://jupyter.org/enhancement-proposals), [Matplotlib MEPs](https://matplotlib.org/stable/devel/MEP/index.html), [Bokeh BEPs](https://github.com/bokeh/bokeh/wiki/BEP-0:-Bokeh-Enhancement-Proposals).
### Balancing aspirations with reality
While we aspire to have multiple people understand, maintain, and develop every package, this is unlikely to happen in practice. The community has limited resources, and we must balance ideal practices in engineering with the reality of whatever resources we have. We must also ensure that the most impactful repositories and decisions are resourced properly.
Here are a few steps we follow to do this:
#### Core vs. non-core packages
We want rigor and deliberation to scale with risk and impact. For this reason, we distinguish between "core" and "non-core" packages.
A package is "core" if it is central to an end-user tool in the EB stack. A major feature or bug in this package would often affect *all* users or parts of the core workflow.
Packages that are "core" to the EBP should have extra resources dedicated to them, to ensure that their bus factor is high and that multiple perspectives flow into their development. Core packages should also use practices that are more deliberate and inclusive, and invite more comment and feedback from our stakeholders.
For projects that are not "core packages" or in the prototype stage, it is OK to relax our practices and prioritize more fluid development cycles. As the package becomes more adopted, we should shift towards more inclusive practices.
The Steering Committee should design and vote on a list of "core projects" that are in the EBP stack. Here is a rough list to start:
#### Best practices vs. required practices
*Best Practices* are a gold-standard for building maintainable, well-structured code. They require discipline and training to get right. We maintain a definition of our best practices in the [CONTRIBUTING.md document](https://github.com/executablebooks/.github/blob/master/CONTRIBUTING.md).
*Required Practices* are of extreme importance to maintaining our code, and are thus required across all core repositories. If these conventions are not followed, it is reasonable to ask for changes before merging a PR. They are defined explicitly in our contributing guide.
#### Mentorship and knowledge transfer
Even if a single person maintains a package, they should spend their time sharing their knowledge and mentoring others so that this burden can be shared (or passed on) over time. Maintainers should write high-quality developer documentation to help others get up to speed. They should also create a plan for their for their succession, and work with other Maintainers to ensure they are not the only ones with knowledge in a particular area. This ensures that the burden of maintaining doesn't fall on one person for too long, and ensures that a particular part of the stack doesn't become over-fit to one person's ideas.
### Appendix: Proposed required practices
This is a proposal for code standards that we use to ensure a consistent experience and level of quality across our projects. The goal of these standards is to strike a balance between common best practices in software engineering, and being accessible to the communities of practice that we expect to become contributors. This is a proposal, and should be iterated on and voted on by the Steering Committee.
- **Testing Infrastructure**. All additions to a codebase should contain tests that cover their functionality, [as described in the Testing section](https://github.com/executablebooks/.github/blob/master/CONTRIBUTING.md#testing).
- **Documentation**. All contributions should come with user-facing documentation to explain functionality and usage, as well as developer-facing documentation to explain how the code relates to the broader codebase. See [the documentation section](https://github.com/executablebooks/.github/blob/master/CONTRIBUTING.md#documentation) for more details.
The rest of the Best Practices in the Contributing Guide are not required. If a required practice is not followed, it is reasonable to require changes or apply changes yourself before merging. Otherwise, unless the PR adds no material value or poses a substantial risk, a maintainer should either merge it as-is or make a final commit to adhere to standards before merging.
## Long-term organizational home
Once the Executable Books _Project_ winds down, there will be no legal structure behind the assets that the project has created (e.g., our repositories or logos). We must consider what kind of organizational structure we wish to have in the Executable Books community.
There are roughly three options to take:
- Create a standalone open source community, and incorporate under a fiscal sponsor like NumFOCUS.
- Incorporate into a pre-existing community, like the Jupyter Project.
- Remain as an unofficial collection of GitHub repositories.
_(in addition, we might take different approaches for different repositories within this organization)_
The Steering Committee must decide which of these options to take, with consultation from the Maintainers of the project. See [a proposal below](https://hackmd.io/5Q4D0eJ7SOGT6Lh_dkiyCw#Incorporation-as-a-Jupyter-sub-project) for discussion.
Some approaches will influence the structures / policy described above. For example, incorporation under a pre-existing community will likely require us to adopt their Code of Conduct and abide by whatever policies they have in place.
### Appendix: Incorporate as a Jupyter sub-project
I think the approach that gives us the best long-term chance at impact is to try to **incorporate Executable Books as a sub-project within Project Jupyter**. Here's a brief reason why this would be valuable to both organizations:
**Benefit to Jupyter:** The Executable Books Organization can steward the focus area of "publishing and authoring use-cases" within the Jupyter Project. It differentiates itself from JupyterLab and JupyterHub as a use-case-driven sub-community. Jupyter Book is the flagship tool that drives development across the stack, but other tools that are focused on authoring/communicating (e.g., Thebe, MyST) live here as well. This can drive innovation for publishing-focused use-cases (e.g., the recent thread around in-line markdown execution, or text-based notebook formats).
Many likely already view this project as a sub-project of Jupyter, given that `jupyter-book` is the most user-facing tool and has `jupyter` in the name + began inside the Jupyter organization, and because the `MyST` name was originally an idea that came out of the core Jupyter team. This may just be bringing reality in-line with assumptions.
**Benefit to Executable Books**: Aligning and integrating with the Jupyter Project will provide an organizational backstop that boosts the mission of the Executable Books community. There is already significant overlap between Jupyter tools and EB tools, and integrating with Jupyter will encourage more connections between EB tools and other parts of the Jupyter stack (e.g., JupyterHub, JupyterLab, and Jupyter Notebooks in general). This also
gives EB a larger platform that it can use to reach more users and gain more credibility. Jupyter may also provide strategic advice at the level of developing a large and participatory community, since it is a large and well-established steward over open standards with a diverse group of contributors.
Finally, the Jupyter Project already has many of the structures and processes proposed above, and we could adopt some of the Jupyter processes and commit to following them rather than creating our own (e.g., the [Jupyter Code of Conduct](https://jupyter.org/governance/conduct/code_of_conduct.html) and the [Jupyter Enhancement Proposal process](https://jupyter.org/enhancement-proposals), as well as a legal home via NumFocus underneath the Jupyter umbrella). In the future, we could rely more on the Jupyter community's structure and contribute to it ourselves. Creating these structures on our own will require a _significant_ amount of time and energy, and this could be a way to join forces to make it more sustainable for us.
## Next steps
This document lays out some major principles and strategy that guide our community and team dynamics. Executing on this strategy will take effort and time to get right, and we should formalize these practices quickly. I'd propose that we do the following:
1. Iterate on this document and improve it as necessary, addressing suggestions and objections from Contributors.
2. Decide whether to adopt this proposal, via a vote of the Steering Committee.
3. Merge it into the documentation at `executablebooks.org` as a commitment to implementing these ideas.
4. Begin implementing the necessary next steps to adopt these practices (e.g., define an RFC process, formalize a code of conduct, formalize team policies, decide on an organizational home, etc).
Our goal should be to have a well-functioning community that adheres to the principles described above, and with an organizational structure that is explicit. Our final "deliverable" as PIs of the grant should be to relinquish control of the project to this new organization and allow it lead the Executable Books community into the future.
## Extra considerations and thoughts
### Who do we want to contribute?
We should build a community culture that makes everyone feel welcome and valued. As long as somebody is willing to adhere to our code of conduct and wishes to contribute in good faith, we should find a way to bring them in.
There are a number of reasons for this approach.
From a mission standpoint, our goal is to facilitate open, accessible, and reproducible computational narratives. We do this by organizing a community of people that build technology and work together towards this goal. Our organizational principles and culture should build towards the future we want: a diverse coalition of stakeholders from many perspectives acting as equals and creating together. This is also an important strategic advantage - while we will never have the raw engineering capacity of most tech organizations, we can make up for this by pooling resources across a diverse community of stakeholders.
From a tactical standpoint, there are also reasons to favor a "big tent" inclusion approach. If you assume that the goal of a project is to have contributors that consistently make high-quality contributions, this is also the model that maximizes our chance of building a healthy "contributor -> maintainer -> leader" pipeline.
There are (roughly) two kinds of contributors that will interact with our project:
1. People who make small contributions, and will move on relatively soon
2. People who make small contributions, and continue contributing enough that they become maintainers and co-leaders
The people in group 1 provide short-term value to the project, though if it takes extensive time to accept their contributions it may be a net-negative expense of energy for the maintainers. The people in group 2 are _incredibly valuable_ for an open source project, they are the only way that it continues to survive as a multi-stakeholder project. The goal of an open community like ours is to create more people in group 2. Note that this does not necessarily correlate with pre-existing engineering skill - open source projects like Jupyter have created long term contributors out of both inexperienced and experienced developers alike.
Both kinds of people are highly sensitive to whether they _enjoy_ working with an open source community. The experience of discussion, planning, and execution must be fun, positive, creative, dynamic, and inclusive. If they encounter barriers (they don't feel welcome, are made to feel inferior, have to jump through extensive hoops to make a contribution, etc) then they are less likely to enjoy themselves and less likely to participate. If they see _other people encountering barriers_, then it will have a similar effect. Moreover, they are also _connected_ with one another, and any experience (negative or positive) will be communicated to a broader community of people, resulting in a reputation (good or bad) for the executablebooks community.
We do not know who fits into either category ahead of time.
As a result, the only winning strategy is to win over **both groups** of people, by casting a wide net and being as inviting as possible. We need to practice and value the role of community-level decision making, invite participation at all levels and create pathways for other people to grow into leadership roles. This means building community dynamics that empower people to collaborate and participate in a variety of ways, emphasizing a warm and welcoming culture, and creating space for community members to make decisions in partnership with one another. The more inflexible we are in our practices, organizational structure, etc, the harder it will be for us to build this upward pathway of contributors.
#### Is this going to be a silver bullet? (no)
There is an inherent tension between making decisions _quickly_ and making decisions _thoughtfully and inclusively_. The fastest way to make decisions is to let individuals go it alone. The best way to decide inclusively is to gather extensive feedback from all possible stakeholders and wait for consensus before moving forward. Neither of these are realistic - the former makes it difficult to build a multi-stakeholder community, and the latter may slow down progress substantially.
The challenge of any open source community is to balance these two tensions according to its goals. Some goals may shift over time, or differ in one area of the project or another (for example, it may be more valuable to prioritize rapid development in a highly experimental new tool, rather than in a core tool of the stack). Other goals are hard constraints that do not shift over time. I propose that "positive, welcoming, and inclusive culture" should be one of those hard constraints. In terms of balance, this approach tries to scale rigor and inclusiveness with the impact that a decision will make.
Working out these processes will take time and effort to get right. It must begin at the leadership level of the project, with a strong commitment of its members to abide by the values and mission that defines the Executable Books community. It will take time to design and implement, and will never be perfect. That is OK and expected, provided we stick to our values and keep the mission in mind.
_Many thanks to @mmcky, @fperez, and @rowanc1 for conversations and ideas that made their way into this document_