[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
On Jun 29, 2015, at 8:34 AM, Joaquin Oltra Hernandez jhernandez@wikimedia.org wrote:
I've mapped the proposed workflow: https://i.imgur.com/Wu7crcB.png https://i.imgur.com/Wu7crcB.png
TLDR ^
Any feedback folks?
I've been talking to the tech lead and we're considering adopting this and adapting as we go along for improvements we could make.
Cheers
On Mon, Jun 29, 2015 at 8:14 PM, Bahodir Mansurov bmansurov@wikimedia.org wrote:
On Jun 29, 2015, at 8:34 AM, Joaquin Oltra Hernandez < jhernandez@wikimedia.org> wrote:
I've mapped the proposed workflow: https://i.imgur.com/Wu7crcB.png
TLDR ^
It looks good to me. Thanks for the hard work, Joaquin.
On Jun 30, 2015, at 2:56 PM, Joaquin Oltra Hernandez jhernandez@wikimedia.org wrote:
Any feedback folks?
I've been talking to the tech lead and we're considering adopting this and adapting as we go along for improvements we could make.
Cheers
On Mon, Jun 29, 2015 at 8:14 PM, Bahodir Mansurov <bmansurov@wikimedia.org mailto:bmansurov@wikimedia.org> wrote: On Jun 29, 2015, at 8:34 AM, Joaquin Oltra Hernandez <jhernandez@wikimedia.org mailto:jhernandez@wikimedia.org> wrote:
I've mapped the proposed workflow: https://i.imgur.com/Wu7crcB.png https://i.imgur.com/Wu7crcB.png
TLDR ^
Hi Joaquin I'm still not 100% sure how the query will work for us but I'm all for trying this out.
A few caveats to be aware of: * Anyone can edit the priority field. I don't know of any cases of someone switching from some kind of priority to 'needs triage' ever happens though so this shouldn't be a problem. * Some tasks may get lost when they are not filed against an extension. eg. Adding a card in a sprint but not with the associated extension https://phabricator.wikimedia.org/maniphest/query/gdeZ0Re2Ekmh/#R OR Tasks in reading web but not in the extension pages https://phabricator.wikimedia.org/maniphest/query/BuWVMgcwb1kM/#R (but I think we can train ourselves to avoid that) I certainly do the former a lot, since I spend most of my time in the sprint board. Setting up herald rules [1] for each sprint board seems rather expensive and a pain but is one solution.
In terms of epics, on the reading web board, I'd love to see us use though's more often and use only the 'must have', 'could have', 'should have' for those tasks. Any subtasks I'd love to file them in a 'Sub task' column on the basis that it makes the board less noisy and keeps us focused. Any bugs should either be put in a sprint project or left on the extension (we can triage them separately there using the MobileFrontend workboard)
[1] https://www.mediawiki.org/wiki/Topic:Sh94hyx5vqslwf8n
On Tue, Jun 30, 2015 at 1:00 PM, Bahodir Mansurov bmansurov@wikimedia.org wrote:
It looks good to me. Thanks for the hard work, Joaquin.
On Jun 30, 2015, at 2:56 PM, Joaquin Oltra Hernandez jhernandez@wikimedia.org wrote:
Any feedback folks?
I've been talking to the tech lead and we're considering adopting this and adapting as we go along for improvements we could make.
Cheers
On Mon, Jun 29, 2015 at 8:14 PM, Bahodir Mansurov bmansurov@wikimedia.org wrote:
On Jun 29, 2015, at 8:34 AM, Joaquin Oltra Hernandez jhernandez@wikimedia.org wrote:
I've mapped the proposed workflow: https://i.imgur.com/Wu7crcB.png
TLDR ^
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
I thought we had come to a different conclusion: that we would continue with the existing system for a sprint cycle for you to see how the system works before you change it. Maybe I am misunderstanding.
I said *considering adopting* and no dates, which is compatible with what we talked about 😄.
If I'm not misunderstanding, please remember Kristen is a stakeholder on this and it impacts how she does her job, so any changes really do need her buy-in.
I've contacted KL and asked her for further thoughts, so that we can keep the conversation rolling. She's always on my mind 😜
---
Seriously though, there aren't any super-radical changes or anything crazy. Just clearly stablishing the workflow and trying to do our jobs the best we can.
The biggest philosophical change would be having mobile's product backlog on mobile frontend and gather's product backlog on Gather, which we've already done in the past and worked fine.
On Tue, Jun 30, 2015 at 10:49 PM, Jon Robson jdlrobson@gmail.com wrote:
Hi Joaquin I'm still not 100% sure how the query will work for us but I'm all for trying this out.
A few caveats to be aware of:
- Anyone can edit the priority field. I don't know of any cases of
someone switching from some kind of priority to 'needs triage' ever happens though so this shouldn't be a problem.
- Some tasks may get lost when they are not filed against an extension.
eg. Adding a card in a sprint but not with the associated extension https://phabricator.wikimedia.org/maniphest/query/gdeZ0Re2Ekmh/#R OR Tasks in reading web but not in the extension pages https://phabricator.wikimedia.org/maniphest/query/BuWVMgcwb1kM/#R (but I think we can train ourselves to avoid that) I certainly do the former a lot, since I spend most of my time in the sprint board. Setting up herald rules [1] for each sprint board seems rather expensive and a pain but is one solution.
In terms of epics, on the reading web board, I'd love to see us use though's more often and use only the 'must have', 'could have', 'should have' for those tasks. Any subtasks I'd love to file them in a 'Sub task' column on the basis that it makes the board less noisy and keeps us focused. Any bugs should either be put in a sprint project or left on the extension (we can triage them separately there using the MobileFrontend workboard)
[1] https://www.mediawiki.org/wiki/Topic:Sh94hyx5vqslwf8n
On Tue, Jun 30, 2015 at 1:00 PM, Bahodir Mansurov bmansurov@wikimedia.org wrote:
It looks good to me. Thanks for the hard work, Joaquin.
On Jun 30, 2015, at 2:56 PM, Joaquin Oltra Hernandez jhernandez@wikimedia.org wrote:
Any feedback folks?
I've been talking to the tech lead and we're considering adopting this
and
adapting as we go along for improvements we could make.
Cheers
On Mon, Jun 29, 2015 at 8:14 PM, Bahodir Mansurov <
bmansurov@wikimedia.org>
wrote:
On Jun 29, 2015, at 8:34 AM, Joaquin Oltra Hernandez jhernandez@wikimedia.org wrote:
I've mapped the proposed workflow: https://i.imgur.com/Wu7crcB.png
TLDR ^
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Jon Robson
Regarding Jon's caveats (responses inline):
* Anyone can edit the priority field. I don't know of any cases of
someone switching from some kind of priority to 'needs triage' ever happens though so this shouldn't be a problem.
That's true for everything we do because everything is public. Most intervention I see from external stakeholders is commenting, adding related projects and occasionally editing description and title (which of those, the edit is usually good).
The good things we get by making priority field a part of our workflow are:
- Phab integration: Querys, batch edits, colors on cards. - Integration with the rest of the organization (which to my understanding use priorities heavily). - Any changes by anybody are logged in the task. You can see who did what.
All these are things we don't have with *only columns and sorting columns*. Well we get column changes logged in the task, but we don't get *sort order* changes logged in the card, which is what worries me the most.
Anybody can change the sort order of the columns and nothing is logged. There is no way to see if a task was not important but it is now. Or the reverse.
To me *only* relying in column sort order is just damaging to our process. A combo of priority and column sort would seem ideal to me.
* Some tasks may get lost when they are not filed against an extension.
eg. Adding a card in a sprint but not with the associated extension https://phabricator.wikimedia.org/maniphest/query/gdeZ0Re2Ekmh/#R OR Tasks in reading web but not in the extension pages https://phabricator.wikimedia.org/maniphest/query/BuWVMgcwb1kM/#R (but I think we can train ourselves to avoid that)
If I'm correct this is a problem we already have, and we don't have a clear workflow for it.
My proposal is having clear rules of where tasks are (in the software project they belong) and stay vigilant in just *current sprint* and *overview board* to move to needs triage+software project any tasks that pop in there.
In any case with, what we are doing now, we should probably set strict rules about what get's added into the sprint and where to report bugs, since we don't have any agreement now.
---
Keep your minds open, I'm not actually proposing any huge changes, and these "flows" should bring us closer to how the rest of the organization works (if I'm not totally mistaken).
On Wed, Jul 1, 2015 at 1:08 PM, Joaquin Oltra Hernandez < jhernandez@wikimedia.org> wrote:
I thought we had come to a different conclusion: that we would continue
with the existing system for a sprint cycle for you to see how the system works before you change it. Maybe I am misunderstanding.
I said *considering adopting* and no dates, which is compatible with what we talked about [image: 😄].
If I'm not misunderstanding, please remember Kristen is a stakeholder on this and it impacts how she does her job, so any changes really do need her buy-in.
I've contacted KL and asked her for further thoughts, so that we can keep the conversation rolling. She's always on my mind [image: 😜]
Seriously though, there aren't any super-radical changes or anything crazy. Just clearly stablishing the workflow and trying to do our jobs the best we can.
The biggest philosophical change would be having mobile's product backlog on mobile frontend and gather's product backlog on Gather, which we've already done in the past and worked fine.
On Tue, Jun 30, 2015 at 10:49 PM, Jon Robson jdlrobson@gmail.com wrote:
Hi Joaquin I'm still not 100% sure how the query will work for us but I'm all for trying this out.
A few caveats to be aware of:
- Anyone can edit the priority field. I don't know of any cases of
someone switching from some kind of priority to 'needs triage' ever happens though so this shouldn't be a problem.
- Some tasks may get lost when they are not filed against an extension.
eg. Adding a card in a sprint but not with the associated extension https://phabricator.wikimedia.org/maniphest/query/gdeZ0Re2Ekmh/#R OR Tasks in reading web but not in the extension pages https://phabricator.wikimedia.org/maniphest/query/BuWVMgcwb1kM/#R (but I think we can train ourselves to avoid that) I certainly do the former a lot, since I spend most of my time in the sprint board. Setting up herald rules [1] for each sprint board seems rather expensive and a pain but is one solution.
In terms of epics, on the reading web board, I'd love to see us use though's more often and use only the 'must have', 'could have', 'should have' for those tasks. Any subtasks I'd love to file them in a 'Sub task' column on the basis that it makes the board less noisy and keeps us focused. Any bugs should either be put in a sprint project or left on the extension (we can triage them separately there using the MobileFrontend workboard)
[1] https://www.mediawiki.org/wiki/Topic:Sh94hyx5vqslwf8n
On Tue, Jun 30, 2015 at 1:00 PM, Bahodir Mansurov bmansurov@wikimedia.org wrote:
It looks good to me. Thanks for the hard work, Joaquin.
On Jun 30, 2015, at 2:56 PM, Joaquin Oltra Hernandez jhernandez@wikimedia.org wrote:
Any feedback folks?
I've been talking to the tech lead and we're considering adopting this
and
adapting as we go along for improvements we could make.
Cheers
On Mon, Jun 29, 2015 at 8:14 PM, Bahodir Mansurov <
bmansurov@wikimedia.org>
wrote:
On Jun 29, 2015, at 8:34 AM, Joaquin Oltra Hernandez jhernandez@wikimedia.org wrote:
I've mapped the proposed workflow: https://i.imgur.com/Wu7crcB.png
TLDR ^
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Jon Robson
And here's a "stop, laugh, relax" break email:
https://media1.giphy.com/media/u75DtEmmyS0fK/200.gif
https://media0.giphy.com/media/sYHOVHt74OWas/200.gif
On Wed, Jul 1, 2015 at 1:20 PM, Joaquin Oltra Hernandez < jhernandez@wikimedia.org> wrote:
Regarding Jon's caveats (responses inline):
- Anyone can edit the priority field. I don't know of any cases of
someone switching from some kind of priority to 'needs triage' ever happens though so this shouldn't be a problem.
That's true for everything we do because everything is public. Most intervention I see from external stakeholders is commenting, adding related projects and occasionally editing description and title (which of those, the edit is usually good).
The good things we get by making priority field a part of our workflow are:
- Phab integration: Querys, batch edits, colors on cards.
- Integration with the rest of the organization (which to my
understanding use priorities heavily).
- Any changes by anybody are logged in the task. You can see who did
what.
All these are things we don't have with *only columns and sorting columns*. Well we get column changes logged in the task, but we don't get *sort order* changes logged in the card, which is what worries me the most.
Anybody can change the sort order of the columns and nothing is logged. There is no way to see if a task was not important but it is now. Or the reverse.
To me *only* relying in column sort order is just damaging to our process. A combo of priority and column sort would seem ideal to me.
- Some tasks may get lost when they are not filed against an extension.
eg. Adding a card in a sprint but not with the associated extension https://phabricator.wikimedia.org/maniphest/query/gdeZ0Re2Ekmh/#R OR Tasks in reading web but not in the extension pages https://phabricator.wikimedia.org/maniphest/query/BuWVMgcwb1kM/#R (but I think we can train ourselves to avoid that)
If I'm correct this is a problem we already have, and we don't have a clear workflow for it.
My proposal is having clear rules of where tasks are (in the software project they belong) and stay vigilant in just *current sprint* and *overview board* to move to needs triage+software project any tasks that pop in there.
In any case with, what we are doing now, we should probably set strict rules about what get's added into the sprint and where to report bugs, since we don't have any agreement now.
Keep your minds open, I'm not actually proposing any huge changes, and these "flows" should bring us closer to how the rest of the organization works (if I'm not totally mistaken).
On Wed, Jul 1, 2015 at 1:08 PM, Joaquin Oltra Hernandez < jhernandez@wikimedia.org> wrote:
I thought we had come to a different conclusion: that we would continue
with the existing system for a sprint cycle for you to see how the system works before you change it. Maybe I am misunderstanding.
I said *considering adopting* and no dates, which is compatible with what we talked about [image: 😄].
If I'm not misunderstanding, please remember Kristen is a stakeholder on this and it impacts how she does her job, so any changes really do need her buy-in.
I've contacted KL and asked her for further thoughts, so that we can keep the conversation rolling. She's always on my mind [image: 😜]
Seriously though, there aren't any super-radical changes or anything crazy. Just clearly stablishing the workflow and trying to do our jobs the best we can.
The biggest philosophical change would be having mobile's product backlog on mobile frontend and gather's product backlog on Gather, which we've already done in the past and worked fine.
On Tue, Jun 30, 2015 at 10:49 PM, Jon Robson jdlrobson@gmail.com wrote:
Hi Joaquin I'm still not 100% sure how the query will work for us but I'm all for trying this out.
A few caveats to be aware of:
- Anyone can edit the priority field. I don't know of any cases of
someone switching from some kind of priority to 'needs triage' ever happens though so this shouldn't be a problem.
- Some tasks may get lost when they are not filed against an extension.
eg. Adding a card in a sprint but not with the associated extension https://phabricator.wikimedia.org/maniphest/query/gdeZ0Re2Ekmh/#R OR Tasks in reading web but not in the extension pages https://phabricator.wikimedia.org/maniphest/query/BuWVMgcwb1kM/#R (but I think we can train ourselves to avoid that) I certainly do the former a lot, since I spend most of my time in the sprint board. Setting up herald rules [1] for each sprint board seems rather expensive and a pain but is one solution.
In terms of epics, on the reading web board, I'd love to see us use though's more often and use only the 'must have', 'could have', 'should have' for those tasks. Any subtasks I'd love to file them in a 'Sub task' column on the basis that it makes the board less noisy and keeps us focused. Any bugs should either be put in a sprint project or left on the extension (we can triage them separately there using the MobileFrontend workboard)
[1] https://www.mediawiki.org/wiki/Topic:Sh94hyx5vqslwf8n
On Tue, Jun 30, 2015 at 1:00 PM, Bahodir Mansurov bmansurov@wikimedia.org wrote:
It looks good to me. Thanks for the hard work, Joaquin.
On Jun 30, 2015, at 2:56 PM, Joaquin Oltra Hernandez jhernandez@wikimedia.org wrote:
Any feedback folks?
I've been talking to the tech lead and we're considering adopting this
and
adapting as we go along for improvements we could make.
Cheers
On Mon, Jun 29, 2015 at 8:14 PM, Bahodir Mansurov <
bmansurov@wikimedia.org>
wrote:
On Jun 29, 2015, at 8:34 AM, Joaquin Oltra Hernandez jhernandez@wikimedia.org wrote:
I've mapped the proposed workflow: https://i.imgur.com/Wu7crcB.png
TLDR ^
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Jon Robson
I don't have a ton of direct feedback on this except that the documentation is great. I still need to go ask people about where to find things and I can imagine if I'm confused, other people, particularly in the community are confused as well.
It's hard to balance the needs of developers with being transparent and easily understood; the docs are a good start.
-Toby
On Wed, Jul 1, 2015 at 4:24 AM, Joaquin Oltra Hernandez < jhernandez@wikimedia.org> wrote:
And here's a "stop, laugh, relax" break email:
https://media1.giphy.com/media/u75DtEmmyS0fK/200.gif
https://media0.giphy.com/media/sYHOVHt74OWas/200.gif
On Wed, Jul 1, 2015 at 1:20 PM, Joaquin Oltra Hernandez < jhernandez@wikimedia.org> wrote:
Regarding Jon's caveats (responses inline):
- Anyone can edit the priority field. I don't know of any cases of
someone switching from some kind of priority to 'needs triage' ever happens though so this shouldn't be a problem.
That's true for everything we do because everything is public. Most intervention I see from external stakeholders is commenting, adding related projects and occasionally editing description and title (which of those, the edit is usually good).
The good things we get by making priority field a part of our workflow are:
- Phab integration: Querys, batch edits, colors on cards.
- Integration with the rest of the organization (which to my
understanding use priorities heavily).
- Any changes by anybody are logged in the task. You can see who did
what.
All these are things we don't have with *only columns and sorting columns*. Well we get column changes logged in the task, but we don't get *sort order* changes logged in the card, which is what worries me the most.
Anybody can change the sort order of the columns and nothing is logged. There is no way to see if a task was not important but it is now. Or the reverse.
To me *only* relying in column sort order is just damaging to our process. A combo of priority and column sort would seem ideal to me.
- Some tasks may get lost when they are not filed against an extension.
eg. Adding a card in a sprint but not with the associated extension https://phabricator.wikimedia.org/maniphest/query/gdeZ0Re2Ekmh/#R OR Tasks in reading web but not in the extension pages https://phabricator.wikimedia.org/maniphest/query/BuWVMgcwb1kM/#R (but I think we can train ourselves to avoid that)
If I'm correct this is a problem we already have, and we don't have a clear workflow for it.
My proposal is having clear rules of where tasks are (in the software project they belong) and stay vigilant in just *current sprint* and *overview board* to move to needs triage+software project any tasks that pop in there.
In any case with, what we are doing now, we should probably set strict rules about what get's added into the sprint and where to report bugs, since we don't have any agreement now.
Keep your minds open, I'm not actually proposing any huge changes, and these "flows" should bring us closer to how the rest of the organization works (if I'm not totally mistaken).
On Wed, Jul 1, 2015 at 1:08 PM, Joaquin Oltra Hernandez < jhernandez@wikimedia.org> wrote:
I thought we had come to a different conclusion: that we would continue
with the existing system for a sprint cycle for you to see how the system works before you change it. Maybe I am misunderstanding.
I said *considering adopting* and no dates, which is compatible with what we talked about [image: 😄].
If I'm not misunderstanding, please remember Kristen is a stakeholder on this and it impacts how she does her job, so any changes really do need her buy-in.
I've contacted KL and asked her for further thoughts, so that we can keep the conversation rolling. She's always on my mind [image: 😜]
Seriously though, there aren't any super-radical changes or anything crazy. Just clearly stablishing the workflow and trying to do our jobs the best we can.
The biggest philosophical change would be having mobile's product backlog on mobile frontend and gather's product backlog on Gather, which we've already done in the past and worked fine.
On Tue, Jun 30, 2015 at 10:49 PM, Jon Robson jdlrobson@gmail.com wrote:
Hi Joaquin I'm still not 100% sure how the query will work for us but I'm all for trying this out.
A few caveats to be aware of:
- Anyone can edit the priority field. I don't know of any cases of
someone switching from some kind of priority to 'needs triage' ever happens though so this shouldn't be a problem.
- Some tasks may get lost when they are not filed against an extension.
eg. Adding a card in a sprint but not with the associated extension https://phabricator.wikimedia.org/maniphest/query/gdeZ0Re2Ekmh/#R OR Tasks in reading web but not in the extension pages https://phabricator.wikimedia.org/maniphest/query/BuWVMgcwb1kM/#R (but I think we can train ourselves to avoid that) I certainly do the former a lot, since I spend most of my time in the sprint board. Setting up herald rules [1] for each sprint board seems rather expensive and a pain but is one solution.
In terms of epics, on the reading web board, I'd love to see us use though's more often and use only the 'must have', 'could have', 'should have' for those tasks. Any subtasks I'd love to file them in a 'Sub task' column on the basis that it makes the board less noisy and keeps us focused. Any bugs should either be put in a sprint project or left on the extension (we can triage them separately there using the MobileFrontend workboard)
[1] https://www.mediawiki.org/wiki/Topic:Sh94hyx5vqslwf8n
On Tue, Jun 30, 2015 at 1:00 PM, Bahodir Mansurov bmansurov@wikimedia.org wrote:
It looks good to me. Thanks for the hard work, Joaquin.
On Jun 30, 2015, at 2:56 PM, Joaquin Oltra Hernandez jhernandez@wikimedia.org wrote:
Any feedback folks?
I've been talking to the tech lead and we're considering adopting
this and
adapting as we go along for improvements we could make.
Cheers
On Mon, Jun 29, 2015 at 8:14 PM, Bahodir Mansurov <
bmansurov@wikimedia.org>
wrote:
On Jun 29, 2015, at 8:34 AM, Joaquin Oltra Hernandez jhernandez@wikimedia.org wrote:
I've mapped the proposed workflow: https://i.imgur.com/Wu7crcB.png
TLDR ^
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Jon Robson
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
