New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Maintainers for Q1, 2015 #2190

Closed
tomchristie opened this Issue Dec 3, 2014 · 27 comments

Comments

Projects
None yet
5 participants
@tomchristie
Copy link
Member

tomchristie commented Dec 3, 2014

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.

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.

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 tomchristie added the Process label Dec 3, 2014

@tomchristie

This comment has been minimized.

Copy link
Member

tomchristie commented Dec 3, 2014

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

This comment has been minimized.

Copy link
Member

tomchristie commented Dec 3, 2014

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

@tomchristie

This comment has been minimized.

Copy link
Member

tomchristie commented Dec 3, 2014

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

This comment has been minimized.

Copy link
Member

tomchristie commented Dec 3, 2014

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

This comment has been minimized.

Copy link
Collaborator

xordoquy commented Dec 3, 2014

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

This comment has been minimized.

Copy link
Member

tomchristie commented Dec 3, 2014

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

Will encourage transparency & participation.

Hands up for release manager. @xordoquy, maybe?

@carltongibson

This comment has been minimized.

Copy link
Collaborator

carltongibson commented Dec 3, 2014

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

This comment has been minimized.

Copy link
Member

tomchristie commented Dec 3, 2014

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

This comment has been minimized.

Copy link
Collaborator

xordoquy commented Dec 3, 2014

@tomchristie let's give it a try.

@tomchristie

This comment has been minimized.

Copy link
Member

tomchristie commented Dec 3, 2014

Gotta be the right thing to do.

@tomchristie

This comment has been minimized.

Copy link
Member

tomchristie commented Dec 3, 2014

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

This comment has been minimized.

Copy link
Collaborator

xordoquy commented Dec 3, 2014

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

This comment has been minimized.

Copy link
Member

kevin-brown commented Dec 3, 2014

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

This comment has been minimized.

Copy link
Member

tomchristie commented Dec 3, 2014

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

This comment has been minimized.

Copy link
Collaborator

xordoquy commented Dec 4, 2014

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

This comment has been minimized.

Copy link
Collaborator

carltongibson commented Dec 4, 2014

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

This comment has been minimized.

Copy link
Member

tomchristie commented Dec 5, 2014

... 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

This comment has been minimized.

Copy link
Member

tomchristie commented Dec 9, 2014

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

@xordoquy

This comment has been minimized.

Copy link
Collaborator

xordoquy commented Dec 9, 2014

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

@tomchristie

This comment has been minimized.

Copy link
Member

tomchristie commented Dec 9, 2014

Great!

@tomchristie

This comment has been minimized.

Copy link
Member

tomchristie commented Dec 10, 2014

@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

This comment has been minimized.

Copy link
Member

jpadilla commented Dec 10, 2014

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

@tomchristie

This comment has been minimized.

Copy link
Member

tomchristie commented Dec 10, 2014

@jpadilla Yup! :)

@xordoquy

This comment has been minimized.

Copy link
Collaborator

xordoquy commented Dec 10, 2014

@tomchristie confirmed for PyPI.

@tomchristie

This comment has been minimized.

Copy link
Member

tomchristie commented Dec 11, 2014

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

This comment has been minimized.

Copy link
Member

jpadilla commented Mar 7, 2015

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

@tomchristie

This comment has been minimized.

Copy link
Member

tomchristie commented Mar 7, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment