When we talked about process in today’s dev chat, one thing I forgot is that at core meetup we agreed that we should post the notes and action items from each dev chat, then review the action items at the beginning of the following week’s chat to keep track of things. So here goes!
Today’s meeting focused on the process to be used for the 3.4 dev cycle and the overarching concept of the release scope. To read through it line by line, see the IRC logs for the January 4, 2012 #wordpress-dev chat.
Core team presence:┬ Jane, Ryan, Mark, Nacin, Koop, Dion. Late arrivals: azaozz, duck_. Absent: westi, matt.
Agenda: Review new process proposal that came out of Tybee core meetup, discuss; discuss potential focus for 3.4 release cycle; get statements of interest from people interested in taking more formal contributor role in this release.
At Tybee meetup, I proposed we experiment with our process to try and overcome some of our historical downfalls (lack of good time estimation, resource bottlenecks, lack of accountability, unknown/variable time commitments/disappearing devs, overassignment of tasks to some people, reluctance to cut features to meet deadline), and the core team worked as a group to come to the following process proposal.
- We’ll divvy up feature development in pairs/small teams rather than assigning anything to one person. Will┬ hopefully lead to better code, happier coders, and more accountability.
- Each pair/team will┬ ideally have a lead/committer teaming with up-and-coming contributors who want to commit to working on something specific.┬ ┬ Leads, committers, and trusted core contribs will be assigned to a team. Newer contributors can volunteer to work with a specific team but probably won’t be part of the core pair if we’re not familiar with your work yet. This will hopefully make it easier for people to get involved and make connections with the core team instead of lingering unnoticed on a ticket for months at a time.
- Each team is responsible for their feature being delivered on time and meeting interim deadlines (scoping, blog posts, posting patches, etc.).
- Each team will only be allowed to claim one feature at a time, and may not claim another until the first is complete. No more claiming multiple features and working on them simultaneously.
- If a partner/team member goes MIA, rest of team needs to find out what’s up, and if something is seriously wrong, escalate to my attention.
- We’ll have a list of who’s working on what worked into the 3.4 schedule page.
- 2-week cycles, no soft edges. Every two weeks there is a bit of discovery, a chunk of development, and a period of testing/fixing within the team.
- Overlapping team cycles. The 2-week cycles will start on a rotating basis so that teams will be in different phases at all times, allowing for fewer bottlenecks and a greater ability to weigh in on assorted projects. In between each cycle will be several days dedicated to Trac maintenance/bug fixes and tickets related to that team’s project, so that casual contributions won’t pile up waiting for a committer to take a look.
- Every week, the pair/team must post a progress report to wpdevel (once we have team assignments, we’ll make a schedule for this, like we did with gsoc student posts).
- At the end of the two week cycle, team must deliver their scoped deliverable (generally a patch). If they are late, a warning will be issued. If they miss the deadline on 2 of the cycles, the feature will be reconsidered for inclusion in 3.4.
Time Commitments,┬ Time┬ Tracking
- Each team will estimate how long each feature should take (# hours, # days – estimate both total time working on it, and how long that will be spread over based on team member schedules).
- We’ll have some mechanism for reporting time spent on the feature so that we can see how our estimates compare. Not sure if this will be manual or if we’ll use a trac plugin. Investigating options now. Individual “it took this long” stats will be private, but the aggregate “this feature took this long” will be public. This will remove any reason to fudge the time reporting out of fear of looking too slow.
- Like in any job or volunteer gig, we’ll ask people who are assigned to teams to make a specific time commitment per week to working on core in their team. We understand that circumstances change and the time commitments may need to be adjusted along the way, but this is also intended to help us do a better job of preparing scope and using stats to see how we did. If we’ve scoped features that look like they’ll require a total of x hours per week but we only have y in time commitments, we’ll know up front to start trimming scope. Note: making a formal time commitment will not be necessary for casual contributors, only those assigned as an accountable party in a pair/team.
- Each two-week cycle will be another chance to get better at estimating how long things will take, and over time we will improve at this as a group.
3.3 was in some ways a multi-featured mess without a unifying theme. This meant lots of disparate stuff going on at once, and a number of features getting pulled due to timing. We want to get back to the idea put forth a year ago about having one overarching concept/goal/theme per release, that all new feature development fits into. We agreed that 3.4’s “theme” would be, “Making it easier to make your site look how you want it to look.” Shorthand: Appearance/switching themes. The idea is that a combination of front-end features, dashboard features, and under-the-hood improvements all tied to managing your site’s appearance will be the focus of 3.4. It will also include smaller things that don’t live in the appearance section but are related to the overarching goal, such as making it possible to have links in image captions. Make sense?
The individual features will be selected next week, and the proposed list of possibilities will be put up before then in a separate post. We’ll figure out teams, everyone will do their scoping exercises for the features they are interested in working on, and then next week we can hopefully start nailing down who’ll start with what and get the final project plan in place for a dev cycle start the following week.
High-level, the features would likely include: a theme-setup wizard that would incorporate an option for configuring all the appearance-related stuff before activating a new theme (speaking of, Twenty Twelve is targeted for 3.4),┬ and then specific improvements around menus, widgets, backgrounds, headers, easier static front page process, multisite appearance management,┬ etc.
This isn’t gym class; don’t be scared. This is, as stated before, mainly about accountability for the core team. In this cycle, anyone paired with a lead should hopefully be able to lead a pair/team in 3.5, and on and on, so we wind up with lots of experienced teams in the mix. For now, that list is fairly short, but if you are interested in having an official assignment or team designation:
As we divvy up leads and committers we’ll keep your request/offer in mind. If we haven’t seen much code from you, you might want to throw yourself into bug patches over the next week or two so there are some examples of how you approach core code available. Anyone not on a team can work on any ticket and/or bug, and can confer with the appropriate team or with Master Gardener Ryan Boren for assistance as needed.┬
Tentative teams so far: Nacin/dd32/Sergey on language packs, Mark/Pete Mall on multisite, Koop/ocean90 on wizard framework. People who already expressed interest in working with a team or making a time commitment: DH-Shredder, jkudish, helenyhou, drewapicture, MasterJake, tw2113, trepmal, japheth, sabreuse, jorbin, MarkoHeijnen, josephscott, maxcutler, aarondcampbell.
We’ll regroup next week to flesh out the scope.
In case it escaped you, this is a pretty giant change from how we’ve done development in the past. It’s a risk. It could turn out to be the best thing we ever did, or it could crash and burn. Let’s all try our best to make it super awesome!