Maintainers for Q1, 2015

[tomchristie]

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.

[tomchristie]

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.

[tomchristie]

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

[tomchristie]

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.

[tomchristie]

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.

[tomchristie]

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.

[tomchristie]

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.

[tomchristie]

Gotta be the right thing to do.

[tomchristie]

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.

[kevin-brown]

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.

This is basically what I was going to suggest. 👍

It may work better if we mention it within the pull request (if it's in progress), and just make a comment when it's ready to be reviewed.

[tomchristie]

I'd rather have a tag to mark the work under progress

Not sure about that.
Easy to accidentally fail to set, difficult to search against, won't be set when the pull request is first made.

[xordoquy]

won't be set when the pull request is first made
Easy to accidentally fail to set

In both case it should be fairly easy to spot by the reviewer. The point is to avoid looping over the same PR and consider untagged PR as needing a triaging.

[carltongibson]

On the principles that:

1. Labels are cheap
2. "Pave the cow paths"

... I created "In Progess" and "Review to Merge" labels. (Rename if you hate them)

I've applied "In Progress" to #2204 — although don't let that stop you commenting.

Use these as you see fit — if you forget no problem, they can be added by someone else. — If they turn out handy we can keep them; if not, see point 1.

[tomchristie]

... I created "In Progess" and "Review to Merge" labels. (Rename if you hate them)

Deleted - I'd much rather we can try to stick to the current status of a single label for each ticket. When making a PR label it up appropriately as 'Bug', 'Enhancement', 'Docs' / whatever. Knowing when a PR is good to go hasn't been a problem in the past.

I'm also relaxing the 'must' to 'should' in the PRs - it's a process that's already not working for me.
You may expect any functionality stuff to come as a PR from me, but I'm going to reserve the right to make quick docs fixes directly for the moment.

[tomchristie]

Anyone want to be release manager for next period (and be responsible for pushing the upcoming 3.0.1 to PyPI?)

[xordoquy]

@tomchristie if you're still ok with this, let's go (my user profile on pipy is linovia)

[tomchristie]

Great!

[tomchristie]

@xordoquy You are added to PyPI. Let's run with you being release manager for now and Q1 2015?
Which will be:

• Merge the release PR (release notes and version bump)
• Push the package to PyPI.
• gh-deploy the docs.
• Send a message to the discussion group.
• Either: Send a message on twitter and prompt me to retweet it. Or: Ask me to tweet it.

I'm happy that we're about done for 3.0.1 I need to finished my work on #2242, but after that I think we should get the final release PR together, and plan to release as soon as poss after that.

[jpadilla]

@tomchristie Thanks! might want to change "Q1 2014" on the last comment and last updated to the original message to "Q1 2015".

[tomchristie]

@jpadilla Yup! :)

[xordoquy]

@tomchristie confirmed for PyPI.

[tomchristie]

Closing as team now finalized.
Opened #2253 to handle documenting this process.
Anyone interesting in maintaining for Q2 should wait until the 'Maintainers for Q2, 2015' ticket becomes created, and then comment against that.

[jpadilla]

Now that we have Transifex as well, I'm wondering if maintainers could be added over there to help with reviews and requests.

[tomchristie]

Yup that'd make sense. Prob worth a ticket, and poss pull request to the project management docs.