Proposed Features for Launchpad Bugs 3.0 - call for help!

[Jonathan Marsden]

Jordan Mantha wrote:

> For us Launchpad is a *critical* tool
> to our work, so in a lot of respects we're more interesting with
> existing feature working well than adding new features. I'm personally
> be more interested in getting Launchpad to do the basics/fundamentals
> (uploading, bugs, speed) correctly before adding any new features.

I'm just a newcomer to the world of Ubuntu development and Launchpad, 
but I agree 100%.  When 'ordinary' pages in LP say things like:

  at least 77 queries issued in 7.48 seconds

(that was for https://bugs.launchpad.net/ubuntu a few moments ago) there 
would seem to be a *significant* performance issue. Yet improving 
performance seemingly did not even appear on the list of proposed 
features for 3.0 at all.  Why not?  Are there currently any stated 
(public) performance goals for LP?  How does LP currently measure up to 
those goals, if they do exist?  The existence of the "at least X queries 
in Y seconds" comment suggests that at some stage, performance was 
considered worth measuring... I submit that it remains very much worth 
measuring, and improving.

Perhaps "No commonly used LP Bugs page should take more than 3 seconds 
to be delivered to the user, on the official Ubuntu instantiation of LP" 
would be a starting point?  Maybe something like "No more than 20 
database queries per page" wouldn't hurt, either?  These are clear, 
simple, and measurable goals.  Meeting these two goals would, in my 
view, do more for most MOTUs than implementing twenty of the proposed 
features on the list!

Yes, the current UI may well have some issues, or be a source of 
contention.  Yes, there may well be more features that would be handy to 
have, that are not yet implemented.  But surely, a reliable, performant 
and consistent LP would be *far* more valuable than an unreliable, slow, 
and rapidly changing tool, for many LP users.  Re-ordering a long list 
of proposed new LP features will not change this at all.

> The second thing I think needs to be brought up is that it seems like
> we're being consulted at the wrong time and that the feedback is
> acquired at the wrong time. 

Indeed.  Was the question "Should the next release of LP be primarily 
about new features, or about performance, or about bug fixes?" seriously 
addressed early in the development cycle of LP 3.0?  Was input from 
MOTUs and the developer community sought and used at that stage?  Why, 
or why not?  IMO, this is more important than any particular feature or 
list of new features.  If it is too late to address this now, can we 
respectfully ask the LP development community to please consider 
changing their process as a whole, so that it *does* get asked and 
addressed appropriately in the next LP release cycle, and in all future 
LP development cycles?

Jonathan