*Storyboard - Basic concepts and next steps
*Session proposed by Thierry Carrez
*Tuesday November  5, 2013  4:40pm -  5:20pm

Storyboard is a Django/Bootstrap-based  proof-of-concept replacement for task tracking throughout the OpenStack  projects. We currently use Launchpad to track those but we are facing a  number of limitations, especially in the blueprints side. Writing our  own lets us design a system that is closely integrated with other  OpenStack infrastructure bits, and precisely matches our development  processes and workflow.

The POC currently only contains basic  concepts and features and there is a lot of work to do before we can  fully replace Launchpad with it. We need a lot more people working on  this if we want it to become a reality soon.

This session will  introduce the basic concepts behind StoryBoard, map the road ahead and  serve to identify interested contributors.

See https://github.com/openstack-infra/storyboard for more.

--------------------------------------------------------------------------------------------------------------------------

The goal
	* Scope
		* Task tracking (things to do, affected projects/branches, implementation status for each)
		* Cross-project and cross-branch stories (can be bugs, can be features)
		* Milestone / Release cycle planning (targeting) and reference (fixed bugs, implemented features)
	* 
		* Could move off-scope
			* Tarball download hosting (link to tarballs.o.o)
	* Why dump Launchpad
		* Small differences in workflow and roles creating major pains at the scale we are now operating
		* Launchpad is not meant to be run by others: Inability to modify LP to suit our needs, difficult to run our own
		* Features (blueprints) completely crippled (no discussion, useless task tracking, no multi-project features)
		* Inability to have multiple tasks targeted to the same project/branch
		* Useless project grouping (a project can only belong to one project group)
		* Timeouts handling bugs with lots of tasks
		* No future: no new features, limited maintenance
	* Why not use X instead
		* No alternative provided the concept of a cross-project/cross-branch story with multiple tasks. At best we had "related bugs"
		* OpenStack needs are arguably unique
	* Additional benefits
		* Run release tasks as one DB operation rather than thousands of API calls taking hours to complete
		* Possible strong 1:1 task/change relationship

The current state
	* A POC
		* Rather than describing what I wanted, why not start coding it
		* The choice of Django and Bootstrap
	* Current features
		* Basic project pages, including workflow oriented "triage bugs" view
		* Basic bug/feature task tracking
		* Project groups
		* Markdown discussions and history of changes in stories
	* Questionable choices
		* Priority is set for the whole story
		* No invalid/wontfix/opinion status -> we could still use a wontfix status
	* Early, major architectural changes ?
		* Need to keep it Python and simple so that most of our devs can easily fix it

The next steps
	* Missing features/gaps
		* High (Dogfooding ability)
			* Form client-side validation
			* Story/task search
			* Story/task list pagination, ordering
			* Attachments
			* Per-project branches and milestones
			* DB stability / switch to a migration model
		* Medium (Launchpad parity)
			* Private stories (embargoed vulnerabilities)
			* Privileged actions, roles
			* Development cycle tracking (milestone/release pages)
			* Subscription to task/stories
			* Official tags
			* Email notifications (?)
			* Story dependencies (?)
			* Admin panel for creating series/milestones/projects
			* XSS security pass
			* REST JSON API
			* Release tasks support
			* Data import
		* Low (extra features)
			* Task ordering
			* "My" project group
			* Periodic tasks
			* Stats on project pages
			* Image upload / comments (for UX folks) - dogfooding 2
			* Track FFE workflow in feature stories
	* Should we try to achieve 1:1 task/change relationship, and how ? yes
	* Dogfooding storyboard
		* Database is still changing a LOT, migrations not really an option at this point
		* 
	* Icehouse plans

 Venue for discussion?
   IRC channels?  Wait until there is enough traffic
   Weekly meeting? once there is a team
   Workshop / Bootcamp to bootstrap a team?
REST API?