How to request a feature
Features provide value to the end user, allowing them to do or accomplish something that wasn't previously possible. This includes improvements to and expansions of existing features, and isn't necessarily limited to the UI.
To request a feature, include the following information:
-
User story - A user story is a short description of and end user's need. User stories help guide conversation that leads to extracting business and technical requirements and eliminating hidden assumptions. Use this simple template:
As a [specific user/persona/role] I want [desired feature/issue that needs to be solved], so that [benefit from implementing the feature].
Each of these elements is important and has a role in expressing and understanding the captured requirement. For examples and more information about what makes a good user story check out these articles:
-
Acceptance criteria - Acceptance criteria complement the narrative: they allow you to describe the conditions that have to be fulfilled so that the story is done. The criteria enrich the story, they make it testable, and they ensure the story can be demoed or released to users.
-
Mock-up or design collateral - If the feature involves a change to the UI that's visible to the user, design should be consulted or involved. Read more about how to request a design story.
-
Be sure to apply the label "feature" to your issue when you submit it:
An example of a helpful feature request:
As a user composing a story
I want to see the edges of my StoryFrame when I set it
In order to understand what viewers see when they play my MapStory
Acceptance Criteria
- The StoryFrame maintains the same aspect ratio, even when resized
- The user can access and use zoom buttons while setting the StoryFrame
- The edges of the StoryFrame are always visible, and cannot be resized exceed the user's browser width or height
[mock-up from design]