Feature process updates (#183) r=vladikoff

* Update README, and flatten the "proposed" and "shipped" directories.

We don't really seem to be making use of them anyway,
and the state of features is now tracked in the features board.

* Update feature doc template from @davismtl's gdoc version

* Update list of core project people in the docs.

* Rmove mention of Aha, updating docs on waffleboard conventions.

* Update descriptions of our standing meetings.

docs/dev-process.md

@@ -5,11 +5,10 @@ cut a release "train" that goes through deployment to stage and into production.
 
 ## Product Planning
 
-Product-level feature planning takes place in Aha:
+Product-level feature planning is managed via github issues
+in a special "features waffleboard":
 
-* [High-level Product Goals](https://mozilla.aha.io/products/FXA/strategic_imperatives)
-* [Ongoing Initiatives](https://mozilla.aha.io/products/FXA/initiatives)
-* [Individual Feature Cards](https://mozilla.aha.io/products/FXA/feature_cards)
+* [The fxa-features waffleboard](https://waffle.io/mozilla/fxa-features)
 
 ## Issue management
 
@@ -28,7 +27,7 @@ Issue status is reflected by the following:
 
 ### Milestones
 
-When we start working on feature card from Aha, we create a corresponding
+When we start working on a card from the features board, we create a corresponding
 [milestone in github](https://github.com/mozilla/fxa/milestones) and break
 down the task into bugs associated with that milestone.  There's also an ongoing
 ["quality" milestone](https://waffle.io/mozilla/fxa?milestone=FxA-0:%20quality)
@@ -51,9 +50,8 @@ Issues that are not being actively worked on are managed in the following column
 
 Issues that are under active development are managed in the following columns:
 
-* **now**:  issues that we've committed to for the current development cycle.
-* **progress**:  issues that someone is actively working on.
-* **review**: issues that have a PR ready for review; the assignee is the.
+* **active**:  issues that someone is actively working on.
+* **in review**: issues that have a PR ready for review; the assignee is the.
 * **blocked**:  issues on which progress has stalled due to external factors.
 
 All issues in these four columns should have an assignee, who is the person
@@ -84,7 +82,7 @@ Issues in the **triage** column should move into one of the other columns
 via these guidelines:
 
 * If it's so important that we need to get to it in the next few days,
-  put it in **now** and consider adding a **❤❤❤** label to
+  put it in **active** and consider adding a **❤❤❤** label to
   increase visibility.
 
 * If we should get to it in the next few weeks, put it in **next**.
@@ -103,14 +101,15 @@ welcome to deal with issues in the **triage** column at any time.
 ## Checkin Meetings
 
 The team meets regularly to stay in sync about development status and ensure nothing
-is falling through the cracks. During meetings we take notes in the **[public Engineering Coordination etherpad](https://public.etherpad-mozilla.org/p/fxa-engineering-coordination)**.
+is falling through the cracks. During meetings we take notes in the
+**[public Engineering Coordination etherpad](https://public.etherpad-mozilla.org/p/fxa-engineering-coordination)**.
 
 We hold the following meetings over the course of each
 two-week cycle, with meeting times pinned to Mozilla Standard Time (aka Pacific Time).
 
-### Mondays at 09:00
+### Mondays at 08:30
 
-This is a 15 minute meeting slot, followed by a bug triage session.  It's in a
+This is a 30 minute meeting slot followed by a bug triage session.  It's in a
 timeslot that's convenient for Europe and US-East.
 
 ##### First week: Outbound Train Review
@@ -127,34 +126,28 @@ at this point are moved back into **next**.
 
 ### Mondays at 13:30
 
-##### First week: Outbound Train Demos and Retrospective
+##### Weekly: Show and Tell and Share
 
-We get together to demonstrate any new features that will be included on the outbound train,
-or any other interesting work that was compelted in the previous cycle.  We also talk about
-the development process itself, doing a "start/stop/keep" analysis of the previous two weeks.
-
-##### Second week: No Meeting
-
-There's no point in meeting just because...
+We get together to demonstrate any new features that will be included on the next train,
+or any other interesting work that was completed in the previous cycle.
 
 ### Mondays at 14:00
 
 This is the one time each week where all team members everywhere in the world get together
 in the same (virtual) room at the same time.
 
-##### First week: Sprint Planning Meeting
+##### First week: Dev Planning Meeting
 
-We review any items remaining in **now**, **progress** or **review** to determine whether they
+We review any items remaining in **blocked**, **review** or **active** to determine whether they
 should carry over to the upcoming train, or be de-priotitized.  We then work through the issues
 in **next** to decide what to commit to for the upcoming train.
 
-##### Second week: Status Updates and Retrospective
+##### Second week: Retrospective
 
-Since this is our only whole-team timeslot, we take the opportunity to do a round of status
-updates and give everyone a chance to raise any comments or concerns.  We can also use the
-remaining time to continue the "start/stop/keep" restrospective from the previous week.
+We take time every two weeks to explicitly reflect on our development process.
+What worked, what didn't, what new things we'd like to try.
 
-### Tuesdays at 15:30
+### Tuesdays at 14:00
 
 This is a 15 minute meeting slot, followed by a bug triage session.  It's in a timeslot
 that's convenient for US-West and Oceania.
@@ -177,7 +170,7 @@ This is a quick 15-minute checkin in a timeslot convenient for Europe and US-Eas
 We take 15mins to checkin with each other about anything that's blocked or otherwise needs help.
 Items in the **blocked** column should receive special attention.
 
-##### First week: Items in Danger
+##### Second week: Items in Danger
 
 We take 15mins to identify any items that are in danger of not being completed this train, and
 ensure we either have a plan for completing them, or take them off the train.

docs/index.md

@@ -37,18 +37,16 @@ development, and will be happy to help answer any questions you might have:
 
 * [Ryan Kelly](https://github.com/rfk) - Engineering (Melbourne, approx UTC+10)
 * [Shane Tomlinson](https://github.com/shane-tomlinson/) - Engineering (London, approx UTC)
-* [Danny Coates](https://github.com/dannycoates/) - Engineering (Portland, approx UTC-8)
 * [Sean McArthur](https://github.com/seanmonstar) - Engineering (Irvine, approx UTC-8)
 * [Vlad Filippov](https://github.com/vladikoff) - Engineering (Toronto, approx UTC-5)
 * [Vijay Budhram](https://github.com/vbudhram) - Engineering (Orlando, approx UTC-5)
 * [Phil Booth](https://github.com/philbooth) - Engineering (London, approx UTC)
 * [John Morrison](https://github.com/jrgm) - Operations (Mountain View, approx UTC-8)
-* [Chris Kolosiwsky](https://github.com/ckolos) - Operations (Indiana, approx UTC-6)
-* [Peter deHaan](https://github.com/pdehaan) - QA (Mountain View, approx UTC-8)
+* [Jon Buckley](https://github.com/jbuck) - Operations (Toronto, approx UTC-5)
 * [Ryan Feeley](https://github.com/rfeeley) - UX (Toronto, approx UTC-5)
-* [John Gruen](https://github.com/johngruen) - UX (NYC, approx UTC-5)
 * [Chris Karlof](https://github.com/ckarlof) - Identity Services Manager (San Francisco, approx UTC-8)
 * [Edwin Wong](https://github.com/edwong) - Program Manager (San Francisco, approx UTC-8)
+* [Alex Davis](https://github.com/davismtl) - Product Manager (Mountain View, approx UTC-8)
 
 We meet regularly to triage bugs and make grand plans for the future.  Anyone is welcome to
 join us in the following forums:

features/README.md

@@ -5,24 +5,17 @@ lightweight planning and tracking mechanism
 for new feature development in Firefox Accounts.
 
 Each sub-directory named "FxA-XX-YYY"
-corresponds to a [feature card in aha](https://mozilla.aha.io/products/FXA/feature_cards)
+corresponds to a feature card in the
+[features waffleboard](https://waffle.io/mozilla/fxa-features)
 and provides the details of
 how the feature will look and behave,
 how it will be implemented,
 and how we'll determine whether it was successful.
 
-The features in the top-level directory
-are the ones being active worked on.
-New incoming features
-are in the "proposed" subdirectory,
-while completed features
-are under "shipped"
-for historical reference.
-
-Want to propose a new feature?
-Open a PR adding its description
-to the "proposed" directory,
-and we can chat about it in the issue.
-
-You can use the [TEMPLATE.md](TEMPLATE.md) and [TEMPLATE_CLEAN.md](TEMPLATE_CLEAN.md)
-from this directory to quickly get started.
+Proposing a new feature?
+You should start by filing an issue in the
+[features waffleboard](https://waffle.io/mozilla/fxa-features)
+for discussion.
+Once you're ready to specify things in detail,
+you can use the [TEMPLATE.md](TEMPLATE.md) and [TEMPLATE_CLEAN.md](TEMPLATE_CLEAN.md)
+files from this directory to get started with a PR.

features/TEMPLATE.md

@@ -1,12 +1,32 @@
 # [ Feature Title ]
 
+> You can include context or meta-data here if needed.
+> For example, links to past features or bugs,
+> or links to dashboards that spurred this feature into action.
+
+> For example, here's a Google Docs version of this template:
+> https://docs.google.com/document/d/1iGaLTwPYA6AmxJ8EssuMyNoErsgun4vPOcC-ijfixIY/
+
+
 ## Problem Summary
 
-> Talk about current goals of the system and how they aren't being met. What outcomes are we not delivering? This can also include an explicit request for improvement that doesn't dictate a specific or concrete solution.
+> Talk about current goals of the system and how they aren't being met.
+> What outcomes are we not delivering?
+> This can also include an explicit request for improvement
+> that doesn't dictate a specific or concrete solution.
+
+> What user problem(s) are we trying to resolve?
+
+> This is a good place for user stories,
+> but don't feel forced into writing an awkward one
+> just to fill in the space.
+
 
 ### Assumptions (optional)
 
-> This is where you talk about what you assume to be true. This could include assumptions around what users are doing, errors, gaps, etc., based on anecdotes, opinions, testing, or data.
+> This is where you talk about what you assume to be true.
+> This could include assumptions around what users are doing,
+> errors, gaps, etc., based on anecdotes, opinions, testing, or data.
 
 ****
 
@@ -16,32 +36,88 @@
 
 ## Hypothesis
 
-> A high level hypothesis of how the feature you're proposing is going help us achieve the outcomes listed above. I recommend this be a sentence of the form:
+> A high level hypothesis of how the feature you're proposing
+> is going help us achieve the outcomes listed above.
+> Ideally this be a sentence of the form:
 
-> We believe that
-(doing this/building this/creating this experience)
-for (these people)
-will achieve (this outcome).
-We will know this is true when we see this
-(qualitative feedback/quantitative feedback/KPI change).
+> If we (do this/build this/create this experience)
+> for (these users),
+> then we will see (this outcome)
+> because we have observed (previous evidence)
+> from (data source, URL, survey, etc).
 
 ## Metrics
 
-> How are you going to measure the outcome / success?
+> What is the primary success metric to confirm hypothesis?
+> Be precise and explicit, preferably by providing a sample aritfact or graph.
 
-> **Please provide sample artifact graphs here.**
+> Are there secondary success metrics
+> which could potentially prevent this feature from rolling out?
+
+> How will these metrics be measured? (tool, data source, visualization, etc.)
+> Do we have baseline values already?
+
+> **Please provide sample artifact graphs.**
 
 ****
 
 ## Detailed design
 
-> This is the bulk of the RFC. Explain the design in enough detail for somebody familiar
-with the language to understand.
-This should get into specifics and corner-cases, and include examples of how the feature is used.
+> This is the bulk of the RFC.
+> Explain in enough detail to try to make it readable to someone outside of the team
+> (other PMs, executives, etc) or for someone joining the team.
+
+> An additional goal is to reduce any doubt within the interpretation of metrics we might collect.
+> This should get into specifics and corner-cases, and include examples of how the feature is used.
+
+### Original Version (Present Day)
+
+> What is the current situation in regards to this feature?
+> How does it currently work?
+> No need to go in as much detail as the suggested change but just enough
+> to provide contrast and more context. Screenshots and user flow can often be enough.
+
+### Variation A
+
+> Provide details of change.
+> If this is one of multiple variations,
+> why do we think this change will make the better improvement.
+> Include:
+>  * Screenshots with appropriate explanation
+>  * User flow
+
+### Variation B
+
+> Like Variation A.
+> Set out as many variations as necessary.
 
 
-### Unresolved questions and risks (optional)
+## Unresolved questions and risks (optional)
 
 > What parts of the design are still TBD?
 
 ****
+
+
+## Results
+
+> If we are developing a hypothesis and defining success metrics,
+> we need to log them here.
+> If metrics leave room to interpretation, define them.
+> (e.g. when are they tracked, how, etc)
+> Include screenshots of result graphs or data tables.
+> These results will likely help us develop new hypotheses!
+
+## Conclusion
+
+> Was our hypothesis true or false and why?
+> Our hypothesis was true because we observed... [e.g. a 15% increase in account signup completions].
+
+> We should also address secondary metrics here:
+> We also observed during this test that…  [e.g. we had an increase in single device signups]
+
+## Next Steps
+
+> There no point having a conclusion if you don’t have take-aways with next steps.
+> Are we releasing? Are we making changes?
+

features/TEMPLATE_CLEAN.md

@@ -2,7 +2,6 @@
 
 ## Problem Summary
 
-
 ### Assumptions (optional)
 
 ****
@@ -17,7 +16,19 @@
 
 ## Detailed design
 
+### Original Version (Present Day)
 
-### Unresolved questions and risks (optional)
+### Variation A
+
+### Variation B
+
+## Unresolved questions and risks (optional)
 
 ****
+
+
+## Results
+
+## Conclusion
+
+## Next Steps

features/proposed/README.md

@@ -1,9 +0,0 @@
-# Proposed new Features for Firefox Accounts.
-
-This directory contains descriptions for
-proposed new features in Firefox Accounts.
-We have no particular commitment or timeline
-for implementing anything in this directory.
-When we commit to shipping something, it will
-move into the parent directory for easy
-visibility.

features/shipped/README.md

@@ -1,6 +0,0 @@
-# Shipped Features for Firefox Accounts.
-
-This directory contains descriptions of
-new features that were shipped in Firefox Accounts.
-It provides a historical record of what we've shipped
-and why.