Re: [REPORT] Issue Clearance Quality + Technical Debt

[Andreas Säger]

Technical Debt in AOO 4.1.2:
1. The entire Base component does not work on the Mac platform. Not a
Java issue, not limited to any type of database. Serial letters and
bibliographies are impossible to do on the Mac. On the user forum this
issue comes up more than once a week. Going back to AOO 4.1.1 is one
solution. Most users prefer LibreOffice in this situation.
2. Spreadsheet functions IFERR and IFNA are part of the ODF formula
specification and not yet implemented. This comes up more than once a
week because nobody uses IF(ISERROR(foo);bar;foo). Today's users of
Excel, LibreOffice and Gnumeric use IFERROR(foo;bar).

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [REPORT] Issue Clearance Quality + Technical Debt

[Rob Weir]

On Sun, Jan 17, 2016 at 11:17 AM, Dennis E. Hamilton  wrote:
> FYI, the searches I've done for unresolved issues excludes all issues that 
> have been identified as duplicates and those having any form of resolution, 
> including being closed.  It does not distinguish between unresolved extension 
> requests and defect reports, and between unresolved confirmed and unconfirmed 
> incident reports.
>

The point, of course, is that we once make deliberate efforts to
identify duplicates, support questions, etc., and mark them
accordingly, an effort that is not occurring to the same degree today.
So your numbers are conflating this difference in BZ processing with a
difference in the product quality, which is inaccurate and unfair.

-Rob


> Agreed, finer-grained analysis can provide some clarity on this, and it will 
> be interesting how much noise happens to be removed.
>
> Of course, technical debt can be more than known and uncorrected bugs in the 
> code.  It has more forms and symptoms, some of which are reflected in bug 
> reports of a different nature.
>
> For those playing along at home, what I have relied on in my use of the 
> *metaphorical* term, "technical debt":
>
>  Martin Fowler.  Technical Debt Quadrant.  Web site article, 2009-10-14.  
> Available at
>  <http://martinfowler.com/bliki/TechnicalDebtQuadrant.html>
>  and the earlier paper linked there.
>
> I use the open bugs as an indicator of technical debt.  Whether it is a very 
> good one or not is a different matter.  It strikes me that digging deeper is 
> the avenue to clarity on that.
>
> What we have here is evidence that there is something being accrued and that 
> needs to be dug into.  We can worry about what best to call it when we know 
> more about what it is.
>
> My concern is that it is a debt that our users and the supporters of the 
> user-facing lists are paying the interest on [;<).
>
>  - Dennis
>
>> -Original Message-
>> From: Rob Weir [mailto:r...@robweir.com]
>> Sent: Sunday, January 17, 2016 06:29
>> To: dev@openoffice.apache.org;  
>> Subject: Re: [REPORT] Issue Clearance Quality + Technical Debt
>>
>> On Fri, Jan 15, 2016 at 2:22 PM, Dennis E. Hamilton 
>> wrote:
>> > [BCC to Project Management Committee and users@ oo.a.o]
>> >
>> > SUMMARY
>> >
>> > The top-level analysis of Bugzilla issue handling has been completed
>> for all issues opened on the project through December 31, 2015.
>> >
>> > The complete tabulation is in the PDF document at
>> <http://s.apache.org/YFT>.
>> >
>> > It remains the case that since the establishment of Apache OpenOffice
>> as an ASF Top Level Project in November, 2012, the accrual of unresolved
>> issues exceeds 40%.  That is, for every 100 new issues, on the average
>> more than 40 of them will be unresolved indefinitely.
>> >
>> > In contrast, although there is a very large number of unresolved
>> issues that remain in the Bugzilla from its history as part of
>> OpenOffice.org, that previous technical debt was, proportionally, under
>> 20%.
>> >
>>
>> It is entirely unfounded to equate unresolved "issues" in Bugzilla
>> with "technical debt." When I was "leading" a group of QA volunteers a
>> few years ago to resolve BZ issues it was clear that only a small
>> percentage of them were actual reports of new bugs in the product.  A
>> very small fraction.  Most of them fit into other categories:
>>
>> 1) Questions on how to use to product, or misunderstandings about how
>> the product worked.
>>
>> 2) General system-wide issues and user was reaching out to us for free
>> computer technical support.
>>
>> 3) Redundant reports of already known bugs or already requested
>> enhancements,
>>
>> 4) Vague reports which could not be reproduced and which the original
>> submitter was unresponsive to requests for clarification.
>>
>> At that time we reduced these numbers by quite a bit.  But note that
>> this was done without changing a single line of code.  It was a paper
>> exercise of reducing the of open BZ issues only.   If closing BZ
>> issues in these categories does not magically improve product quality,
>> hopefully you can see how not closing such issues (due to less
>> organization in the QA activity) does not magically decrease product
>> quality, or technical debt for that matter.
>>
>> Anyone familiar with the discipline of SQE understands that the
>> meaningful comparison can only be done after triaging issues,
>> eliminating those that

