Maintainers for Q1, 2015

[lovelydinosaur]

This is the start of us formalizing our process for maintainers of the project. The aims for this are that the process is lightweight, and up to date.

What I'd like to try first is a quarterly renewal process whereby members must explicitly opt-in, or else drop out of the maintenance team for the next cycle. The size of the team is currently capped at 5 members. If new folks are seeking to be added to the team we can consider if we want to encourage anyone to cycle out for a period.

Suggestions of revisions to this process are welcome.

---

Renewing existing members.

The following people are the current maintenance team. Please checkmark your name if you wish to continue to have write permission on the repository for the Jan-Mar 2015 period.

• @tomchristie
• @xordoquy
• @carltongibson
• @kevin-brown

Members of this team are added as collaborators on the repository. Responsibilities are:

• Merge pull requests.
• Build and deploy the documentation.
• Add triage labels.

Further notes for maintainers:

• Code changes should come in the form of a pull request - do not push directly to master.
• Maintainers should typically not merge their own pull requests.
• Each issue/pull request should have exactly one label once triaged.
• Search for untriaged issues with is:open no:label.

---

New members.

The following are seeking to be added to the maintenance team for Q1 2015. If you wish to be considered for this or a future date, please comment against this or subsequent issues.

• @jpadilla - approved

Decisions on inclusions will currently be made on an informal basis by @tomchristie. We may choose to formalize this process at a future date.

---

Further notes.

The release manager for Q1 2015 is @xordoquy.
Responsibilities for the release manager are:

• Merge 'release' pull requests when a release is finalized. (Confirm with @tomchristie)
• Push the package to PyPI.
• Deploy the documentation with mkdocs gh-deploy.
• Send a message to the discussion group.
• Send a message on twitter.

The PyPI package is owned by @tomchristie, and additionally has @j4mie as a backup owner. If I cease to work on the project for some reason it should be considered @j4mie's responsibility to manage the handing over of ownership of the project.

[lovelydinosaur]

Future plans (probably after version 3.2) [UPDATE: Now adopted]

• Strictly enforce that all work comes via pull request (even for myself)
• Strictly enforce that no maintainer may merge their own pull request (even for myself)
• Choose someone else as the release manager to forcibly ensure that we have a bus factor > 1.

[lovelydinosaur]

We may also want to document a list of past maintainers. Believe this currently stands as @danielsokolowski @mammique @markotibold, but could be incorrect.

[lovelydinosaur]

Also at some point I also need to ensure the @j4mie has access to the django-rest-framework.org domain name account details if needed and we should document his handover responsibility for that too.

[lovelydinosaur]

Once the team for Q1 2014 is finalized, we should update this page http://www.django-rest-framework.org/topics/credits/ too. Assuming that is done as part of this ticket I'm now closing off #1992 as part of this work.

[xordoquy]

I'd be interested if we could make the three points - the future plans - earlier even though we do not strictly enforce them.
I'd be interested in the other's opinion on that. As for myself, it would make it easier to help during for the big upcoming changes and give more visibility where things are going.

[lovelydinosaur]

Well let's just adopt em starting now. Strictly. :)

Will encourage transparency & participation.

Hands up for release manager. @xordoquy, maybe?

[carltongibson]

it would make it easier to help during for the big upcoming changes and give more visibility where things are going.

I couldn't agree more on that. It should help with bandwidth and — hard to believe I know — quality too. +1 for now.

[lovelydinosaur]

Given this formalization let's also commit to #2162, either in tandem with the 3.1 release, or during the 3.0.x release cycle.

[xordoquy]

@tomchristie let's give it a try.

[lovelydinosaur]

Gotta be the right thing to do.

[lovelydinosaur]

Are we going to need flags to request final reviews or something? How do other maintainers know when someone wants their PRs reviewed/merged?

[xordoquy]

I'd rather have a tag to mark the work under progress so we can assume anything that's not tagged needs to be reviewed/merged.