Bugtracker Cleanup Project

Currently (Wednesday, May 9, 2007) there are 228 open bugs in OpenACS and .LRN https://openacs.org/bugtracker/openacs/. (Note I had to multiple 25 time the number of full pages  of bugs and tack on the last 3 on the last page the numbers next to the filters don't reflect the actual current state.) The list of bugs in the bugtracker does not reflect the reality of the release status of the toolkit. That is, the core developers and the automated tests show that OpenACS core and .LRN are pretty stable and work as expected.

There are some quite old bugs, along with suggestions, todos and more reported in the bugtracker. Its quite possible a bug was fixed without a developer noticing a reported bug in the bugtracker that should have been closed. Some bugs have become irrelevant due to changes in OpenACS since the bug was first reported.

Around OpenACS 5.1 there were even goals for number of open priority 1 bugs (0) before a release was declared final. I think it is a good goal to have the bugtracker reflect the real status of a release.

To do this we need volunteers to go through existing bugs, and check if they are still relevant, check for patches, and close the bug, fix it, or as for help in resolving a bug.

Here is a proposal for a procedure to meet this goal

1. Test is a bug can be duplicated on the newest release of OpenACS 5.3.1 or .LRN 2.3.0. If not it should be marked not reproducible and closed. If more information is necessary that should be marked and the bug reassigned to the original submitter.
2. If the bug is reproducible, and the tester does not feel they have the knowledge to fix the bug themselves, a request for assistance should be made. At this point a more experienced volunteer will need to help out. It would be wonderful, although it is not required, if volunteers ask for help, then take this advice to learn more about the toolkit, and try to fix it themselves. This is definitely NOT required to contribute to this effort. Anyone who can try to reproduce a bug on a test server can contribute.
3. If a decision needs to be made, whether a bug should be fixed, for core packages, the OCT should decide. For .LRN packages that are released with .LRN, the .LRN Leadership Team should decide. For other packages, it would be great if someone who uses or develops with the package will step up as maintainer and make that decision.

This is meant as a quick simple proposal to get a discussion going, and hopefully a volunteer effort organized to make the bugtracker reflect the real status of the code. Any suggestions are welcome.

--

suggestions:

1. bug bash. Maybe coincide with a Tcl/Tk conference (for those not following the Tk part).