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.

Bryan Petty 17:18 on October 9, 2013

Yeah, this sounds like the best workflow for now, as long as there still aren’t feature plugin components on core trac.

At some point here, this will eventually need to be converted over to a branch off of develop.svn too so we can start looking at patch sets directly off of core (for when we see the integration opportunities nacin was adamant about). As long as there isn’t even an official GitHub mirror of develop though, I don’t see this as a priority.

We do need to get serious about core PHP unit tests for this though, and get those written up as we go from here on out so we can stay on top of them. I’ll probably jump on that myself when I get some time here.
- Ryan McCue 01:59 on October 10, 2013
  
  At some point here, this will eventually need to be converted over to a branch off of develop.svn too so we can start looking at patch sets directly off of core (for when we see the integration opportunities nacin was adamant about).
  
  I’m looking into some of these at the moment. The main point to look at is the preparation/inserting stuff, as WP CLI would have to do a lot of the same (if it handled it thoroughly, without blindingly trusting the user). I’ve got the start of a CLI plugin (which builds off the post internals), but nothing really releasable yet. That’s where #3 and #2 came from. Both of those should also help a lot with unit testing.
  
  I’ve filed #6 as an enhancement for the unit tests. I’m happy to set up the Travis/Coveralls infrastructure once we’ve started on the tests.
Justin Shreve 21:08 on October 14, 2013

I’ve been out/busy recently but want to jump into the code and start hacking away on stuff. Is there specific enhancements or things that you would like me to focus on?

Also – did I miss something about the time changing for the chat?
- Ryan McCue 15:01 on October 21, 2013
  
  Apologies, the chat was not on last week (and won’t be this week). I’m attempting to juggle a bunch of stuff right now, hence the lack of updates.
  
  As to starting, I’m not sure at the moment. Users is probably the best thing to tackle right now if you’re looking to start something new, since it’s fairly self-contained and we already have a schema for it.