Alright, after a short break…

Alright, after a short break on my behalf, let’s start getting you guys set up to contribute. The model I’d like to use for managing the project is the same one I use for most of my projects; that is, groups of changes always go in pull requests. If you’ve contributed to wp-cli, you’ll know what I mean. In a nutshell:

  • Fork the main project on GitHub
  • For a new feature, create a new branch locally and commit to that branch
  • Create a pull request (or attach your branch to an existing issue if possible)
  • I’ll review and merge

With the exception of major features, I’ll merge everyone’s pull requests as soon as possible. Non-team contributions will need sign off by at least one team member (ideally not me, to ensure there’s a few people checking), while team contributions will be merged basically straight away.

In the case of major features, file a pull request and then post here for discussion. Major features will need a rough consensus to get in, plus sign off from the team leader (hey, that’s me!).

Why am I not just giving you all commit access? For accountability reasons (especially since this is aimed at going into core), I’d like to make sure every change is signed off by myself. (One committer for the team seems the right sort of scale, since even with the size of core, it only has a handful of committers. Unlike core though, I want to move fast. :)) Rest assured that I’ll be proactive about merging your code.

Why are we not using Trac for issue tracking? Core Trac isn’t really the right place for this at the moment (but it will be eventually as we merge in), and the GSOC Trac isn’t really a great place for this either, since GSOC is over now.

As an example, I filed two enhancements, and @mordauk filed a bug fix as a pull request.