Re: [WikimediaMobile] [reading web] Phabricating in Q1

[Toby Negrin]

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 <
jhernan...@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 <
> jhernan...@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 <
>> jhernan...@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 
>>> 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
>

Re: [WikimediaMobile] [reading web] Phabricating in Q1

[Joaquin Oltra Hernandez]

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 <
jhernan...@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 <
> jhernan...@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  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', 

Re: [WikimediaMobile] [reading web] Phabricating in Q1

[Joaquin Oltra Hernandez]

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 <
jhernan...@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  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:Sh94hyx5vqslw

Re: [WikimediaMobile] [reading web] Phabricating in Q1

[Joaquin Oltra Hernandez]

>
> 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  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
>  wrote:
> > It looks good to me. Thanks for the hard work, Joaquin.
> >
> > On Jun 30, 2015, at 2:56 PM, Joaquin Oltra Hernandez
> >  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 <
> bmansu...@wikimedia.org>
> > wrote:
> >>
> >> On Jun 29, 2015, at 8:34 AM, Joaquin Oltra Hernandez
> >>  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
> * http://jonrobson.me.uk
> * https://www.facebook.com/jonrobson
> * @rakugojon
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [reading web] Phabricating in Q1

[Jon Robson]

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
 wrote:
> It looks good to me. Thanks for the hard work, Joaquin.
>
> On Jun 30, 2015, at 2:56 PM, Joaquin Oltra Hernandez
>  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 
> wrote:
>>
>> On Jun 29, 2015, at 8:34 AM, Joaquin Oltra Hernandez
>>  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
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [reading web] Phabricating in Q1

[Bahodir Mansurov]

It looks good to me. Thanks for the hard work, Joaquin.

> On Jun 30, 2015, at 2:56 PM, Joaquin Oltra Hernandez 
>  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  > wrote:
> On Jun 29, 2015, at 8:34 AM, Joaquin Oltra Hernandez 
> mailto:jhernan...@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

Re: [WikimediaMobile] [reading web] Phabricating in Q1

[Joaquin Oltra Hernandez]

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 
wrote:

> On Jun 29, 2015, at 8:34 AM, Joaquin Oltra Hernandez <
> jhernan...@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

Re: [WikimediaMobile] [reading web] Phabricating in Q1

[Bahodir Mansurov]

On Jun 29, 2015, at 8:34 AM, Joaquin Oltra Hernandez  
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

[WikimediaMobile] [reading web] Phabricating in Q1

[Joaquin Oltra Hernandez]

[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 groomin