[top posting] Given the breadth of this post, and its implications, I would suggest breaking this up into "sub" discussions. For example, review what we have on QA practices, and involve the QA volunteers in discussion of some of these topics. I realize this may be difficult because some of the issues involve facets of OpenOffice that are not commonly used, or require more in-depth knowledge of particular aspects -- basic programming, for example.
I think we've already had some feedback on the VERY old issues as well. Some of these issues have in fact been resolved, but the issue has never been closed. It may be difficult to determine when the issues was resolved and include that for record keeping in the issue. It would help if many of these old issues could be re-reviewed and determine if they still exist. Just to re-iterate: I think it would help if the overarching topic/discussion presented here could be broken down into sub-topics. And, I find this statement -- > The rate of arrival of new issues is steadily declining from the 2013 > peak. That is not necessarily good news. It does not demonstrate > better proportional clearing of the smaller number. somewhat off-putting. It seems rather critical of our QA efforts and development efforts to me. On 09/09/2015 11:33 AM, Dennis E. Hamilton wrote: > > From the Chair, > > From "A Maturity Model for Apache Projects," > <http://community.apache.org/apache-way/apache-project-maturity-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 remain in > the software indefinitely. > > DISCUSSION > > Besides the questions posed by growing technical debt, below, perhaps > the most pressing topic for resolution this year is Improved > Coordination of Issues, near the end of this lengthy note. This > requires a community approach and a group of contributors able to > work with users in providing first-line support in identification of > issues, recording issues, and directing users directly to known > solutions or work-arounds. The volunteer users who accomplish that > will require all of our support. They are also our best source of > on-the-ground experience with regard to what the major difficulties > are. > > All questions, proposals, corrections, and suggestions are welcome. > > TECHNICAL DEBT > > Using crude statistics from an earlier report, every indication is > that the rate of unresolved issues is continuing to accrue as > technical debt with over 40% of arriving issues unresolved. In this > case, the debt is the accumulation of unresolved defects and the cost > of a process that reduces the increase while also paying down past > debt. > > As of 2015-08-05 * the oldest unresolved issue is #497 created > 2001-03-02 * 24115/121298 (20%) issues unresolved from before > November, 2012 * 2232/5139 (43%) issues unresolved of new issues from > November, 2012 (after TLP) through July, 2015 * 192/452 (42%) issues > unresolved of those created in the first 7 months of 2015 > > There are a number of factors that impact the quality of these > statistics, including > > * Unresolved issues are not differentiated by type. Feature and > enhancement requests are counted among confirmed defects. > > * The resolved portion includes issues rejected as duplicates, as > lacking supporting information, and as usability/support matters > rejected as not being bugs, even when obviously about defects. > > There is every reason to fear that, after such adjustments, the rate > of technical debt accrual is even greater than 42-43%. > > CONTEXT > > 2012-11: #121299 First new issue in the Bugzilla of the AOO Top Level > Project. 2015-07: #126439 Last new issue in the Bugzilla at the end > of July, 2015. > > By years at the TLP, (2012 and 2015 partial) > > 2012 2013 2014 2015 > > 929 2136 1739 441 BZ items/month 133 198 170 65 > New issues/month (averages are rounded to whole numbers) > > The rate of arrival of new issues is steadily declining from the 2013 > peak. That is not necessarily good news. It does not demonstrate > better proportional clearing of the smaller number. > > PROPOSED MITIGATION > > The project is currently in a crunch to release Apache OpenOffice > 4.1.2. There will be a bump in Bugzilla activity after which there > can be a fresh look at this situation and the developers now > heads-down on 4.1.2 can look to the horizon beyond. > > MONITORING. These data will be updated monthly, using the July 2015 > state as a baseline with respect to changes in the technical debt and > rate of increase. A new baseline from December 2015 can be used for > 2016, continuing on an annual basis thereafter. > > REVIEW. Some drill-down is required to differentiate between > unresolved feature and enhancement requests in contrast to reports > that relate to defects of some kind. It is also important to > understand the incidence of duplicates for still-unresolved issues > and issues that are marked resolved without any action having taken > place. > > IMPROVED COORDINATION OF ISSUES. Issues involve far more than > identified bugs. Reported issues are valuable information about > experiences of users and others and where their difficulties arise. > There is no means to determine how many others experience an issue > and do not report it. It is important that usability issues of many > kinds be captured, tracked and mitigated wherever possible. > Appropriate categories should be added to the Bugzilla and issues of > such kinds should be embraced as the gifts that they are. Simple > additions to the current Bugzilla classifications will be > investigated. In addition, many issues are recognized on the mailing > lists and forums. It is important that there be cross-talk among the > different volunteer supporters and that there be no direction of > users to other places instead of providing some positive assistance. > This involves more engagement and communication among those who work > with the Bugzilla, the mailing lists, and the forums to ensure that > all avenues are covered. It is desirable for users to be supported > with positive assistance no matter how they bring their situation to > the attention of the project. Accomplishing that is open for > discussion. "It takes a village." > > > -----Original Message----- From: Dennis E. Hamilton > [mailto:orc...@apache.org] Sent: Wednesday, August 5, 2015 19:57 To: > dev@openoffice.apache.org Subject: STATE OF AOO: Overall Bugzilla > Activity through July 2015 > > In looking for visible indicators of project activity, I created an > overview of Bugzilla activity from November 2012 through July 2015. > > This is a high-level view of gross activity and does not provide fine > details. There is still an interesting picture. > > My complete tabulation is available in a PDF document at > <http://svn.apache.org/repos/asf/openoffice/pmc/project-state/2015-07-BZ-OverallActivity-2015-08-05-dh.pdf>. > > [ ... ] > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > -- -------------------------------------------- MzK “The journey of a thousand miles begins with a single step.” --Lao Tzu --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
