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 <jdlrob...@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 >>> <bmansu...@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 >>> > <jhernan...@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 < >>> bmansu...@wikimedia.org> >>> > 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 >>> > >>> >>> >>> >>> -- >>> 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