RE: [REPORT] Issue Clearance Quality + Technical Debt

[Dennis E. Hamilton]

FYI, the searches I've done for unresolved issues excludes all issues that have 
been identified as duplicates and those having any form of resolution, 
including being closed.  It does not distinguish between unresolved extension 
requests and defect reports, and between unresolved confirmed and unconfirmed 
incident reports.  

Agreed, finer-grained analysis can provide some clarity on this, and it will be 
interesting how much noise happens to be removed.

Of course, technical debt can be more than known and uncorrected bugs in the 
code.  It has more forms and symptoms, some of which are reflected in bug 
reports of a different nature.  

For those playing along at home, what I have relied on in my use of the 
*metaphorical* term, "technical debt": 

 Martin Fowler.  Technical Debt Quadrant.  Web site article, 2009-10-14.  
Available at
 <http://martinfowler.com/bliki/TechnicalDebtQuadrant.html> 
 and the earlier paper linked there.

I use the open bugs as an indicator of technical debt.  Whether it is a very 
good one or not is a different matter.  It strikes me that digging deeper is 
the avenue to clarity on that.  

What we have here is evidence that there is something being accrued and that 
needs to be dug into.  We can worry about what best to call it when we know 
more about what it is.  

My concern is that it is a debt that our users and the supporters of the 
user-facing lists are paying the interest on [;<).

 - Dennis

> -Original Message-
> From: Rob Weir [mailto:r...@robweir.com]
> Sent: Sunday, January 17, 2016 06:29
> To: dev@openoffice.apache.org;  
> Subject: Re: [REPORT] Issue Clearance Quality + Technical Debt
> 
> On Fri, Jan 15, 2016 at 2:22 PM, Dennis E. Hamilton 
> wrote:
> > [BCC to Project Management Committee and users@ oo.a.o]
> >
> > SUMMARY
> >
> > The top-level analysis of Bugzilla issue handling has been completed
> for all issues opened on the project through December 31, 2015.
> >
> > The complete tabulation is in the PDF document at
> <http://s.apache.org/YFT>.
> >
> > It remains the case that since the establishment of Apache OpenOffice
> as an ASF Top Level Project in November, 2012, the accrual of unresolved
> issues exceeds 40%.  That is, for every 100 new issues, on the average
> more than 40 of them will be unresolved indefinitely.
> >
> > In contrast, although there is a very large number of unresolved
> issues that remain in the Bugzilla from its history as part of
> OpenOffice.org, that previous technical debt was, proportionally, under
> 20%.
> >
> 
> It is entirely unfounded to equate unresolved "issues" in Bugzilla
> with "technical debt." When I was "leading" a group of QA volunteers a
> few years ago to resolve BZ issues it was clear that only a small
> percentage of them were actual reports of new bugs in the product.  A
> very small fraction.  Most of them fit into other categories:
> 
> 1) Questions on how to use to product, or misunderstandings about how
> the product worked.
> 
> 2) General system-wide issues and user was reaching out to us for free
> computer technical support.
> 
> 3) Redundant reports of already known bugs or already requested
> enhancements,
> 
> 4) Vague reports which could not be reproduced and which the original
> submitter was unresponsive to requests for clarification.
> 
> At that time we reduced these numbers by quite a bit.  But note that
> this was done without changing a single line of code.  It was a paper
> exercise of reducing the of open BZ issues only.   If closing BZ
> issues in these categories does not magically improve product quality,
> hopefully you can see how not closing such issues (due to less
> organization in the QA activity) does not magically decrease product
> quality, or technical debt for that matter.
> 
> Anyone familiar with the discipline of SQE understands that the
> meaningful comparison can only be done after triaging issues,
> eliminating those that are not reporting bugs, deduplicating bug
> reports and attempting to confirm them.   That might indicate
> "technical debt".  But what you're reporting is not that, but "bug
> triaging debt" if you feel the need to give it a label.  This
> distinction is important.
> 
> Regards,
> 
> -Rob
> 
> 
> 
> > Some highlights:
> >
> >  * Even though the monthly rate of new issues and comments on issues
> has been decreasing significantly since mid-2014, the rate of technical
> debt as the proportion of unresolved issues has not improved.
> >
> >  * Although a reduction to 35% unresolved-issue is seen in the last 5
> months of 2015, this may be distorted by issues created and then

