[Date Prev][Date Next] [Chronological] [Thread] [Top]

# rcr mailing list closing -- feature enhancement requests now in bugzilla

- To: <support@dieboldes.com>
- Subject: rcr mailing list closing -- feature enhancement requests now in bugzilla
- From: "Ken" <ken@dieboldes.com>
- Date: Mon, 30 Sep 2002 15:51:05 -0700
- Importance: Normal

At the close of business today we will be shutting down the RCR majordomo mailing list. The motivation is pretty much the same as with the old bugtrack mailing list that was shut down in June. Of late the RCR list has become a bit of a dumping ground, with no one really knowing the status of their requests. We hope that by putting all requests into the bugzilla database we can apply some rigor to the process. We want to give people an honest picture of what requests to expect in upcoming releases, and just as important, which requests not to.

When submitting new feature requests, set the Severity of the “bug” as Enhancement. This will keep the feature requests separated from bugs in existing releases. You can leave the Version field as unspecified. Obviously the version of the feature doesn’t exist yet, so there is nothing to fill in there. All of the old rules for submitting RCRs still apply. If a RCR turns out to be better characterized as a bug (or visa-versa), we can always change the severity after the fact.

There are new hyperlinks on the main bugzilla page for My RCRs and My RCRs in Purgatory. You can use these to see the status of your feature requests. All of the previous RCRs from the majordomo list have been imported into bugzilla. It will take some time to work through these, but we hope to have them sorted over the next couple of weeks. In the mean time, don’t take the current status of your requests as gospel.

The basic modes are:

NEW, unassigned: The feature request has not yet been reviewed or assigned to anyone.

LATER: The feature may be implemented some day, but is not on our 3-6 month development horizon, and will not likely make it into the next upcoming major release.

NEW/REOPENED, assigned: The feature has been assigned to a project lead, and will be implemented in an upcoming release.

WONTFIX: In all likelihood, this request will never be implemented.

INVALID: There were not enough details given to implement the request. The request is functionally in the same state as WONTFIX until more information is provided.

Please don’t take the WONTFIX state personally. We would love nothing more than to implement everyone’s requests, but tough technical and business realities often make that impossible. If you feel that your request has been unjustly rejected, bring it up with the executive committee and see if you can get it resurrected. Just because something is on the WONTFIX pile does not mean that it must stay there forever. If the right technical or business circumstances present themselves, the request could become a reality. The reason for this state is simply to try to be honest with people about their request, rather than putting it on the LATER pile where LATER won’t in reality come before hell freezes.

The LATER pile is basically an un-prioritized list. We may one day make use of the priority field of bugzilla, but for now our priority (pardon the pun) is to let people know if their request will: (1) make it into a foreseeable release, (2) make it into some release way out in the future, or (3) never make it into any release. We might one day start fine-tuning the far out horizon; for now though, knowing which of those three slots a request fits into will be a big improvement on what we have now.

Ken

- Prev by Date: Re: OS server/Vote center question
- Index(es):
  - Chronological
  - Thread