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
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
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
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
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:
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
