Create team of maintainers

So far, I’ve been the only active maintainer of this project, meaning I was the only one who could make direct changes to this repo and the tools’ configurations. Most of that work has been done on the weekly JUnit Pioneer streams on Twitch and supply and demand of my time have been somewhat balanced for a while. This has already started to change and will do so even more in the future, though: Due to the very welcome influx of capable and productive contributors demand has risen and because of new projects on the horizon that threaten the weekly streams, supply will likely fall.

In other words, I’m a bottleneck and the project would greatly benefit from more active maintainers. Fortunately, there are a few people I can think of who qualify. I will reach out to them and if they agree:

• I will ask them to quickly introduce themselves here
• they will get more permissions (write permission, to be precise)
• they will get added to team.developers in the ShipKit configuration

I am further considering to mention them in the README or on the website, but will discuss that in #188.

[nipafx]

Great, let’s flesh this out, then. I propose to extend CONTRIBUTING.md with a section that contains what I wrote in the longer message above (particularly the bullet point list) as well as my answers to @aepfli’s point:

1. How does the team align? will there be regular meetings, or will it be kept slack, on demand?

Since nobody objected, I’ll propose the team call for Tuesday 1630 UTC / 1830 CEST. Whatever we discuss/decide there, needs to be filed into tickets/PRs/etc., so it’s observable.

• What is the merge policy for code changes of maintainers? do they need to wait for an approve of another maintainer?

Yes, let’s go for at least one other maintainer to review/upvote and no dissenting opinion (no minority reports). As mentioned I reserve the right to push through / veto anything, so the buck stops with me. Note that this discussion should mostly happen on the issue, i.e. it’s decided there whether something will get implemented - the PR is mostly just execution. Also see next point.

• How are issues handled, a lot of idea arise by multiple people, and in their context they always seem to be good, but might miss reflection, or differ from the actual goal of this project. There needs to be some kind of guideline regarding that. eg. and pull request can only be merged, if the issue relating to it, was once discussed within the team.

The contribution guidelines already explain that a PR is not the place to discuss whether changes need to be made. It’s ok to provide a draft PR to explore a possible solution and discuss its validity, but the issue then needs to reflect what was learned and what decision was made and why.

Regarding “the actual goal of this project”, as mentioned we don’t really have one except to be a collection of JUnit extensions. I think we can sort out what is “worthy” and what isn’t as we do today.

• What conditions have to be met to do a release? (after #193 )

By default, any bug fix / feature should trigger a patch / minor release. Exceptions can be made if more merges are expected to happen within the next few hours, e.g. during a stream. Inversely, we should avoid more than one release per day.

• will there be an initial migration phase, where you @nicolaiparlog will support the new maintainers. Just so they get a glimpse of what it means. As with great power comes great responsibility.

I think my comment above addressed that - I won’t be out of the picture.

• As i am a fan of transparent inclusive and accessible decision making, i would also recommend to shortly define, how decisions are persisted, like in issues, and not just in discord, and how much information they should include (sidenote: i think we do a great job here, but having like a COMMUNICATION.MD to once provide it, might not be a bad idea even for the future, if the team increases again) (maybe i am just a too process focused person, but i had bad experiences with too slack definitions)

I think CONTRIBUTIONS.md is the best place for this (even if it grows large), but otherwise I agree. As soon as you give me the green light, I will open a PR that adds these policies.

[Bukama]

My first reaction was (and my feeling is still) Wow!?! Did he really ask me to become a maintainer?

I’m feeling vey honored, but I’m not blind to ignore that becoming a maintainer of a public libary like this comes with huge responsibility. So I asked myself if I’m convinced of myself able to take this and if I’m able to keep the high level of quality Nicolai’s putting into the lib. Especially for code quality in terms of effectiveness and good use of techniques I’m unsure as I know that I’m lacking a huge knowledge of JAVA - mostly because I didn’t take care of my abilites (e.g keeping up with JAVA changes) for a long because we are forced to old JAVA versions at work and got Java 1.8 at the end of 2018…Visiting Javaland conference in 2018 for the first time changed that and I’m trying to learn those features. Everytime again I’m impressed how Nicolai and others in stream chat (or in their code) playing around with e.g. streams. It will take a long time and much practice to learn at least a bit of this. And I’m one of those people who have difficulties to learn things by heart. Always had them, even back in early years of school. I mostly do understand things like math or code and I can remember “that there was something to get this done” and look it up, but I’m struggeling at learning those things by heart.

So my main value I can (and in my opinion already do) contribute to the project is having a good overview about open issues and PR. I also believe that I’m quite good a code reviews with adressing maintanability and especially naming. I also see a huge value in documentation and making things transparent. I think the tend to document is closly correlated to my struggles to learn things by heart and was also increased because I had cancer three times and was disappearing several times at work from almost one day to the next because of this. So I try do keep everything I know available for others (see bus factor).

This said I would accept the promotion, but I don’t know if my coding skills can carry the responibility to be a maintainer. So I would feel more comfortable if there would be at least one active maintainer whichs coding skills are better than mine so maybe I can play my strengths in fields I think I have them. Especially in the next weeks when Nicolai won’t have so much time. I hope our little, growing community doesn’t suffer from reduced number of streams.

Aside from the fact that myself may become a maintainer I suggest that there should be some guidelines on how the teams work should be organized. When there’s only one active person he does as he think its best. But when there are more then there should be a common thinking about how to work and decide on issues, e.g. labeling all as “in discussion” first and then decide how to deal with them and when or how to work on pull request. Those guidelines have to be much, but just as a basic alignment to have a common goal and way to achieve that and to keep harmony. Especially for new team members. For me that would also be things like “How do I rebase and update the branch of a PR without screwing it up” as everytime I try to rebase one of my branches it ends that instead of one changed file dozends were changed (like in #204). I worked on a small PHP browser game for severl years as a so called “community developer” and a the end I was the core maintainer of a small group of three. One of the others and I worked together very harmonious as we had the same goals and standards of “good software”. The codebase of this game was about ten years old and was created by two students which selflearned PHP by creating the game (therefore it was really good!). We two tried to move it step by step to a framwork to get rid of this all the bad code (I don’t blame the two origin coders as they learned programing by creating this game), but the third person (and the organizing owners of the game) didn’t want to do, which result in that we two quit the team after several years of arguing and getting more and more frustraiting. With this experience I see it quite important to have a common goal and work as a team to achieve it.