Motivations[edit]

Get things cleaned up
When we are in a sprint kickoff meeting we should be able to view the tickets currently outstanding for a given sub team
The CPT managers should be able to have visibility of the tasks across all of the sub teams
We want to take responsibility for all of the Phabircator projects for which we are stewards
- We want to ensure that we are meeting our obligations to those who have created tasks
We have a backlog of tasks and we don’t have certainty over their current state, we want to resolve this
- Tasks tend to languish in our backlog and we’re not clear whether they are not important or if they have just fallen into the cracks
- We also want to facilitate the creation of the Clinic Duty team
We don’t have a tool process that supports internal and external tasks travelling through our pipeline consistently
- We do not have any metrics that characterise our tasks over time
- We want to enshrine correct terminology usage and application visavis Initiatives, Stories, Epics, Tasks etc
- Product Managers should have a clear means to prioritise and manage their Stories
- Teams should be clearly named
- The sub teams and sub team workboards are tools to help us focus on a certain unit of work that is bounded so it’s clear. All the work an Engineer needs to care about should be contained within their workboard.
Getting to a prioritised list of stuff we can do in order to ameliorate the current situation and support our pipeline and process

Challenges[edit]

We need to examine the consistency of language to be used and implemented so that it is clear to all parties involved in terms of their responsibility/accountability
Need to keep old tasks for context or information or documentation?
- There are some long lived tasks that aren’t closed because you don’t want them to disappear
  - Are these Epics? Are they also nebulous long range ideas or initiatives?
Closing tasks means they are not available in default search, you would have to set an advanced search and include closed
We lack consistency in our use of organisation and naming of existing Tasks, Projects, Initiatives and Epics
Conceptual differences between task to make an RFC and RFC task
- RfC tasks move through the process
- Traditionally, the description of the task is the actual document for the RfC
- The discussion then leads to this discussion being modified
- We should have a tracking task for the RfC task and then separate RfC tasks, could be a parent/sub task
That there are Projects that we aren’t tracking
- Some of these were created to create Tags not initially as Projects to be workboards but many do have workboards
- There could ~200 of these
  - Can we generate this list? Timo sent Cindy a list of ones we should own as a team
    - MediaWiki-Database
    - MediaWiki-Cache
    - MediaWiki-Debug-Logger
    - PoolCounter
    - Wikimedia-log-errors
    - WMF-JobQueue.
    - MediaWiki-Api
    - MediaWiki-Authentication and Authorization
    - MediaWiki-Configuration
    - MediaWiki-ContentHandler
    - MediaWiki-Decoupling
    - MediaWiki-Installer???
    - MediaWiki-General-or-Unknown
    - Also https://phabricator.wikimedia.org/project/view/135/
- https://www.mediawiki.org/wiki/Developers/Maintainers
It is not clear how the forming of sub teams will happen and how this affects how we use workboards whether they are long lived or disposal
There are limits to the way that phabricator to present information, we may be able to use the sm wiki that can be used at the manager level to use for overall planning or for task triage or for overarching views
- Should be used
All of this should be migrated to Wiki
There may be issues around some people squatting certain areas of work and prevent knowledge or ownership transfer

Approaches[edit]

Restructure existing workboards to ensure they adhere to Workboard Process
Group meeting to get through backlog of tickets
Herald rules to tag with CPT on issues that arrive on workboards we’re responsible for
We should keep the tags BUT NOT THE WORKBOARD
For existing Projects 3 columns:
- Inbox
- Not CPT responsibility
- CPT Taking Ownership -> which automatically tags the task with CPT
How can we use Triage meeting effectively?
Using Semantic MW as a tool to
- Help with structure and organising work in/for the Triage meeting
- Help with overarching reviewing of tasks in flight for initiatives

Backlog[edit]

Keep using Attic but rename as appropriate
Move Attic column to CPT Kanban
Close board

Next Steps[edit]

How the triage process should work and how we formulaise that
1. Ready, Doing, Waiting for Review, Blocked Externally
2. Done with CPT requires special attention
Does this task give me joy Meeting
1. Should rotate
2. Should have few people
3. Should be curated by someone
4. Will use Cindy’s SMW
5. Backlog
  1. Backlog ← Pool to draw work for clinic duty
  2. ??? ← Work that we intend to do within X amount of time but haven’t scheduled
  3. Watching/External <- Tasks that affect us in some way but we’re not actively working on
  4. Epic ← Shouldn’t have work associated with them, not actively working them but we might want to have a column on CPT board to show currently active Epics
  5. Icebox ← Can’t close, want to keep, but have no time/resources to do
  6. Mop Column ← Will be used to clear out tasks that are covered by categories already
  7. Email Eric, Petr and Marko and ask them to untag all the services team tasks or tag them with an initiative
Name workboard
1. Come up with a theme for workboard names
Outcome for this week: Get structures set up so that projects are supporting of pipeline and process, that there is fidelity
1. Kanban work board?
2. CPT workboard
  1. Are the columns initiatives?
  2. How are the subtasks associated with Epics, associated with Initiatives?
Metrics
Resolve errors that currently exist in tasks vis a vis categorisation
Close, Categorise or Move Service Team tasks
Define how to integrate other workboards