[Long email, sorry]
Hi friends,
There's been some talk about how we currently phabricate and there doesn't seem
to be much satisfaction in our current workflows, and as part of the new team
we are getting more software artifacts so we are going to have to adapt to this
new situation.
For that, I've mapped how we do things now, and proposed how we could move
forward to effectively avoid more conphusion (sorry 'bout that).
## Current workflows
Reading web currently uses 3 permanent boards + current sprint board.
Reading-web:
* Type: Team project.
* Contains: Epics, bugs, features.
* Board: Columns with should have, could have, etc. Mixed columns. Triaging column.
MobileFrontend:
* Type: Software project.
* Contains: Bugs, tech tasks, features, discussions.
* Board: Backlog.
Gather:
* Type: Team project + Software project (mix between the two above).
* Contains: Epics, bugs, tech tasks, features.
* Board: Columns with should have, could have, etc. Mixed columns. Triaging column.
### Bugs
MobileFrontend bugs are added to MobileFrontend and Reading-web. They get
categorized and triaged in Reading-web by team/standup and brought into the
sprint if appropriate.
Gather bugs are added to Gather & current sprint. Gather is triaged by JonR --
high priority are brought straight into the sprint.
### Features
MobileFrontend/Gather features added to Reading-Web **Needs triage** column.
Have MobileFrontend or Gather project added by TechPro as needed. Moved to
**Must Have**, **Should Have**, or **Could Have** as necessary
### Problems
* Workflow is different for MobileFrontend and Gather.
* Boards have mixed responsibilities.
* No one place to triage bugs and features.
* Reading-Web is *noisey*.
* Tasks with several tags -- leads to noise across all projects.
* No clear high level overview of Reading-Web workload/workflow.
On top of how we are currently working, we are getting a bunch of software
artifacts that we are going to have to triage & maintain really soon. We need
to adapt to deal with multiple projects/boards and maintain team vision of what
we are doing. (Current process probably won't scale well with more than a few
software projects).
## Proposal
Taking into account that we want to:
* Be able to work across multiple phabricator projects for different software
artifacts.
* Maintain a high level overview of team focus through time (so that we all
know what we are focusing on mainly).
* Have a clear place to triage for the projects we are responsible for.
### Solution
#### phStructure
Reading web will use N+2 boards. N+1 permanent boards + current sprint board.
* *N being the number of software projects we maintain*.
Reading-web:
* Type: Team project.
* Contains: Epics.
* Board: Time based columns, left is closer, right is further on time. (Can be
sprint based + Quarter based, or something else)
(Ex: In progress | Next sprint | ...).
MobileFrontend:
* Type: Software project.
* Contains: Bugs, tech tasks, small features, discussions.
* Board: Backlog | Discussion.
Gather:
* Type: Software project.
* Contains: Bugs, tech tasks, small features, discussions.
* Board: Backlog | Discussion.
PageImages:
* Type: Software project.
* Contains: Bugs, tech tasks, small features, discussions.
* Board: Backlog | Discussion.
TextExtracts:
* Type: Software project.
* Contains: Bugs, tech tasks, small features, discussions.
* Board: Backlog | Discussion.
ETC. (same for the rest of the software projects we're getting).
Suggestion is that software projects get the same layout, but not necessary.
#### Phrocess
##### Bugs and pheatures
Such tasks will get submitted against the corresponding software project that
involves them.
If there is a bug on the mobile web, it'll get submitted to MobileFrontend, if
there is a bug with collections, it'll get submitted against Gather. Same for
feature requests. If there is a bug on MobileFrontend & PageImages it'll get
submitted to both.
Default priority *Needs triage* means task hasn't been triaged yet.
Each project has tasks that involve that project. Reading-web stays a high
level view of the team's focuses through time available for everybody.
##### Triaging
We'll have a **saved query** available to everybody to triage (standups or
(note this looks like shit because we don't use priorities at all right now).
When triaging a bug, we'll set it's priority to something that makes sense
regarding severity and add to current sprint project if priority is high.
When triaging a feature, we'll set it's priority to something that makes sense
regarding perceived importance and ping product owner. PO should add as subtask
of epic if makes sense.
##### Sprint preparation. Task creation.
From the epics on Reading-web we'll spin off subtasks of specific work that'll
get tagged with the concrete software project where they need to be acted upon
with a priority.
Sprint grooming and prioritisation will put subtasks of epics in *Next sprint*
into the next sprint board. Also give a pass on work on software artifacts
projects that needs to be added to sprint. Then we'll analyse and estimate.
------
(I've tried with the current workflow but I don't even know how to accurately draw it. Sorry).
---
What do you guys think? Beginning of next quarter is approaching so it would be great if we discussed this and arrived somewhere better than our current workflow.
Thanks!
Joaquin
