RahulSundaram/CollectiveMaintenance

= No answer to bug fix policy =

The Problem
There are several occasions where the individual maintainers are still active and working on some software packages while not fixing trivial bugs on other software packages. If this occurs over a long period of time, the maintainers should seek out co-maintainers or just be orphaning the software packages they are not interested in. If it does happen for a shorter periods, others can act as a buffer to avoid the problem lingering for our users. A bug easy to fix is a bug where other experienced and trusted package maintainers, developers or others in the community have offered a specific simple solution to the problem in terms of patches or recommendations that translate into straight forward solutions. More precisely, these 3 situation may qualify for a bug easy to fix:


 * a patch is proposed, attached to the bug, and tested
 * a trivial change is proposed to the .spec, preferably tested
 * help is offered, with different possibilities outlined, but the maintainer has to ack or specify his preferences for the style of the proposed fix, so that the contributor can create a suitable patch

Maintainers are wary of stepping on each other's toes and these clear guidelines should help in setting expectations. Also, it should always be remembered that simple changes may have unexpected consequences on the distribution as a whole, so easy bugs should be cautiously considered.

This policy is not to be abused. It should be conceived as a way to have maintainers react when they maintain too much packages, and not a way to punish maintainers.

The solution
When the situation described above happens, somebody (called the reporter) can proceed with what is explained below, provided 3 weeks have passed. However, this should only be done in one bug at a time for each maintainer, even if there are many such bugs for different or the same components. To enforce that, a blocker bug should be associated with the bug such that it is easy to see which maintainer is already concerned by the procedure.

The reporter shall place the following comment in the bug:

---

As per the 'No answer to bug fix' policy, please answer within the timeout period whether


 * you wish to allow others to fix this bug


 * you are not interested enough in that package to really keep on maintaining it by yourself, and are looking for a co-maintainer


 * you wish to orphan the package


 * you know of already in progress work that should fix the bug, indicating the nature of this work, and time frame for release

If you don't answer after, a reminder should be sent, and if not answered within a further My_Username will be assigned as a co-maintainer and can make changes according to the policy stated at

http://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers

---

Timeout period specified in non responsive maintainer policy

---

- The reporter blocks a blocker bug, such that before following the procedure another reporter can check that the procedure has not already begun for the packager.

- The blocker bug is left for at least 1 month, even if the maintainer answered, such that only one procedure per month can be engaged.

- a response from the maintainer (even a simple 'I am looking at it', but preferably a 'will get to this during [time frame]' etc.) resets the timers.

- it is the reporter responsibility to clean the blocker bug as soon as possible once the maintainer has responded.

The idea is to avoid having people be able to bother maintainers more than needed by having only one procedure opened at a time, while forcing uninterested maintainers to accept co-maintainers or orphan their packages.