New feature page proposal

tl;dr

We’re working on a new Feature page proposal, making the whole system easier to use. It’s structured around the five stages each feature passes through during its development. It also makes use of a new Mediawiki add-on that lets us create queries and autogenerate lists on other wiki pages. We’re going to start using this new format at the end of June, so please give us your feedback ASAP.

The proposed new format can be found here:

https://wiki.mozilla.org/User:Dria/NewFeaturePageStructure2

The longer version

The new format aims to be more logically — and chronologically — ordered. Rather than being a mishmash of specs and lists and use cases and so forth, the new feature page includes five “stages” that the feature passes through: Definition, Design, Planning, Development, and Release.

We still have whatever flexibility we need to move back and forth between stages as needed as the feature is developed. For the most part, however, a feature will move from one stage to the next, with a straightforward review and sign-off by the relevant teams at the end of each.

We know that not every feature will need as much detail as this. After working through a few dozen of these we’ll have a stronger idea of which parts are necessary or not given the relative complexity of each and the scope of the work being done.

The stages

Stage I: Definition

This is where a feature is born and defined. If you would like to propose a new Feature, start by writing up a clear overview and a by defining the feature’s intended users and use cases. Where possible, you are encouraged to add to the list of the dependencies and requirements, but the Product team will help flesh out these parts if you don’t include them.

Stage II: Design

In this stage, Products, Engineering, UX, and/or User Research work together to finalize the feature’s functional specification and, if needed, the user experience design.

Stage III: Planning

With the requirements and design clarified and approved, the feature moves into the planning stage, where the Engineering team sorts out the overall technical approach that will be taken, and other stakeholder teams (Security, Privacy, QA, Accessibility, Localization, etc.) have the opportunity to review the feature in detail. This stage is complete when all stakeholder teams finish their reviews and are comfortable with the requirements, design, and plan for implementation.

Stage IV: Development

This is where coding begins and activity for feature development moves into Bugzilla. Detailed progress tracking will not be done on the wiki — that should all happen in Bugzilla, and will not be replicated on the feature pages. Product or project managers are responsible for updating the status on the feature pages if and when needed.

Stage V: Release

This stage documents the final checklist of everything the team feels should happen before a feature can land. Over time, we’ll develop a standardized checklist for this, but we’ll sort that out as we go. For now, the team will create their own checklist and ensure that everything on it is complete before the feature lands.

When a feature is released as part of a shipped product, it is considered “Complete” and the feature page is then archived for future reference.

Queryable data

The new feature page format includes some other information in addition to the stage sections, all of which can be used to query the pages and magically generate lists on other pages. This is all done by way of templates, and should be seamless to anyone creating or editing the pages themselves.

The new “Team status notes” table has been included because several of the stakeholder teams (Security, Privacy, Localization, etc) have asked for a way to include their own unique status notes on each feature. All of the values in this table are queryable, and can be used to generate customized lists for each team to simplify feature page & status tracking.

Feedback, comments, and questions

We will not start broadly using this new feature page format until the latter half of June, and we would like as much feedback on it as possible between now and then.

Please leave comments on this post, email them to me directly (deb at mozilla dot com), ping me in IRC (“dria”), or speak directly with me or any other member of the Products team.

Please note: I will be away from Wed Jun 8 until Mon Jun 20. Do not be shy about sending your feedback along in the meantime — I’ll be diving back into this as soon as I return.