launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On Sat, Feb 18, 2012 at 10:09 AM, Deryck Hodge
<deryck.hodge@xxxxxxxxxxxxx> wrote:
> On Fri, Feb 17, 2012 at 1:29 PM, Robert Collins
> <robertc@xxxxxxxxxxxxxxxxx> wrote:
>> There are two major reasons to disable this (irrespective of it being
>> worked on):
>>  - it is at best breakeven for us today, not yet a benefit. reduces
>> dev friction, increases ops friction. Increases dev confusion.
>>  - we are seeing a different Launchpad to our users - and not a
>> difference like our debug tools, but a difference in terms of features
>> and usability.
>
> I just don't think it's that large a price to pay for keeping the
> feature around for us to remind us it exists and needs polish. Keeping
> it enabled is a better signal IMHO, a commitment to fixing it and
> releasing it, rather than hiding it away by disabling it.  This is the
> beauty of feature flags to me, and I think we devs can tolerate some
> minor pain if it means we end up with a better feature in the end.

Francis and I will figure something out :) As already acked elsewhere
in the thread, I'm happy with the flag being on while you finish the
combo work: it helps you guys, and that is important.

I spent the weekend mulling about this, and I think the heart of it is
a LEAN sentiment. A general theme in LEAN is that we want  to keep WIP
limits low to avoid stockpiling, queueing, context switching (and the
higher average time-to-complete that this drives). This piece of work
is de facto WIP as it stands, but it is not on anyones board. Other
bits of WIP that we decide to take off of boards I would expect us to
disable rather than leaving part on. Imagine, for instance, if we had
stopped work on bug columns after getting 90% of it done: would we
have left it on for just us?

-Rob