Re: [REPORT] Issue Clearance Quality + Technical Debt

[donaldupre .]

On Sat, Jan 16, 2016 at 8:22 PM, Dennis E. Hamilton 
wrote:

>
> [orcmid]
>
> I don't know.  I haven't looked for such information and I am not aware of
> any form it might be available in.
>
> Considering how different projects can be, I am not certain what lessons
> might transfer from one to another.
>
> Do you envision how having such information would be helpful in assessing
> the effectiveness of this project's handling of reported issues and how
> that is reflected in improvements to the product?
>
> The industry averages of the various parameters can serve us as quality
objectives.

>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: [REPORT] Issue Clearance Quality + Technical Debt

[Rob Weir]

On Fri, Jan 15, 2016 at 2:22 PM, Dennis E. Hamilton  wrote:
> [BCC to Project Management Committee and users@ oo.a.o]
>
> SUMMARY
>
> The top-level analysis of Bugzilla issue handling has been completed for all 
> issues opened on the project through December 31, 2015.
>
> The complete tabulation is in the PDF document at .
>
> It remains the case that since the establishment of Apache OpenOffice as an 
> ASF Top Level Project in November, 2012, the accrual of unresolved issues 
> exceeds 40%.  That is, for every 100 new issues, on the average more than 40 
> of them will be unresolved indefinitely.
>
> In contrast, although there is a very large number of unresolved issues that 
> remain in the Bugzilla from its history as part of OpenOffice.org, that 
> previous technical debt was, proportionally, under 20%.
>

It is entirely unfounded to equate unresolved "issues" in Bugzilla
with "technical debt." When I was "leading" a group of QA volunteers a
few years ago to resolve BZ issues it was clear that only a small
percentage of them were actual reports of new bugs in the product.  A
very small fraction.  Most of them fit into other categories:

1) Questions on how to use to product, or misunderstandings about how
the product worked.

2) General system-wide issues and user was reaching out to us for free
computer technical support.

3) Redundant reports of already known bugs or already requested enhancements,

4) Vague reports which could not be reproduced and which the original
submitter was unresponsive to requests for clarification.

At that time we reduced these numbers by quite a bit.  But note that
this was done without changing a single line of code.  It was a paper
exercise of reducing the of open BZ issues only.   If closing BZ
issues in these categories does not magically improve product quality,
hopefully you can see how not closing such issues (due to less
organization in the QA activity) does not magically decrease product
quality, or technical debt for that matter.

Anyone familiar with the discipline of SQE understands that the
meaningful comparison can only be done after triaging issues,
eliminating those that are not reporting bugs, deduplicating bug
reports and attempting to confirm them.   That might indicate
"technical debt".  But what you're reporting is not that, but "bug
triaging debt" if you feel the need to give it a label.  This
distinction is important.

Regards,

-Rob



