Thank you for this discussion! I have updated the description of https://phabricator.wikimedia.org/T101686 based on the feedback received, and will continue to do so.
I'm thinking of morphing this proposal into a WMF committed goal: *The code review queue must stop growing and start decreasing* Then each team and each individual would be free to take the approaches that fit best with their workflows. Meanwhile, Team Practices and Community Engineering could work on recommendations, activities, and metrics supporting that goal, and product managers and line should be onboard when planning new goals and sprints. So far we have identified several problems (listed in T101686). As we dig into the problems, we will identify specific problems and hopefully their specific remedies. Does this sound better? I have proposed in T101099: Engineering Community Roadmap <https://phabricator.wikimedia.org/T101099> a sequence of goals to solve the code review time wait problem in the next 12 months. T88531: Goal: Organize a Gerrit Cleanup Day <https://phabricator.wikimedia.org/T88531> would be the first step (awareness and official kick-off of the discussion), followed by changing the trend (queue stops growing), cleaning up, and committing to some kind of service-level agreement. I (or @Aklapper <https://phabricator.wikimedia.org/p/Aklapper/>, or whoever is faster) will create specific tasks to discuss these goals as soon as we have enough feedback supporting this direction. On Wed, Jun 10, 2015 at 10:41 AM, Gilles Dubuc <[email protected]> wrote: > I think this is a cultural problem, which means that it will be difficult > to solve by forcibly pushing people towards a specific way of fixing it. > It's not a staff vs volunteer nor an active project vs abandoned project > issue. Other open source projects with worse staff to volunteers ratios > don't have that problem. We have to change the conditions and the landscape > to produce a long-lasting cultural shift. > > The way I try to contribute at my own little scale is to always aim to > review more changesets than I produce. If everybody did that, the issue > would go away, right? And it doesn't have to be tied to a specific > workflow, like reviewing before writing, etc. which wouldn't fit everybody > and wouldn't even fit me every day. It doesn't matter how you organize your > schedule as long as at the end of the week/month/year you've reviewed more > changes than you've asked others to review. > > Maybe that specific way of seeing things (am I in review debt?) could be > supported by software. I.e. a prominent indicator of whether or not you've > pushed more changesets than you've reviewed. It might be something to > consider once we move code reviews to phabricator. Moving away from gerrit > should be a priority, in fact, as the increased ease of use and integration > of our review tool could have an impact on those figures. > > On Wed, Jun 10, 2015 at 2:00 AM, James Douglas <[email protected]> > wrote: > >> > Exactly. And thus a team prioritizing Bar might continue coding on >> Bar, allowing the queue of pending Foo code reviews to pile up. >> >> Bingo! >> >> On Tue, Jun 9, 2015 at 1:55 PM, Kevin Smith <[email protected]> wrote: >> >>> >>> On Tue, Jun 9, 2015 at 1:10 PM, James Douglas <[email protected]> >>> wrote: >>> >>>> This prioritization then makes it trivial to decide between reviewing >>>> (or fixing, testing, deploying, etc.) feature Foo vs. coding up feature >>>> Bar. >>>> >>>> >>> Exactly. And thus a team prioritizing Bar might continue coding on Bar, >>> allowing the queue of pending Foo code reviews to pile up. >>> >>> Kevin >>> >>> >>> _______________________________________________ >>> teampractices mailing list >>> [email protected] >>> https://lists.wikimedia.org/mailman/listinfo/teampractices >>> >>> >> >> _______________________________________________ >> teampractices mailing list >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/teampractices >> >> > > _______________________________________________ > teampractices mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/teampractices > > -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil
_______________________________________________ teampractices mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/teampractices
