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