> Some highlights:
>
>  * Even though the monthly rate of new issues and comments on issues has been 
> decreasing significantly since mid-2014, the rate of technical debt as the 
> proportion of unresolved issues has not improved.
>
>  * Although a reduction to 35% unresolved-issue is seen in the last 5 months 
> of 2015, this may be distorted by issues created and then resolved in the 
> staging of AOO 4.1.2 release candidates and QA on the candidates.  Results 
> for the first-quarter of 2016 are needed to determine if this is a new trend 
> or a hiccup.
>
> DETAIL AND QUALITY MATTERS
>
> This is a rough analysis, although the consistent trend is difficult to 
> explain away.
>
> Refinement requires a closer look at the nature of issues and understanding 
> of exactly what resolution means, not just what being left unresolved means.
>
> There is also a suspected disconnect with regard to what is considered an 
> issue and how the ways of closing an issue are actually applied.
>
>  * Closing of a new issue as a duplicate qualifies as a resolution.  The 
> incidence of long-standing issues that continue to receive duplicate reports 
> is useful to understand in this case, and that requires more detail.
>
>  * Some issues are closed as Resolved Fixed when the fact of the matter is 
> that there was insufficient detail to understand and confirm the issue and 
> the reporting party failed to provide additional information (if it was even 
> requested).
>
>  * Some comments on issues tailgate possibly-different problems onto known 
> ones, although the resemblance may be superficial and the issues need to be 
> split.
>
>  * Enhancement/feature requests are not distinguished.
>
>  * Resolved issues are sometimes closed without obtaining confirmation that 
> incorporation of the identified resolution in distributed code actually 
> addresses the originally-reported difficulty.
>
>  * Some issue reports are closed as not issues because they are declared user 
> problems and kicked to the Community Forum.
>
> These may all have small effects.  We will know only by looking more closely 
> into Bugzilla details.
>
> The last case deserves more careful attention.
>
> The next-in-line users of Apache OpenOffice distributions consist of around 
> 50 million users who are mainly individuals and 87% of whom are using 
> Microsoft Windows.  Such casual users, whatever their limited experience in 
> trouble-shooting and describing problems, are the main users of this 
> software.  The usability issues th

Re: [REPORT] Issue Clearance Quality + Technical Debt

[Dave Fisher]

In line

Sent from my iPhone

> On Jan 16, 2016, at 10:22 AM, Dennis E. Hamilton  wrote:
> 
> 
> 
>> -Original Message-
>> From: donaldupre . [mailto:donaldu...@gmail.com]
>> Sent: Saturday, January 16, 2016 04:51
>> To: dev@openoffice.apache.org; orc...@apache.org
>> Subject: Re: [REPORT] Issue Clearance Quality + Technical Debt
>> 
>> Very interesting, thank you.
>> Perhaps the reduced activity is an indication for the saturation state
>> of
>> the project (i.e. all the possible bugs and features already exist in
>> Bugzilla)?
> [orcmid] 
> 
> That's an interesting idea.  
> 
> I don't know how to test that with the data that we have.  

I concur with the idea. That the saturation point has to do with overall 
activity level. When the level of Contribution dropped after November 2014 
technical debt accelerated. Compare the overall commit / bugzilla resolution 
levels with number of contributors multiplied by the average size of the 
contribution.


> 
> 
>> Is it possible to compare this information with other office suites?
> [orcmid] 
> 
> I don't know.  I haven't looked for such information and I am not aware of 
> any form it might be available in.  
> 
> Considering how different projects can be, I am not certain what lessons 
> might transfer from one to another.  
> 
> Do you envision how having such information would be helpful in assessing the 
> effectiveness of this project's handling of reported issues and how that is 
> reflected in improvements to the product?

An interesting comparison might include counting the the size of contributions 
of those who are paid by their day job to work on the project. A count of 
students and retirees would be interesting metrics as well.

Strict development comparisons are only fair to a point. For example the forums 
are hosted by the ASF and the volunteers and community answer all questions 
about any part of the OpenOffice / ODF ecosystem.

Regards,
Dave

> 
> 
>> On Fri, Jan 15, 2016 at 9:22 PM, Dennis E. Hamilton 
>> wrote:
>> 
>>> [BCC to Project Management Committee and users@ oo.a.o]
>>> 
>>> SUMMARY
>>> 
>>> The top-level analysis of Bugzilla issue handling has been completed
>> for
>>> all issues opened on the project through December 31, 2015.
>>> 
>>> The complete tabulation is in the PDF document at
>> <http://s.apache.org/YFT
>>>> .
> [ ... ]
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: [REPORT] Issue Clearance Quality + Technical Debt

[Dennis E. Hamilton]

> -Original Message-
> From: donaldupre . [mailto:donaldu...@gmail.com]
> Sent: Saturday, January 16, 2016 04:51
> To: dev@openoffice.apache.org; orc...@apache.org
> Subject: Re: [REPORT] Issue Clearance Quality + Technical Debt
> 
> Very interesting, thank you.
> Perhaps the reduced activity is an indication for the saturation state
> of
> the project (i.e. all the possible bugs and features already exist in
> Bugzilla)?
[orcmid] 

That's an interesting idea.  

I don't know how to test that with the data that we have.  


> Is it possible to compare this information with other office suites?
> 
[orcmid] 

I don't know.  I haven't looked for such information and I am not aware of any 
form it might be available in.  

