User:MarkTraceur/Multmedia team organisation

The way I see it, we have a few different steps we need to take, for any product or component we handle:


 * 1) Product prioritisation
 * 2) Analysis of potential solutions from a product standpoint
 * 3) Design (if applicable)
 * 4) Estimation
 * 5) Development
 * 6) Code review
 * 7) Documentation (if applicable) - includes mediawiki.org page(s) for technical purposes
 * 8) Testing
 * 9) Deployment (if applicable)
 * 10) Community relations (if applicable) - includes announcements, FAQs
 * 11) Reactive community relations - includes handling any talk pages that got set up above and funnelling reports into the team's planning tool(s)
 * 12) Analysis of metrics

Looking at this list, I see 4 steps in the middle (estimation, development, code review, and documentation) and one after (deployment) that are obviously the tech team's job, and one (testing) that is partially our responsibility when testing is of a technical nature.

The rest of the time, I don't think the tech team should really be involved in the product process. I think there needs to be a better separation of duties, because I find myself testing a *lot*, and I find us analyzing metrics as a group in our planning meetings (analysis of metrics is not planning, it's informing planning), and probably too much of the reactive community relations.

I think this will help us be a lot more productive, because we won't need to handle emails about community announcements, we can just handle the bug reports from talk pages and mailing lists when they come in, and we can have 1-hour planning meetings rather than spending 30 minutes analyzing metrics.

Here's what I'd propose:


 * Product team
 * Prioritisation
 * Analysis of potential solutions
 * Hand off to design, await deployed solution
 * Test any new features or user-facing bug fixes
 * Set up landing pages for major new features
 * (ongoing) Respond to talk page messages and mailing list threads having to do with the change(s)
 * Analyze any metrics that are gathered to be used in step 2 above
 * Design team
 * Designs for suggested solution
 * Hand off to tech
 * Tech team
 * Estimate time to develop proposed solution
 * Develop proposed solution
 * Review code for solution
 * Document any new technical interfaces
 * Test any technical changes - API modifications etc.
 * Deploy code (or ensure it's in a queue to be deployed)
 * Hand back to product for testing

I think we should be diligent in enforcing the lines between the subteams and keeping things from bleeding over into others' work.