This project is read-only.

Feature Team Process

Topics: Core
Oct 6, 2011 at 7:15 PM
Edited Oct 6, 2011 at 7:20 PM

As we are starting work on new features with feature teams, I wanted to write down some very lightweight process so that we are on the same page and integration of the new features is as easy as possible. This is not written in stone and comments are welcome.

Feature Teams are formed by the steering committee, after which a call for volunteers is published on these forums.

The first step in the team's work is to write down a design draft proposal and to publish it on the announcement thread for the team. That proposal should be validated by the steering committee. Prototyping is also encouraged.

The second step is to break down the design into atomic tasks that can ideally be performed in parallel. If they can't be performed in parallel, please annotate the corresponding tasks with a note pointing to the tasks it depends on. Prefix the task with the name of the team ("perf:", etc.). The default tool that we'll use to track those tasks is the Orchard board on Trello. It's a free tool. If you want to participate in a feature team, you should have an account. Once you have that, send me a note and I'll add you to the Orchard board.

Don't hesitate to break tasks down into smaller ones if you can.

Coding work by the feature team should be done in a fork of the 1.x branch. Work on the team's fork should be associated with a Trello task. The process is that you pick a task in the "to do" column and move it to "doing". Once you're done with a task, move it to "for review". Once it's been acknowledged by the team, you can move it to "done" and move on to the next task.

Documentation work should be done on New topics should be annotated with a note on top saying that this is work in progress for a future feature. Add a link to the feature team's thread.

Bar for integration: we will only integrate a team's fork back into the 1.x branch under the conditions that code reviews have been done (we'll have a tool for that, and until then we can use the CodePlex annotation tool), that sufficient test cases exist, that integration has been tested and that documentation exists.

Feedback: feature teams should regularly ask for feedback on their thread, and should send regular status reports to the steering committee (preferably every week).

One final note: once you sign up for a feature team, please be ready to watch and fix bugs on your work. Or don't write bugs ;) But that is of course impossible.

Oct 6, 2011 at 7:51 PM

Oh, one very important thing I missed (thanks to bradmi for reminding me): if you are going to contribute to a feature team, you must sign a Contribution License Agreement with the Outercurve Foundation. For this to happen, you need to send me e-mail (bertrandleroy at gmail) and I'll get you in. See for more details.