We've written this document for:
- Active maintainers of Stryker.NET
- Prospective maintainers of Stryker.NET
- Anyone curious about how Stryker.NET's maintainers maintain Stryker.NET
The purpose of this document is to describe our processes. We want to avoid conflicts and confusion around "unwritten rules". In our opinion, the most straightforward way to address this is to write them down. This also happens to be the most straightforward way to change them!
This is the most important thing: You don't have to write code to be a contributor!
A "contributor" is any individual who has given back in some way to the project and its community. Contributions include (but are not limited to):
- Reporting bugs which follow the reporting guidelines
- Suggesting and debating enhancements that have wide applicability
- Helping others with Stryker-related questions on Slack, or other sites.
- Sending pull requests which fix bugs, improve documentation, improve developer experience, improve code quality, and/or implement requested enhancements
- Reviewing code on pull requests
- Providing design assets
- Posting a tutorial on a personal blog or blogging site
- Organizing a "Stryker" event or workshop
- Spreading the love for mutation testing and test quality in general.
- Recruiting more contributors! Don't spam.
- Researching the user base, getting feedback, etc. Don't spam.
A contributor is usually a user as well, but this isn't a hard-and-fast rule. A contributor is also expected to adhere to the Code of conduct as a user would.
A maintainer has certain "rights" (or "permissions") to the Stryker.NET project and other projects under the stryker-mutator organization. These rights come with increased responsibilities.
However, there is no expectation of a standard of technical ability to be a maintainer of Stryker.NET. This doesn't imply a lack of technical oversight--every pull request will eventually be reviewed.
If you think you aren't experienced enough to maintain a project like Stryker.NET, you are incorrect. The only requirements are the above responsibilities and a desire to help the project. It bears repeating:
You don't have to write code to be a maintainer!
A maintainer is synonymous with "Collaborator" in GitHub parlance.
As a maintainer, you are expected to not just "follow" the code of conduct, but embody its values. Your public behavior, whether in the physical or virtual world, reflects upon the project and other maintainers.
If you don't understand the code of conduct, or why it exists, it is your responsibility to educate yourself. This does not imply the CoC is immutable.
Furthermore, a maintainer is a contributor who contributes regularly, or expresses a desire to do so. That could be every day--but it might be once a week, or even once a month. Your boss doesn't work here; contribute as often as you wish. We are all people with Real Lives, and for many of us, contributing to OSS is just a hobby!
Finally, a maintainer must help define what makes Stryker "Stryker". At a minimum, a maintainer must understand the current definition (if a maintainer is not interested in decision-making). Some of these questions include:
- What's the scope of Stryker.NET?
- Where should we focus our efforts?
- What's urgent, what can wait?
- What can we break? What's off-limits?
- What user feedback is valuable? What isn't?
As maintainers, we work together to learn about the nature of these questions. If we try hard enough, we even come to some answers!
A maintainer must also have 2FA enabled on their GitHub account.
You may choose to do zero or more of these at their discretion:
- Merge pull requests
- Modify issues (closing, adding labels, assigning them to other maintainers, etc.)
- Cancel builds, restart jobs, or otherwise interact with our CI server(s)
- CRUD operations on GitHub integrations
- Participate in the decision-making process
Some maintainers will have full admin rights to the stryker-mutator organization and/or will have access to publish to nuget.
- Those with publishing access are expected to use nuget's 2FA.
- This level of access will be granted by the current owners to those maintainers who have earned the project's trust.
- Add new maintainers to the team.
Stryker.NET follows a consensus-seeking decision-making process. In other words, all maintainers attempt to come to an agreement. If that fails, owners will decide.
Active maintainers will make an effort to solicit feedback from others before making important or potentially controversial decisions. Given the varying geographical distribution and availability of the maintenance team, we resolve to do the best we can to solicit feedback.
In other words, to have your opinion heard, participate regularly. The rest of the team won't wait on feedback that isn't necessarily forthcoming!
Maintainers will mainly gather in the stryker-net channel on slack. This is a public channel, and anyone can join.
All new issues will need to be triaged, and pull requests must be examined. Maintainers must understand Semantic Versioning ("SemVer"), as Stryker.NET follows it semi-strictly.
We’re also using conventional commits (or see summary here). This means that the commit message decides the next release version number as well as the annotation in the changelog. This why it is important to always squash merge PR’s and decide on a good commit message.
Some examples:
✅ A feature without breaking change.
feat(Regex mutations): Add regex mutations. Not enabled by default.
✅ Fix something in the docs (won’t appear in changelog)
docs(plugins): fix dead link
✅ A feature with a breaking change
feat(options): Standardize stryker CLI options
BREAKING CHANGE: All options have been reworked. Your existing commandline and json config will most likely no longer work.
❌ Comment message has to be present tense
~~ feat(vstest): fixed cleanup of vstest from temp ~~
❌ Format issues:
~~ feat(Html reporter) Add html reporter ~~ // missing : ~~ feat: Add html reporter (#2622) ~~ // missing subject
❌ Scope too vague
feat(stryker): changed option
It is important to note that these message are not necessary when contributing a PR, only when squash merging them (we only care about commit messages on the master branch).
Once more: Only use squash merge to the master branch.
All maintainers should be courteous and kind. Thank the external contributor for the pull request, even if it is not merged. If the pull request has been opened (and subsequently closed) without discussion in a corresponding issue, let them know that by creating an issue first, they could have saved wasted effort. Clearly and objectively explain the reasoning for rejecting any PR.
If you need more information on an issue, nicely ask the user to provide it. Remind them to use the issue/PR templates if they have not.
Use GitHub's code review features. Requesting a review from another maintainer may or may not actually result in a review; don't wait on it. If the PR cannot move forward without input from a certain maintainer, assign them to the PR. If you’re waiting on someone, send them a direct message on Slack.
There will be jerks.
These are users who feel the Stryker.NET project and its maintainers owe them time or support. This is incorrect.
However, this behavior is often indicative of someone who is "new" to open source. Many just don't know better. It is not your responsibility to educate them (again, you owe them nothing).
Here are some suggestions:
- If u mad, wait 20 minutes before writing a comment.
- "Kill them with kindness". Explain how they are presenting themselves; maybe link to a good article or two about it.
- Don't make it about "users vs. maintainers". Treat them like a potential future maintainer.
- Avoid adding to the drama. You could try to reach out privately; email may be in their GitHub profile. You will likely never hear from that individual again (problem solved)
- If an issue is getting out of control, lock it.
- If someone is repeatedly rude and does not correct their mistakes, you may ban them from participating in the
stryker-mutatororg. If you do not have permission to do so, contact someone who does (an "owner").
We release when we feel like it. However, we don’t want to overwhelm users with new versions. We might decide to group features together, in order to not release multiple minor versions in a short period of time.
The Stryker Mutator initiative consists of 3 main mutation testing frameworks:
- StrykerJS (for JavaScript and friends)
- Stryker.NET (for C# and maybe other .NET languages)
- Stryker4s (for scala and maybe other JVM languages)