I’ve put together some specific questions for you about the new feature page proposal. It would be great if you could take the time to review the proposal before June 19th.
You can send your feedback either by commenting on this post or by sending email to deb-at-mozilla-dot-com. I’m away until June 20th, but will dig through all the feedback as soon as I return. Thanks!
The questions…
1) Do the five stages — Definition, Design, Planning, Implementation, & Release — make sense? Are there features would not go through all five stages? Are there projects that would require more or different stages?
2) Are the sections in Stage I (Definition) — Overview, Use cases, Dependencies, & Requirements — sufficient to clearly define the scope, impact, and requirements of a feature? Is there anything missing?
3) Is there anything needed for Stage II (Design) other than a Functional specification and the User Experience design?
4) Should there be additional review sections explicitly included in Stage III (Planning) in addition to Security and Privacy?
5) When completed, will Stages I, II, and III provide enough information and detail to successfully build the feature? Is there anything else engineers, QA, localization or other teams need in order to start implementation?
6) Do Stages IV (Implementation) and V (Release) need any other detail, steps, or information? As it stands, these parts of the feature page will simply be a list of bugs and a checklist of landing criteria. Is that sufficient?
7) Overall, what do you think of the new feature page format proposal? Is there anything else you think we could do to improve this system as a whole?
1) I expect that many features will need to iterate through design/planning/implementation.
2) I fully expect that you won’t know dependencies and requirements until you’ve at least completed the design phase, and perhaps well into the implementation phase. For example, the plugin crash comments feature needed design input to decide whether it would be implemented primarily client-side or server-side.
4) Many platform-level features should have a design review. This may take the form of a proposal to the whatwg list, or a review by somebody who didn’t do the original API design. It may also be necessary, depending on the feature, to get input (call it “review” if you like) from localization and addons communities.
I notice that nowhere is mentioned definite QA plans. In many cases we need to write down definite plans for measurement and also human-QA plans in advance of implementation. The simplest features to write are often the most complex to test.
I agree with Benjamin in that there’s not always sharp lines between those steps and there might be the need for iteration in some of them and that some pieces that in theory fall into Stage I or II might sometimes only become clear on a later stage. I think the wireframe is still good as long as there’s no need to be 100% strict about “one stage needs to be complete to go to the next”.