Re: [WikimediaMobile] [reading web] Phabricating in Q1
> > 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
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
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
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] [video club] RailsConf 2015 - Implementing a Strong Code Review Culture
What a great recommendation! Thanks for sharing! --stephen On Mon, Jun 29, 2015 at 10:51 AM, Toby Negrin wrote: > Thanks for posting this Sam -- code review is one of the best parts of our > engineering culture, I'll definitely watch this when I get a chance. > > -Toby > > On Mon, Jun 29, 2015 at 7:59 AM, Sam Smith wrote: > >> Hey y'all, >> >> I watch a lot of talks in my downtime. I even post the ones I like to a >> Tumblr… sometimes [0]. I felt like sharing Derek Prior's "Implementing a >> Strong Code Review Culture" from RailsConf 2015 in particular because it's >> relevant to the conversations that the Reading Web team are having around >> process and quality. You can watch the talk on YouTube [1] and, if you're >> keen, you can read the paper that's referenced over at Microsoft Research >> [2]. >> >> I particularly like the challenge of providing two paragraphs of context >> in a commit message – to introduce the problem and your solution – and >> trying to overcome negativity bias in written communication* by offering >> compliments whenever possible and asking, not telling, while providing >> critical feedback. >> >> I hope you enjoy the talk as much as I did. >> >> –Sam >> >> [0] http://sometalks.tumblr.com/ >> [1] https://www.youtube.com/watch?v=PJjmw9TRB7s >> [2] http://research.microsoft.com/apps/pubs/default.aspx?id=180283 >> >> * The speaker said "research has shown" but I didn't see a citation >> >> *Notes (width added emphasis)* >> >>- Code review isn't for catching bugs >>- "Expectations, Outcomes, and Challenges of Modern Code Review" >>- Chief benefits of code review: >> - Knowledge transfer >> - Increased team awareness >> - Finding alternative solutions >>- Code review is "the discipline of explaining your code to your >>peers" >>- Process is more important than the result >>- Goes on to define code review as "the discipline of discussing your >>code with your peers" >>- If we get better at code review, then we'll get better at >>communicating technically as a team >> >> Rules of Engagement >> >>- As an author, provide context >> >> >>- "If content is king, then context is God" >> - *In a pull request (patch set) the code is the content and the >> commit message is the context* >> - Provide sufficient context - bring the reviewer up to speed with >> what you've been doing in the past X hours >> - *Challenge: provide at least two paragraphs of context in your >> commit message* >> - This additional context lives on in the commit history whereas >> links to issue trackers might not >> >> >>- As a reviewer, ask questions rather than making demands >> - Research has shown that there's a negativity bias in written >> communication. *Offer compliments whenever you can* >> - *When you need to provide critical feedback, ask, don't tell*, >> e.g. "extract a service to reduce some of this duplication" could be >> formulated as "what do you think about extracting a service to reduce >> some >> of this duplication?" >> - "Did you consider?", "can you clarify?" >> - "Why didn't you just..." is framed negatively and includes >> the word just >> - Use the Socratic method: asking and answering questions to >> stimulate critical thinking and to illuminate ideas >> >> Insist on high quality reviews, but agree to disagree >> >>- Conflict is good. *Conflict drives a higher standard of coding >>provided there's healthy debate* >>- Everyone has a minimum bar to entry for quality. Once that bar is >>met, then everything else is a trade-off >>- Reasonable people disagree all the time >>- Review what's important to you >>- SRP (Single Responsibility Principle) (the S from SOLID) >> - Naming >> - Complexity >> - Test Coverage >> - ... (whatever else you're comfortable in giving feedback on) >> >> >>- What about style? >> - Style is important >> - "People who received style comments on their code perceived that >> review negatively" >> - Adopt a styleguide >> >> >> Benefits of a Strong Code Review Culture >> >>- Better code >>- Better developers through constant knowledge transfer >>- Team ownership of code, which leads to fewer silos >>- Healthy debate >> >> >> ___ >> 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 > > ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
