Add WireMock co-maintainers role and document the merge process

[oleg-nenashev]

This change should help us to increase velocity of changes

• Add a role of a WireMock Co-maintainer, which also stems from a co-maintainer in the Community charter
• Document the Merge process for WireMock 3,x Beta
• Document the process in the community repo, e.g. make a call regarding the CLA for co-maintainers

Motivation

There are a lot of open pull requests that are important to end users and contribute to the WireMock 3.x scope. They keep accumulating overlaps and potential merge conflicts, and also do not get evaluation in the Beta releases.

The only current maintainer, Tom Akehurst, combines a number of roles and does not have much bandwidth to review and merge pull requests. So we need more review and maintainer bandwidth

Nominated co-maintainers

I would suggest to make the following contributors co-maintainers, or to work towards enabling them.

• @oleg-nenashev
• @Mahoney
• @timtebeek
• @oleg-nenashev
• @rodolpheche - if we include WireMock Docker into the scope now or later

[jamietanna]

Although I agree with this - if something was to be merged, it's still possible to revert it before the next release, right? I assume Tom right now is the only person releasing the library, and it's unlikely(?) that folks are generally using SNAPSHOTs or pulling the latest commits, so it may be less worrisome if something did get merged and needs to get unpicked?

[jamietanna]

As someone who's previously been involved in the project - and has some arguably co-contributor access - would we also be doing a review of who currently has write access to the repo and reviewing their access?

I'd be very happy if this review found that my access wasn't necessary and you'd like to remove it for now, until I get to the point of being more involved in code contributions to Wiremock.

[oleg-nenashev]

Thanks for the feedback @jamietanna!

Although I agree with this - if something was to be merged, it's still possible to revert it before the next release, right? I assume Tom right now is the only person releasing the library, and it's unlikely(?) that folks are generally using SNAPSHOTs or pulling the latest commits, so it may be less worrisome if something did get merged and needs to get unpicked?

The idea is to actually automate the releases and to make them possible for co-maintainers. For the continuous delivery it is important to keep the main branch ready for release, so reverting is not the best approach. It also becomes a manual procedure once there is a merge conflict on the top of it.

So it is better to not merge changes that have not yet received a signoff

As someone who's previously been involved in the project - and has some arguably co-contributor access - would we also be doing a review of who currently has write access to the repo and reviewing their access?

Yes. Some audit would be needed. At the same time, there is no intent to revoke permissions of any active contributor

[oleg-nenashev]

Approved by @tomakehurst in the DM chat

[jamietanna]

Makes sense, thanks for the clarification!