Project:Bug-cleaners

The goal of the Bug cleaners project is twofold:
 * The main purpose of the project is to close bugs on Bugzilla that do no longer apply due to versions and/or packages that are no longer present in the Portage tree.
 * As a side effect, it also tries to look for solutions for the oldest bugs.

For those that still have use, it attempts to inform the persons involved in the bug that the bug is still open if the bug is important; inviting them to make a decision on it.

Resources
Queries that can be handy for finding old bugs include:


 * Bug cleaners: Oldest bugs: Any bugs or filtered bugs (no retirement, games or m-w), both filter out bugs that block useful trackers.
 * Bug cleaners: Long time untouched bugs: Any bugs or filtered bugs (no retirement, games or m-w), both filter out bugs that block useful trackers.
 * QA-Reports: Bugs last touched by year: till 2006 (0 bugs), 2007, 2008, 2009, 2010, 2011 and 2012.

First steps
Because one cannot just rush in and go hunt at random bugs and expect people to agree with one's actions; the very first steps we will take is to raise the necessary discussion to get feedback on what the community wants us to do exactly, which clarifies the further limits and scope of the project.

Questions to be answered
We will need to get some questions answered to proceed:


 * How old is "oldest"?
 * When is a bug considered still useful?
 * Are there other types of bugs we could or need to look into?
 * Can this effort replace the Bug Day that does not receive interest lately?
 * Do we need a mail alias so we can get CC-ed on bugs? (Effectively allowing users to help as well.)
 * Do we need a mail alias so we can get assigned on bugs? (*unsure*)
 * What to do in exceptional cases? (Cannot be answered until we identified them.)

This will be discussed on the mailing lists.

Bug summaries
Preferably, bugs requesting new packages should have similar formatting for the summary or title. This will allow for easy parsing of the maintainer-wanted bugs and quickly inform readers of the name and purpose of requested packages. Suggested guidelines for package requests are:


 * The summary should contain the package name, the category, and a brief description of the package.
 * Category suggestions are fine, but if unsure, just leave it out and mention in a comment.
 * If the category isn't known, then it can be omitted.
 * Version numbers should not be in the summary.
 * The request is for the atom to be added in general, versioning will be dependent on the maintainer and upstream availability.
 * If the addition of one package is dependent on the addition of another, this should be indicated with the Bugzilla field.
 * Depends On should only be set for the immediate dependency - in the example below, would is only used for, not.

Examples of good bug summaries include:


 * Bug 1234 - app-editors/foo: a multicoloured text editor
 * Bug 1236 - app-dicts/bar: a dictionary of bad words for app-editors/foo [depends on 1234]
 * Bug 1238 - libbaz: a library for accessing app-dicts/bar [depends on 1236]

Examples of bug summaries that are less useful:


 * Can foo be added to the tree?
 * bar is a dictionary
 * It would be cool to have libbaz if we get foo

This page is to be extended
We will need to document our practices and useful resources here (QA reports, good bug queries, ...).

Criteria for closing a report
Each request is important and was made by a real user, so must be carefully evaluated prior to closing. While it is not useful to have thousands of open requests, it's also harmful to unnecessarily close requests that are still valid.

Use these guidelines to help evaluate whether a request still has merit:

Project's relationship to Bug wranglers
This project attempts to fit side by side with Bug wranglers.

Bug wranglers is a project for bug assignment. Having a separate mail alias and project page makes it easier for people as a separate form of contact, documentation, and recognition.