Re: [teampractices] Code review before writing new code
On Tue, Jun 9, 2015 at 9:25 AM, James Douglas jdoug...@wikimedia.org wrote: staying focussed on their teams' priorities may in fact contribute to code review queues growing I disagree, unless the team's priority is add to the code review queue. :] I think Arthur's comment was based on the theory that a lot of the code to be reviewed by a team may not be related to work that is not that team's priority. There was a lot of that in the old core team, where they had to review code in a variety of areas, and doing so slowed their coding progress on work directly related to their quarterly goal. If they stayed purely focused on their own priorities, code reviews (of code written by people outside their team) would pile up. Kevin ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] Code review before writing new code
staying focussed on their teams' priorities may in fact contribute to code review queues growing I disagree, unless the team's priority is add to the code review queue. :] If the priority is ship feature X so that user Y can do Z, then the acts of writing code and opening a code review compose only a portion of the work necessary to complete the priority. To focus on the priority here includes getting the code review done, releasing, and deploying the code, and perhaps even gathering user feedback, depending on the scope of the feature. On Mon, Jun 8, 2015 at 11:45 AM, Arthur Richards aricha...@wikimedia.org wrote: On Mon, Jun 8, 2015 at 9:25 AM, James Douglas jdoug...@wikimedia.org wrote: A team should review their open patchsets before writing new code. +1, this is a great way to remind ourselves to focus on priorities. While in principle I agree with this notion, I don't think this solves the problem of Our code review queues keep growing, or gets us closer to resolving the underlying issues. I would even go as far as to say that for many of the WMF engineering teams, staying focussed on their teams' priorities may in fact contribute to code review queues growing - especially for repositories that have no clear ownership or are for projects that do not rank near the top of the WMF's or a given team's priorities. It's cool to see a ranking of repositories in Korma which ranks repos by oldest median age of unreviewed changesets. I clicked through the first 100 of those repos and with only a few exceptions that I'm aware of, those repositories do not have owners on WMF engineering teams. Is there a way to see which repositories have the largest and/or fastest growing unreviewed queue of changesets? I would guess that the biggest issues around lack of code review happen in repos that have no clear/current ownership or are in repos owned by someone in the WMF but in a project that may be low organizational priority relative to other things they/their team is working on. But it's just a guess - seeing that kind of data might help us get a better understanding of the problem. -- Arthur Richards Team Practices Manager [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] Code review before writing new code
On Tue, Jun 9, 2015 at 1:10 PM, James Douglas jdoug...@wikimedia.org 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 teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] Code review before writing new code
It might unnecessarily complicate matters to draw this kind of distinction between community-written code and organization-written code. We have the capacity to make new features available to the user, whether through code we write ourselves, code that comes in from the community, or code that results from a collaboration of both. Through a balance of cost (e.g. implementation, maintenance, support) and benefit (i.e. utility to the user), we can come up with the relative priority of any set of features, independently of the motivation of any work in progress. It's certainly possible that such motivation factors into the weight of benefit, and we can simply adjust the priority accordingly. This prioritization then makes it trivial to decide between reviewing (or fixing, testing, deploying, etc.) feature Foo vs. coding up feature Bar. On Tue, Jun 9, 2015 at 11:40 AM, Dan Garry dga...@wikimedia.org wrote: On 9 June 2015 at 09:44, James Douglas jdoug...@wikimedia.org wrote: Wouldn't that a misprioritization? In a literal sense, yes. However, as the curators and owners of an open source project, we have a responsibility to review code contributed by our volunteers, and as volunteers they have the freedom to work on whatever they choose. I'm not sure there's a golden bullet answer to this, except that it's about finding the right balance between our responsibilities. Dan -- Dan Garry Product Manager, Discovery Wikimedia Foundation ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] Code review before writing new code
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 ksm...@wikimedia.org wrote: On Tue, Jun 9, 2015 at 1:10 PM, James Douglas jdoug...@wikimedia.org 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 teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
Re: [teampractices] Code review before writing new code
On Tue, Jun 9, 2015 at 1:55 PM, Kevin Smith ksm...@wikimedia.org wrote: On Tue, Jun 9, 2015 at 1:10 PM, James Douglas jdoug...@wikimedia.org 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. What Kevin said :) Thanks Kevin! -- Arthur Richards Team Practices Manager [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ teampractices mailing list teampractices@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/teampractices
