1# Maintainers guide for rclone #
2
3Current active maintainers of rclone are:
4
5| Name             | GitHub ID         | Specific Responsibilities    |
6| :--------------- | :---------------- | :--------------------------  |
7| Nick Craig-Wood  | @ncw              | overall project health       |
8| Stefan Breunig   | @breunigs         |                              |
9| Ishuah Kariuki   | @ishuah           |                              |
10| Remus Bunduc     | @remusb           | cache backend                |
11| Fabian Möller    | @B4dM4n           |                              |
12| Alex Chen        | @Cnly             | onedrive backend             |
13| Sandeep Ummadi   | @sandeepkru       | azureblob backend            |
14| Sebastian Bünger | @buengese         | jottacloud, yandex & compress backends |
15| Ivan Andreev     | @ivandeex         | chunker & mailru backends    |
16| Max Sum          | @Max-Sum          | union backend                |
17| Fred             | @creativeprojects | seafile backend              |
18| Caleb Case       | @calebcase        | tardigrade backend           |
19
20**This is a work in progress Draft**
21
22This is a guide for how to be an rclone maintainer.  This is mostly a writeup of what I (@ncw) attempt to do.
23
24## Triaging Tickets ##
25
26When 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.
27
28Rclone uses the labels like this:
29
30* `bug` - a definite verified bug
31* `can't reproduce` - a problem which we can't reproduce
32* `doc fix` - a bug in the documentation - if users need help understanding the docs add this label
33* `duplicate` - normally close these and ask the user to subscribe to the original
34* `enhancement: new remote` - a new rclone backend
35* `enhancement` - a new feature
36* `FUSE` - to do with `rclone mount` command
37* `good first issue` - mark these if you find a small self contained issue - these get shown to new visitors to the project
38* `help` wanted - mark these if you find a self contained issue - these get shown to new visitors to the project
39* `IMPORTANT` - note to maintainers not to forget to fix this for the release
40* `maintenance` - internal enhancement, code re-organisation, etc.
41* `Needs Go 1.XX` - waiting for that version of Go to be released
42* `question` - not a `bug` or `enhancement` - direct to the forum for next time
43* `Remote: XXX` - which rclone backend this affects
44* `thinking` - not decided on the course of action yet
45
46If 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.
47
48When 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).
49
50The milestones have these meanings:
51
52* v1.XX - stuff we would like to fit into this release
53* v1.XX+1 - stuff we are leaving until the next release
54* Soon - stuff we think is a good idea - waiting to be scheduled to a release
55* Help wanted - blue sky stuff that might get moved up, or someone could help with
56* Known bugs - bugs waiting on external factors or we aren't going to fix for the moment
57
58Tickets [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.
59
60## Closing Tickets ##
61
62Close 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.
63
64## Pull requests ##
65
66Try to process pull requests promptly!
67
68Merging pull requests on GitHub itself works quite well now-a-days 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.
69
70After 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`.
71
72Sometimes 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.
73
74## Merges ##
75
76If 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.
77
78## Release cycle ##
79
80Rclone 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.
81
82High impact regressions should be fixed before the next release.
83
84Near the start of the release cycle the dependencies should be updated with `make update` to give time for bugs to surface.
85
86Towards the end of the release cycle try not to merge anything too big so let things settle down.
87
88Follow 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.
89
90## Mailing list ##
91
92There is now an invite only mailing list for rclone developers `rclone-dev` on google groups.
93
94## TODO ##
95
96I should probably make a dev@rclone.org to register with cloud providers.
97