Stryker: Discussion: Maintaining Stryker

Created on 16 Nov 2020  路  8Comments  路  Source: stryker-mutator/stryker

I'm really proud of what we've achieved here with the Stryker repository. We've got a vibrant community working together to create an awesome mutation testing framework. We've also been steadily climbing in downloads, with currently over 100k downloads/month.

With success, also the job of maintaining Stryker is growing. We don't want to fall victim to our own success here. It is time to take the next step. We should increase the number of maintainers.

However, I don't want to just add maintainers without guidance, structure, code of conduct, description, etc. I think we should come to a consensus and document that in a MAINTAINERS.md. It should explain a couple of things:

  1. Where to find the code of conduct?
  2. What is a maintainer?
  3. What can we expect of a maintainer?
  4. How do we reach discissions?
  5. How to comment on issues/PRs?
  6. What is the scope of Stryker?

    1. What is the scope of Stryker for JS explicitly?

  7. What is the release process? When do we release?

I'm jealously looking at mocha's MAITNAINERS.md, although we might be able to start with something smaller at first and expand as we see fit.

@kmdrGroch
@Garethp

What do you guys think? Since I was thinking of adding you as maintainers. Would you feel inclined to help with this? Maybe we can work together on this? @simondel also might want to pitch in.

help wanted

Most helpful comment

I think it's good to identify which kinds of works there are and what (if any) communication is required to start completing the work. Helping someone to start using Stryker or upgrading a dependency can be done alone (most of the time), but a feature request may require communication between maintainers to make sure the feature fits the roadmap.

All 8 comments

If you want, we could have some meeting :) (although sorry, I have had a little time recently due to a lot of stuff on head)

I have some boring lectures this week too, so I could think of something close to mocha :D I dunno how much I'll write tho :D

I'm happy to help with this. Here's my thoughts of the top of my head

What is a maintainer?

I do like the definition of a maintainer in Mocha but at the same time when I read it I find myself asking questions about how I would go about qualifying under its definition if applied to Stryker. Here's the ones I mean:

Where should we focus efforts?
What's urgent, what can wait?
What can we break? What's off-limits?
What user feedback is valuable? What isn't?

I think they're great questions but I have no idea what the answers are, and I think the answers come from lots of discussion. I think maybe we could add something in the Stryker version to explain how one comes to understand these points. Maybe there could be links to where this has been discussed or maybe if we do more frequent community zoom calls that can be mentioned. In short, rather than just listing what you need to understand to be a maintainer, also list ways someone can work towards getting those understandings.

What can we expect of a maintainer?

Reading through the mocha MAINTAINERS.md file, it looks like the whole file answers this question. Were you thinking of a separate section for this? A section that acts like a summary for responsibilities might make sense

What is the scope of Stryker?
What is the scope of Stryker for JS explicitly?

I think a meeting would be great on this. It's something I'd like to learn myself

What is the release process? When do we release?

I'm not sure on the process, but I vote we release often. There's nothing worse than a project that's got an important bug fix for your use-case sitting in master, but they haven't released in months. I say this as someone who's also done that exact thing multiple times.

I'm jealously looking at mocha's MAITNAINERS.md, although we might be able to start with something smaller at first and expand as we see fit.

I like the sound of essentially just "forking" it and cutting it down a bit. It's a good document that has a lot of great advice for most projects

I started a little bit and have something like this:

Stryker Maintainer's Handbook

  • Introduction
  • Terminology
    -- User
    -- Contributor
    -- Maintainer
    -- Owner

Introduction

If you are reading this document, you probably are:

  • Active maintainer of Stryker
  • Prospective maintainer of Stryker
  • Curious about how to maintain Stryker

Here, we will describe our terminology, processes and scope of the project.

Terminology

Anyone involved with Stryker is either user, contributor or maintainer.

User
"One of the horrible words we use is 'users'. I am on a crusade to get rid of the word 'users'. I would prefer to call them 'people'." - Don Norman

A user is a person who utilizes Stryker and generally lacks the technical expertise required to fully understand how it works. A user interacts with contributors and with the software, web site, documentation, etc. which contributors provide.
You are expected to follow the code of conduct when interacting in Stryker鈥檚 social spaces.

  • Any Stryker chat room
  • Any project under the Stryker organization on GitHub
  • Any event which Stryker might organise

Contributor

A "contributor" is any individual who has contributed in some way to the project and its community. Contributions include (but are not limited to):
Reporting bugs
Suggesting and debating enhancements
Helping others with questions related to Stryker
Sending pull requests which fix bugs, improve documentation, improve developer experience, improve code quality, and/or implement requested enhancements
Reviewing code on pull requests
Posting a tutorial
A contributor is also expected to adhere to the code of conduct as a user would.

Of course it needs some changes etc. I think we should make this readme "information > length"

I think it's good to identify which kinds of works there are and what (if any) communication is required to start completing the work. Helping someone to start using Stryker or upgrading a dependency can be done alone (most of the time), but a feature request may require communication between maintainers to make sure the feature fits the roadmap.

I never know what feature to add XD Im just lurking through code looking for something to improve :D I have to do some optimisations to code I have written... coz it's pretty bad in performance (sowwy)

@simondel and I made a start. Please review the PR.

@Garethp and @kmdrGroch would you like to meet virtually on Monday evening? That way we can clarify things that might be unclear and give the "keys to the kingdom" 馃攽

Yea, monday is good :)

What time were you thinking?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

nicojs picture nicojs  路  33Comments

Lakitna picture Lakitna  路  97Comments

trollepierre picture trollepierre  路  18Comments

jeznag picture jeznag  路  17Comments

kmdrGroch picture kmdrGroch  路  19Comments