[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
_______________________________________________ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
