[sldev] sljirastats.com Linden Metrics Report

[Lawson English]

Rob Lanphier wrote:
> Hi Gigs,
>
> This is great information.  Thanks for compiling it.
>
> A couple of questions/comments below:
>
> On 4/16/08 12:02 PM, Jason Giglio wrote:
>> "Open" bugs have been on a steady climb.  It started at 1547 when
>> sljirastats.com began collecting data, and is now at 2717.   This means
>> we are averaging 8.6 additional unresolved bugs per day.  This is after
>> subtracting fixed and resolved issues.  This number is a critical
>> metric; Linden Lab is falling more and more behind every day.
>>   
>
> How does this compare to other open source and public projects?  My 
> suspicion is that almost every active open source project experiences 
> net positive growth in number of open bugs.  I'd like to make sure 
> we're not being measured against an unreasonably high standard.
>
> We have a resolution internally called "someday maybe", which is one 
> I'm personally not a fan of (since the issue isn't "resolved", just 
> acknowledged as a wart we're going to have to live with for a while).  
> We've recently discussed making a matching PJIRA resolution, and 
> concluded that a) we can't, because we still want to allow votes and 
> b) we'd get a public flogging over it.  The conclusion of that 
> discussion is to represent that as "small" priority, possibly renaming 
> "small" to "someday maybe", or adding a new "someday maybe" priority, 
> and I'm hoping we can actually change our internal usage to match.
>
>> SVC-472 and SVC-85 remain the most hated bugs, for most of the time that
>> sljirastats has existed.
>>   
>
> Hmmm....these are also somewhat subjective without clear victory 
> conditions.  While I'm guessing the team will acknowledge that these 
> aren't yet running at an acceptable baseline, it also strikes me that 
> these both describe symptoms with multiple and ever-changing causes of 
> failure that will probably always be with us in some form from time to 
> time.  For both of these, I think we need to establish a victory 
> condition that causes these issues to be closed and stay closed, to 
> the point where a new issue gets opened if a problem with the same 
> symptom occurs.  Otherwise, these will automatically be at the top of 
> the list every time they get reopened, despite the fact that other 
> issues may actually be more pressing.
>
> What are good victory conditions for these?
>
> Rob
>
I've said it before (and I'm saying it again): the single most important 
thing that can be done to reduce client-bugs in the long-run is to 
refactor the GUI away from the rest of the client code-base.  The GUI 
kinda seeps into everything and it's virtually impossible to change the 
GUI in substantial ways without impacting the rest of the code, and 
whenever you touch most of the non-GUI code, you must take into account 
the interactions of the GUI with that section of code during your 
analysis--even at the highest and lowest levels of the analysis.

It's a mess. And a not-very tasty mess, too.

In other words, if the refactoring of the GUI is done properly, it will 
allow us to establish good victory conditions for almost every other 
issue in the client because many issues will sort themselves out during 
the refactoring or such is my intuition, and even if not, they will 
become more manageable issues automatically.

Lawson