Considering how different projects can be, I am not certain what lessons might 
transfer from one to another.  

Do you envision how having such information would be helpful in assessing the 
effectiveness of this project's handling of reported issues and how that is 
reflected in improvements to the product?


> On Fri, Jan 15, 2016 at 9:22 PM, Dennis E. Hamilton 
> wrote:
> 
> > [BCC to Project Management Committee and users@ oo.a.o]
> >
> > SUMMARY
> >
> > The top-level analysis of Bugzilla issue handling has been completed
> for
> > all issues opened on the project through December 31, 2015.
> >
> > The complete tabulation is in the PDF document at
> <http://s.apache.org/YFT
> > >.
> >
[ ... ]


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [REPORT] Issue Clearance Quality + Technical Debt

[donaldupre .]

Very interesting, thank you.
Perhaps the reduced activity is an indication for the saturation state of
the project (i.e. all the possible bugs and features already exist in
Bugzilla)?
Is it possible to compare this information with other office suites?

On Fri, Jan 15, 2016 at 9:22 PM, Dennis E. Hamilton 
wrote:

> [BCC to Project Management Committee and users@ oo.a.o]
>
> SUMMARY
>
> The top-level analysis of Bugzilla issue handling has been completed for
> all issues opened on the project through December 31, 2015.
>
> The complete tabulation is in the PDF document at  >.
>
> It remains the case that since the establishment of Apache OpenOffice as
> an ASF Top Level Project in November, 2012, the accrual of unresolved
> issues exceeds 40%.  That is, for every 100 new issues, on the average more
> than 40 of them will be unresolved indefinitely.
>
> In contrast, although there is a very large number of unresolved issues
> that remain in the Bugzilla from its history as part of OpenOffice.org,
> that previous technical debt was, proportionally, under 20%.
>
> Some highlights:
>
>  * Even though the monthly rate of new issues and comments on issues has
> been decreasing significantly since mid-2014, the rate of technical debt as
> the proportion of unresolved issues has not improved.
>
>  * Although a reduction to 35% unresolved-issue is seen in the last 5
> months of 2015, this may be distorted by issues created and then resolved
> in the staging of AOO 4.1.2 release candidates and QA on the candidates.
> Results for the first-quarter of 2016 are needed to determine if this is a
> new trend or a hiccup.
>
> DETAIL AND QUALITY MATTERS
>
> This is a rough analysis, although the consistent trend is difficult to
> explain away.
>
> Refinement requires a closer look at the nature of issues and
> understanding of exactly what resolution means, not just what being left
> unresolved means.
>
> There is also a suspected disconnect with regard to what is considered an
> issue and how the ways of closing an issue are actually applied.
>
>  * Closing of a new issue as a duplicate qualifies as a resolution.  The
> incidence of long-standing issues that continue to receive duplicate
> reports is useful to understand in this case, and that requires more detail.
>
>  * Some issues are closed as Resolved Fixed when the fact of the matter is
> that there was insufficient detail to understand and confirm the issue and
> the reporting party failed to provide additional information (if it was
> even requested).
>
>  * Some comments on issues tailgate possibly-different problems onto known
> ones, although the resemblance may be superficial and the issues need to be
> split.
>
>  * Enhancement/feature requests are not distinguished.
>
>  * Resolved issues are sometimes closed without obtaining confirmation
> that incorporation of the identified resolution in distributed code
> actually addresses the originally-reported difficulty.
>
>  * Some issue reports are closed as not issues because they are declared
> user problems and kicked to the Community Forum.
>
> These may all have small effects.  We will know only by looking more
> closely into Bugzilla details.
>
> The last case deserves more careful attention.
>
> The next-in-line users of Apache OpenOffice distributions consist of
> around 50 million users who are mainly individuals and 87% of whom are
> using Microsoft Windows.  Such casual users, whatever their limited
> experience in trouble-shooting and describing problems, are the main users
> of this software.  The usability issues they encounter are important to the
> project; even though they may not involve bugs in the code, they point to
> defects in the product.  Capturing those experiences and recognizing them
> as real issues for the user community is important.  That feedback is
> important for determining and making available workarounds and advice.  It
> can also inform changes to the software that might ameliorate those
> difficulties for non-experts.  Here's a simple example: having an
> easy-to-use option for resetting the user profile.
>
> FUTURE STEPS
>
> Along with extending the current analysis into the first quarter of 2016,
> exploration of the nature of unresolved and resolved issues will be
> introduced.
>
>
>  - Dennis
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

