launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Wed, Jan 26, 2011 at 8:43 PM, Robert Collins
<robert.collins@xxxxxxxxxxxxx> wrote:
> So, a LEP contains a few things by the time its implemented:
>  - goals
>  - constraints
>  - design decisions
>  - UI mockups
>  - discussion
>
> Once we land a patch, some of that stuff becomes irrelevant, some
> becomes 'what if' material, and some stays relevant : the goals and
> constraints are part of our system forever more.
>
> Right now we tend to abandon a LEP that has been implemented; from an
> IRC discussion today about LEP/FeatureFlags Francis and I are
> wondering if after a LEP is implemented we:
>  - strip the stuff obsoleted by the implementation
>  - remove the stuff that is redundant with whats live
>  - garden / mark clearly / remove 'what if' material
>  - preserve *and update* goals/constraints on the LEP
>
> that we'd get some more value from them. specifically we'd have the
> ability to say  'hey, whoa' when coming to a implemented LEP and
> making a change inconsistent with its original constraints/goals.
>
> What do you all think?

It would be nice if the requirements, goals, constraints and user
stories could be found easily when working again on that area of
Launchpad. Also, it would be good to somehow highlight nice-to-haves
that didn't get implemented.

The "could be found easily" bit is tricky to manage, though, partly
because there's just so much stuff. The feature list[1] is the Product
team's first pass at addressing this problem, and might be a good
place to start.

I'm very reluctant to make a policy or a process around this. We don't
really know what we're doing, and we have only the vaguest idea of
what we want. Let's just try stuff for a while longer.

Obsolete and never-to-be-implemented LEPs should be killed with great killing.

jml

[1] http://dev.launchpad.net/FeatureChecklist