NUnit Docs Vision

The NUnit docs site is a project within the NUnit organization.

Its vision is to make it easier for NUnit's community to better understand and connect with NUnit's projects, and to make this documentation accessible to anyone who wishes to contribute back. The docs, in order to be successful, must be more than a hosting place for the separate projects' information. They must be a uniform and holistic journey for users to navigate the ecosystem and be confident that they understand things.

Stakeholders / Collaborators

The docs project supports and collaborates with the other NUnit projects and their respective leads -- for reference, those are currently:

Project	Lead
Framework	@rprouse
Console and Engine	@ChrisMaddock
VS Adapters and Test Generator	@OsirisTerje
NUnit Analyzers	@mikkelbu
Xamarin Runners	@rprouse

Values: how we aim to operate the docs project

• We aim for a culture of proactive collaboration over rigid rules and process. Our goal is to further our community's knowledge; we won't get hung up on the process if everyone's working toward that end goal.
• We aim to make it easy to get involved. Newcomers will be welcome, and the ability to contribute should be clear.
• We aim for progress over consensus. We'll sometimes merge changes before everyone agrees, in order to keep things moving forward. That also means keeping an open mind about reverting things. Docs are more malleable than code; we'll try to use that to our advantage.
• We respect the project teams and their immense contributions. The docs don't exist without other project leads and members or the core team. Their opinion matters and is always welcome.
• We aim to be a support mechanism for project teams as much as possible. We will suggest potential documentation improvements, but we also aim to enable project teams to ping us in conversations that might merit documentation to be included, or to make a suggestion that we can attempt to run with. We want to enable better docs, which means enabling other project teams to lean on us for support wherever possible.
• We welcome suggestions and contributions. Whenever possible, we will work to support contributions to the docs. And we consider the raising of issues and suggestions to be a form of contribution.
• We aim to broadcast our intentions, radiate information, and work in public. It should be clear what's in the roadmap for the docs, and we will aim to broadcast the changes we'll make before we take them.

These values will sometimes conflict, and we'll feel it out and talk it out when they do.

Who makes changes to the docs

Given that there are many projects that feed into the docs and their members and leads work hard to maintain things, our goal is to be able to modify the docs without making it harder for project team members.

• Any change has to pass the docs build process, linters, etc. before being merged. That process will continue to evolve to ensure the docs have a great build & release story.
• Typos, small content corrections, stylistic consistency, grammatical changes, and clear bug fixes are places where docs team members can make & merge changes without project member approval.
• In general, we will ask everyone to aim to create an issue before submitting non-routine changes for consideration. This allows space for discussion ahead of changes.
• We'll attempt to alert project teams or members to changes in their area in case they want to offer their insights. If no project team members respond within 48 hours, the docs team will work with the PR as they see fit (waiting on input, or merging). Some changes will absolutely require input from the project team; we'll be sure to involve the project team in those cases. Should a project team have a concern after a merge, we'll remember our overall values and work with them to resolve any concerns as a high priority.
• We'll give a wide berth and strong deference to project members / leads on their content changes. While we ask for the same PR process to make suggestions, we'll ensure that project leads and core team members have access to write to the docs in case they have a time-sensitive change to make; we trust them everyone operate in the spirit of the values of the project.