[REPORT] Issue Clearance Quality + Technical Debt

[Dennis E. Hamilton]

[BCC to Project Management Committee and users@ oo.a.o]

SUMMARY

The top-level analysis of Bugzilla issue handling has been completed for all 
issues opened on the project through December 31, 2015.  

The complete tabulation is in the PDF document at .

It remains the case that since the establishment of Apache OpenOffice as an ASF 
Top Level Project in November, 2012, the accrual of unresolved issues exceeds 
40%.  That is, for every 100 new issues, on the average more than 40 of them 
will be unresolved indefinitely.  

In contrast, although there is a very large number of unresolved issues that 
remain in the Bugzilla from its history as part of OpenOffice.org, that 
previous technical debt was, proportionally, under 20%.  

Some highlights:

 * Even though the monthly rate of new issues and comments on issues has been 
decreasing significantly since mid-2014, the rate of technical debt as the 
proportion of unresolved issues has not improved.  

 * Although a reduction to 35% unresolved-issue is seen in the last 5 months of 
2015, this may be distorted by issues created and then resolved in the staging 
of AOO 4.1.2 release candidates and QA on the candidates.  Results for the 
first-quarter of 2016 are needed to determine if this is a new trend or a 
hiccup.

DETAIL AND QUALITY MATTERS

This is a rough analysis, although the consistent trend is difficult to explain 
away.  

Refinement requires a closer look at the nature of issues and understanding of 
exactly what resolution means, not just what being left unresolved means.  

There is also a suspected disconnect with regard to what is considered an issue 
and how the ways of closing an issue are actually applied.  

 * Closing of a new issue as a duplicate qualifies as a resolution.  The 
incidence of long-standing issues that continue to receive duplicate reports is 
useful to understand in this case, and that requires more detail.

 * Some issues are closed as Resolved Fixed when the fact of the matter is that 
there was insufficient detail to understand and confirm the issue and the 
reporting party failed to provide additional information (if it was even 
requested).

 * Some comments on issues tailgate possibly-different problems onto known 
ones, although the resemblance may be superficial and the issues need to be 
split.

 * Enhancement/feature requests are not distinguished.

 * Resolved issues are sometimes closed without obtaining confirmation that 
incorporation of the identified resolution in distributed code actually 
addresses the originally-reported difficulty.

 * Some issue reports are closed as not issues because they are declared user 
problems and kicked to the Community Forum.

These may all have small effects.  We will know only by looking more closely 
into Bugzilla details.

The last case deserves more careful attention.  

The next-in-line users of Apache OpenOffice distributions consist of around 50 
million users who are mainly individuals and 87% of whom are using Microsoft 
Windows.  Such casual users, whatever their limited experience in 
trouble-shooting and describing problems, are the main users of this software.  
The usability issues they encounter are important to the project; even though 
they may not involve bugs in the code, they point to defects in the product.  
Capturing those experiences and recognizing them as real issues for the user 
community is important.  That feedback is important for determining and making 
available workarounds and advice.  It can also inform changes to the software 
that might ameliorate those difficulties for non-experts.  Here's a simple 
example: having an easy-to-use option for resetting the user profile.

FUTURE STEPS

Along with extending the current analysis into the first quarter of 2016, 
exploration of the nature of unresolved and resolved issues will be introduced.


 - Dennis




> -Original Message-
> From: Dennis E. Hamilton [mailto:orc...@apache.org]
> Sent: Wednesday, September 9, 2015 11:33
> To: dev@openoffice.apache.org
> Subject: FW: [DISCUSS] SUSTAINABILITY: Issue Clearance Quality +
> Technical Debt
> 
> 
> From the Chair,
> 
> From "A Maturity Model for Apache Projects,"
>  model.html>
> 
> "QU50: The project strives to respond to documented bug reports
>in a timely manner."
> 
> It is also a recommended practice to acknowledge receipt of reports
> within some minimum time period, sometimes 24 hours, certainly not more
> than 72 hours.
> 
> This note discusses crude estimation of the technical debt that the
> project is accruing in terms of unresolved issues in the Bugzilla
> system.  It is important to appreciate the statistics as warning
> indicators.  It is necessary to look deeper for better understanding.
> 
> The risk of not attending to these indications is exposure of users to a
> growing set of known defects and related issues that