[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
else). Example:
https://phabricator.wikimedia.org/maniphest/query/c_ZQlOwVk9I8/
(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 mapped the proposed workflow:
https://i.imgur.com/Wu7crcB.png
(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
