Mapping Launchpad to StoryBoard
One of the crucial parts of any transition is understanding the differences between your old tools and new tools. It's also worth noting that StoryBoard was built with the knowledge of Launchpad's limitations, and so much of it was engineered to work around those issues. In an effort to help make this migration to StoryBoard easier, we have laid out some of the more widely used features and will discuss the differences between Launchpad and StoryBoard.
For more information on StoryBoard specifically, check out the documentation , wiki, sandbox , and live UI.
Filing Bugs & Planning Features
Launchpad uses a minimalist approach for bug reporting. The submitter is only required to provide a summary description of the issue and then has the option to add other relevant information about the bug, tags, and other attachments before submitting. Bugs also have a status that can be modified throughout the process of triaging, confirming, and resolving. People are able to post comments on the bug as it goes through the process to communicate with other people watching the issue.
Feature planning in Launchpad uses an equally minimalist process for registering a blueprint for a feature request. Blueprints are the classification for the tasks that focus on new features and changes. When creating a blueprint, the submitter need only provide a name (to be used for the url), the title of the feature request, and a summary description of the feature. They can also provide an assignee, drafter, approver, status other than new, and a proposed sprint that the blueprint is targeted for. After the blueprint has been created, it will be approved and work on implementing it can commence. In practice, the 'blueprints' feature is not widely used in this way; instead, the community use 'specs' repositories updated through code review, and tend to use 'blueprints' as hollow pointers to these.
StoryBoard uses same process both for filing bugs and detailing feature requests; a user files a 'story', which can describe either a bug or a feature. A story has a 'description' field, in which a user can give details, 'tags', to help classify the story, for use with filters, and comments, where users can add further information.
A story can also include multiple tasks, which will each be associated with a project (the projects can be the same or different for tasks in the same story). A task is a concrete item of work that should be undertaken in order to complete the story, so has a status (eg: 'in progress', 'review', 'merged'). A story's status is derived from the statuses of its tasks; a story can be 'active' (one or more tasks with the status 'todo', 'in progress' or 'review'), 'merged' (all tasks 'merged') or 'invalid' (no tasks, or all tasks 'invalid').
Stories have unique IDs, as do tasks. If a user notes the story ID in a commit, comments will be left linking to gerrit whenever there are updates in the corresponding review. If a user notes a task ID in a commit, the corresponding task status will automatically update in StoryBoard when the patch first goes up for review, is merged, or is abandoned. You can read more details here  . Using 'stories' for both bug reports and feature requests protects users from long debates on whether something should be classed as an issue report or a feature request.
Launchpad has the ability to set the importance for bugs and series goals for blueprints after they have been created, but only if you have the correct permissions to do so.
In contrast, in StoryBoard, a 'priority' setting is not applied directly to a task. Instead, a user can place a task in a worklist. The task then derives priority, relative to that worklist, from the task's position in that worklist.. This means that a task can be present in multiple worklists, and have different priority relative to each one. Each of these worklists may be used by a different individual or team, and a user can subscribe to any worklist they are interested in. When viewing tasks, the user will then see tasks' priority relative to any subscribed worklists. Stories may also be placed in worklists, so a user may also prioritise stories.
This flexible priority provides multiple views, by allowing different people to state their priority for items, and users to see the priorities of those whose opinions are important to them. As well as visualizing more information, this approach saves time, preventing arguments over a single prioritized list during meetings or in other discussion on IRC. Different groups need not give the same task the same priority. Moreover, people do not need to worry about their priority lists being overwritten by others; it is possible to set ACLs for worklists. This means a project team can have full control over its list of priorities. For more information on relative priority, you can see corresponding workitems and notes here .
Any projects relying on bug importance for classifying priority issues can still achieve a similar effect through consistent use of story tags (as well as the capability to create automatic worklists based on specific tag names).
Milestone targets can be defined for both blueprints and bugs in Launchpad if you have the correct permissions for the task-- a similar situation to setting priorities. In both types of tasks, the targeted milestones are set after the bug or bluperint is created. This is designed to tie release-tracking to bugs and blueprints, but the Release Management team does not use Launchpad's milestone targeting, preferring more feature-rich release-note automation, coupled with leaving comments on bugs. The comments note the releases in which their fixes appear.
In StoryBoard, milestones are not yet developed in detail. The API has some support for milestones, as seen here , but milestones are not yet represented in the webclient, as we await feedback on what the most helpful visual representation would be. This is an area where we would love some guidance and help, so if milestones matter to you, please join our weekly meetings, or come over to #storyboard, to get involved !
In a separate blog post, we discussed the motivation for creating StoryBoard's API in detail , and we will cover the features of the API in detail in future blog posts, but the point is this: StoryBoard's API is ahead of its UI. The API was created to handle situations that revealed limitations in Launchpad. If you'd like a sneak-preview, check out our API documentation  or our DB-schema diagram  (that is circa July 2016, so is a little out-of-date, but conveys the general idea).
We hope this has been informative! In our next blog post, we'll focus more on things that are new in StoryBoard, including more detail on our REST API, worklists and boards. In the meantime, feel free to ask any questions in #storyboard, and happy task-tracking!