Becoming a Maintainer

So, you want to help with the development of PaperWM, but PRs just aren't cutting it for you anymore? Consider becoming a PaperWM maintainer!

What is a maintainer? How can I become one?

In the PaperWM project, a maintainer is a repository collaborator. They have write access to the repository, can create and delete releases, and can send those releases for review on GNOME Extensions.

There is no formal process for becoming a maintainer, but in general you should show involvement with the project and its discussions, understand the principles behind PaperWM's architecture, and overall be someone we can rely on and trust.

If you believe you can take up the mantle, just ask to become a maintainer and the other maintainers will help!

What are my responsibilities?

Once enrolled as a maintainer, you can feature yourself on CONTRIBUTING.md and write a short paragraph about what motivated you to join. The main responsibilities of a PaperWM maintainer boil down to these points:

• Make sure PaperWM runs on the latest GNOME version. We are a complex extension eternally racing behind an equally complex desktop environment, so your main duty will be to stay on top of the latest GNOME release and keep things functional once it drops.
• Accommodate aspiring contributors. We regularly receive issues and pull requests, and these are the lifeblood of PaperWM. You should show interest in newly opened tickets, and do your best to update and clean up outstanding issues. Don't burn yourself out -- if you don't feel like fixing an issue, encourage others to do so!
• Decide where the project is going. Like any other team project, PaperWM has governance concerns, often raised on the Discussions page. We encourage you to participate in discussions as this is where key decisions are made.
• Maintain releases on GNOME Extensions. Once you become a maintainer, you may be given secret credentials to GNOME Extensions which will allow you to publish a new version of PaperWM. If you haven't received them yet, don't fret! There are no formal conditions, you can always ask!

How do I merge PRs?

PaperWM being a community-driven project, our main source of work and bug fixes are pull requests on this GitHub repository. Given the sensitive nature of GNOME extensions (if it dies the whole desktop dies with it) we strive to keep a level of quality in contributions. In no particular order, these are the points you should look out for as reviewer and maintainer:

• Is the code targeting develop? Unfortunately GitHub does not let us define a separate "default branch" for PRs to target. We have chosen to keep release as the default for cloning and bug tracking purposes, but contributions should always target the develop branch.
• Is the code clean? For instance, no trailing spaces, no tabs for indent when the rest is spaces.
• Does it run on the latest supported GNOME version? To help with this, we have developed a test virtual machine with PaperWM preinstalled, where you can test things without messing with your main system. Personally, I also recommend daily-driving the PR on your main system to watch for eventual instabilities.
• Is it regression-free? Unfortunately, right now the unit testing system isn't done (do consider helping out!), but you should try covering complex interactions like multiple monitors and touch screens, to ensure these features aren't broken by the PR.

Leave an approving review and invite other maintainers to review the PR if possible before merging. Apart from that, use the default merging rules we've set up and be aware that merging a PaperWM branch as a PR will delete that branch.

How do I submit a new release?

In addition to GitHub, PaperWM is distributed on the official GNOME Extensions website. If you've been vetted as a maintainer, you will have access to the credentials for the PaperWM account. We ask that you please follow this checklist prior to release:

• Bump metadata.json in develop. The version-name key should match the envisioned version number you will tag afterwards. PaperWM uses the following versioning scheme: v[Latest GNOME major].[PaperWM major/breaking].[PaperWM minor]. For instance, the first version to support GNOME 50 is 50.0.0, and the next patch is 50.0.1. If you're adding support for a new GNOME version, make sure to update shell-version as well.
• Merge develop into release. The release branch is intended as a discrete snapshot of changes in develop, and there should be no discrepancies between the two branches at release time.
• Tag the topmost commit in release with the version number. This is the tag you will create the release under on the Releases page.
• Build and send the release archive for review. This is done by running make release. Make sure you're running the command on the release branch! The resulting Zip archive can then be sent as-is for review on the GNOME Extensions website.

Congratulations, you have published a new version of the best scrolling window manager, for thousands of users to enjoy!