rclone/MAINTAINERS.md

# Maintainers guide for rclone

Current active maintainers of rclone are:

| Name             | GitHub ID         |
| :--------------- | :---------------- |
| Nick Craig-Wood  | @ncw              |
| Stefan Breunig   | @breunigs         |
| Ishuah Kariuki   | @ishuah           |
| Remus Bunduc     | @remusb           |
| Fabian Möller    | @B4dM4n           |
| Alex Chen        | @Cnly             |
| Sandeep Ummadi   | @sandeepkru       |
| Sebastian Bünger | @buengese         |
| Ivan Andreev     | @ivandeex         |
| Max Sum          | @Max-Sum          |
| Fred             | @creativeprojects |
| Caleb Case       | @calebcase        |
| wiserain         | @wiserain         |
| albertony        | @albertony        |
| Chun-Hung Tseng  | @henrybear327     |
| Hideo Aoyama     | @boukendesho      |
| nielash          | @nielash          |
| Dan McArdle      | @dmcardle         |
| Sam Harrison     | @childish-sambino |
| Enduriel         | @Enduriel         |

Per-area ownership of code (which backend or command each maintainer looks
after) is defined in [.github/CODEOWNERS](.github/CODEOWNERS), which GitHub uses
to auto-request reviews. Two responsibilities don't map to a code path: @ncw
looks after overall project health, and @boukendesho maintains the snap
packaging.

## This is a work in progress draft

This is a guide for how to be an rclone maintainer.  This is mostly a write-up
of what I (@ncw) attempt to do.

## Triaging Tickets

When a ticket comes in it should be triaged.  This means it should be classified
by adding labels and placed into a milestone. Quite a lot of tickets need a bit
of back and forth to determine whether it is a valid ticket so tickets may
remain without labels or milestone for a while.

Rclone uses the labels like this:

- `bug` - a definitely verified bug
- `can't reproduce` - a problem which we can't reproduce
- `doc fix` - a bug in the documentation - if users need help understanding the
  docs add this label
- `duplicate` - normally close these and ask the user to subscribe to the original
- `enhancement: new remote` - a new rclone backend
- `enhancement` - a new feature
- `FUSE` - to do with `rclone mount` command
- `good first issue` - mark these if you find a small self-contained issue -
  these get shown to new visitors to the project
- `help` wanted - mark these if you find a self-contained issue - these get
  shown to new visitors to the project
- `IMPORTANT` - note to maintainers not to forget to fix this for the release
- `maintenance` - internal enhancement, code re-organisation, etc.
- `Needs Go 1.XX` - waiting for that version of Go to be released
- `question` - not a `bug` or `enhancement` - direct to the forum for next time
- `Remote: XXX` - which rclone backend this affects
- `thinking` - not decided on the course of action yet

If it turns out to be a bug or an enhancement it should be tagged as such, with
the appropriate other tags.  Don't forget the "good first issue" tag to give new
contributors something easy to do to get going.

When a ticket is tagged it should be added to a milestone, either the next
release, the one after, Soon or Help Wanted.  Bugs can be added to the
"Known Bugs" milestone if they aren't planned to be fixed or need to wait for
something (e.g. the next go release).

The milestones have these meanings:

- v1.XX - stuff we would like to fit into this release
- v1.XX+1 - stuff we are leaving until the next release
- Soon - stuff we think is a good idea - waiting to be scheduled for a release
- Help wanted - blue sky stuff that might get moved up, or someone could help with
- Known bugs - bugs waiting on external factors or we aren't going to fix for
  the moment

Tickets [with no milestone](https://github.com/rclone/rclone/issues?utf8=✓&q=is%3Aissue%20is%3Aopen%20no%3Amile)
are good candidates for ones that have slipped between the gaps and need
following up.

## Closing Tickets

Close tickets as soon as you can - make sure they are tagged with a release.
Post a link to a beta in the ticket with the fix in, asking for feedback.

## Pull requests

Try to process pull requests promptly!

Merging pull requests on GitHub itself works quite well nowadays so you can
squash and rebase or rebase pull requests. rclone doesn't use merge commits.
Use the squash and rebase option if you need to edit the commit message.

After merging the commit, in your local master branch, do `git pull` then run
`bin/update-authors.py` to update the authors file then `git push`.

Sometimes pull requests need to be left open for a while - this especially true
of contributions of new backends which take a long time to get right.

## Merges

If you are merging a branch locally then do `git merge --ff-only branch-name` to
avoid a merge commit.  You'll need to rebase the branch if it doesn't merge cleanly.

## Release cycle

Rclone aims for a 6-8 week release cycle.  Sometimes release cycles take longer
if there is something big to merge that didn't stabilize properly or for personal
reasons.

High impact regressions should be fixed before the next release.

Near the start of the release cycle, the dependencies should be updated with
`make update` to give time for bugs to surface.

Towards the end of the release cycle try not to merge anything too big so let
things settle down.

Follow the instructions in RELEASE.md for making the release. Note that the
testing part is the most time-consuming often needing several rounds of test
and fix depending on exactly how many new features rclone has gained.

## Mailing list

There is now an invite-only mailing list for rclone developers `rclone-dev` on
google groups.

## TODO

I should probably make a <dev@rclone.org> to register with cloud providers.