Template Blueprint
This is a blueprint to provide a template for future blueprints. All of the below fields should be populated before a blueprint can be approved. "N/A" is an acceptable answer where applicable.
Summary
=======
A couple of sentences summarizing the goal of this blueprint.
Motivation
========
This field should contain the reason the change is desirable in Horizon and why it should be considered for implementation.
Description
=========
This field should contain a detailed description of the feature to be added.
UX
===
This should contain discussion of the UX implications of the change. If the UX discussion already has a design proposal, a link should be inserted here. If the discussion is ongoing it can take place in the whiteboard area.
Wireframes, Mocks, Videos and UI Markup
-------
Links to any visual assets that describe the changes.
Discussion of use cases and actors is encouraged where applicable.
Testing
======
Brief instruction for reviewers to exercise the changes, including expected results where non-obvious.
Outside Dependencies
==================
Is this functionality already supported in other services? List the appropriate API calls and if they are extensions or base API functionality.
This should describe any cross project dependencies. This should include:
* changes to OpenStack services
* changes to OpenStack services clients (python-*client)
* changes in external projects
Links to particular patches should be included in the whiteboard area.
Requirements Update Required
=======
This field should indicate any changes to openstack/
Doc Impact
=========
This should describe any changes to Horizon documentation that will be required. This could include:
* settings file changes that will be required
* changes to default behaviors
* any deprecation or obsolescence notices
Blueprint information
- Status:
- Complete
- Approver:
- David Lyle
- Priority:
- Essential
- Drafter:
- David Lyle
- Direction:
- Needs approval
- Assignee:
- David Lyle
- Definition:
- Approved
- Series goal:
- Accepted for trunk
- Implementation:
-
Informational
- Milestone target:
-
ongoing
- Started by
- David Lyle
- Completed by
- David Lyle
Related branches
Related bugs
Sprints
Whiteboard
I think "Summary" and "Detailed description of the feature" sound like 2 different things. Maybe the summary should be a 1-3 sentence summary of the function and should be first, then a new section should be added after Motivation called "Detailed Description" where panels affected/new panels and the related API calls should be described with more detail.
I agree with the statement above. In addition, where applicable (larger changes/ flows) should we require UX team sign off when UI is impacted. It could be a sub item of UX section.
[david-lyle] Added
[tqtran 10-14-2014] Should also mention that a wireframes are desirable where applicable. A picture is worth a thousand words right?
[david-lyle] Added
[akrivoka 2014-10-17] This is really great - thanks for drafting this up! I think it will make a huge improvement on our development process! One thing I would add is a section labeled 'Design', in which the implementation design of the proposed solution should be described.
[icordasc 2014-10-17] Along a similar vein to tqtran & akrivoka's suggestions, perhaps add a section for images pointing out exactly where the proposed changes would effect. An example of this would be a screen capture of horizon as it is now with arrows or other diagrams to show exactly the desired impact of a change on at least one affected page.
[david-lyle] Added
[peristeri 2014-10-20] I would like to suggest a additional step called "Functional Test"
where we describe how the blueprint can be tested.
[david-lyle] Added Testing
[jpichon 2014.10.30] We might need an "API support?" field or making it clearer where that info should fit - probably under "Outside dependencies"? Adding "Is this feature already supported by existing APIs? Otherwise <same as is now>".
[david-lyle] Added note about existing API support
I think the "Testing" field aims to describe how to test this already, peristeri, or perhaps the description can be expanded to include this.
[david-lyle] I already addressed this based on peristeri's comment, but forgot to update the whiteboard.
Also I think encouraging ReST-style-like headers would help making the blueprints more readable and the different sections more distinct (e.g.:
Testing
====
etc)
[david-lyle] Updated
[julim 2014.11.07] It would be good if the blueprints includes user stories that include the user or persona, their motivation, and acceptance criteria -- ideally from the user's perspective. For the user / persona, please refer to the personas listed at https:/
