Mailing list description and policy.

["Ken Clark" <ken@dieboldes.com>]

General:

 

Our mailing lists are managed my a program called Majordomo.  You can get a list of commands that Majordomo supports by sending an email message with a single line "help" to majordomo@dieboldes.com.  You can also send commands to a specific list by mailing to list-request@dieboldes.com where list is the name of the list.  For example, you might send an "unsubscribe" command to support-request@dieboldes.com to unsubscribe from that list.

 

If have questions about using Majordomo or setting up your email, contact Mike Brown and he will be happy to help you out.

 

The lists are closed to Global staff.  Do not CC customers when posting to the lists, or forward messages from the lists to customers without permission.

 

The Lists:

announce@dieboldes.com

The announce list is for general announcements.  Submissions to announce should be of the "notice" variety -- much like a company bulletin board.  The Global Newsletter and press releases are good examples.  Messages sent to the announce list should not be followed up on the announce list.  If you have a question, bug, or feature request, send them to the appropriate list, not announce.  The exception to this would be the original submitter correcting errors in the announcement.

sw-announce@dieboldes.com

The sw-announce list is for announcements of new software releases.  Submissions to sw-announce include a description of the changes in the software release, and the passwords to retrieve the release from our ftp site.  Posting to the sw-announce list is restricted to the development group.  If you have a support question, bug, or feature request related to a recent software announcement, send them to the appropriate list, not sw-announce.

rcr@dieboldes.com

The rcr list is for requests for new features or improvements to our products.  Guidelines for posting messages to the rcr list are outlined in the document Submission Policy (attached).

bugtrack@dieboldes.com

The bugtrack list is for reporting bugs in our software products.  Guidelines for posting messages to the bugtrack list are outlined in the document Submission Policy (attached).

support@dieboldes.com

The support list is for operations related discussion that is not otherwise bugs or feature requests.  If you don't know if your question is a bug or rcr, post to support and ask.  The issue can always be escalated to those lists later.  All development and ESD personnel are welcome and expected to respond to this list if they know the answer or have something to contribute to the discussion.  It is always better to send a question to the support list, even if you think it is simple or stupid.  If you don't know the answer to the question, the chances are other people on the list don't know the answer either, and would also gain from seeing the response.  Even if you know full well that there is only one person who knows the answer to your question, again post it to the support list, not him or her.  Chances are very good that you are not the only one who needs to know the answer, or will need the answer three weeks from now.  Consider the support list as a repository of communal knowledge.

salestalk@dieboldes.com

The salestalk list is for discussion regarding sales and selling-related topics.  This includes questions about sales prospects, material for RFPs, status updates, and whatever else it is that sales people talk about.

 

Title: Bugtrack Post Policy

January 9, 2001

 

Bugtrack Submission Policy

 

The bugtrack list is used to report and track bugs in our software products.  Bugs will not receive attention without a bugtrack submission.

 

Bugtrack submissions must contain:

 

• A subject line that contains a synopsis of the bug.
• The version of the software that contains the bug and the version in which the bug first appeared.
• A description of the bug, including all error messages.
• A test case and steps necessary to reproduce the bug.

 

A bugtrack submission must describe only one bug.  It is possible for the same bug to manifest itself in more than one way, and this may result in more than one report, but single posts with unrelated bugs will be ignored.  In particular, do not forward “bug lists” submitted by customers.  Sort out and reproduce each bug, then post separate reports.

 

The subject line is critical.  “GEMS 1.14.7.1 problem” is not an acceptable subject line for a bugtrack submission.  The development group uses the subject line to track the status of the bug.  We will lose your request without a proper subject line.  If you have something to contribute to the discussion, be sure to do it using the same subject as the original submission.

 

If you did not catch the exact error message or were not actually present when the bug appeared, then reproduce the bug yourself and write down the details before posting.  If you are not sure in which version the bug first appeared, narrow it down by testing earlier releases.

 

Development must be able to reproduce a bug in order to fix it.  If you cannot reproduce the problem, it is very unlikely that development will be able to reproduce it either.  Keep one or more toy databases you know worked in previous releases handy for testing.  If a bug manifests itself in one database but not another, determine what settings trigger the problem by comparing the differences between the database that works and the one that doesn’t.  Start with the working database and then make changes until it breaks.  Try to narrow your test case to a minimal database that exhibits the problem.  Specifically, don’t post a 2MB 1000-precinct VIBS database if a one-precinct one-race database also fails.

 

RCR Submission Policy

 

The RCR list is used request new features in our software products.  Feature requests will not receive attention without a RCR submission.

 

RCR submissions must contain:

 

• A subject line that contains a synopsis of the request.
• The account requesting the feature, if applicable.
• The motivation for the request – why it is needed.
• A detailed description of the change or enhancement.
• The date the request is needed, and the nature of the deadline.

 

A RCR submission must describe only one new feature or enhancement.  Minor related items can slide in of course, but unrelated features are verboten.  In particular, do not forward “feature request lists” submitted by customers.  Sort out the requests and submit them as separate posts.

 

The subject line is critical.  “New Report” is not an acceptable subject line for a RCR submission.  The development group uses the subject line to track the status of the feature.  We will lose your submission without a proper subject line.  If you have something to contribute to the discussion, be sure to do it using the same subject as the original submission.

 

The description and motivation part of the RCR are important.  The better job you do in describing how you would like the software to work, the better chance development has at satisfying your request.  The submission must contain both the why and the how of the feature.  That is, a RCR defines a solution to a problem, not just the problem itself.  It is not enough to say that the software needs to be able to do so-and-so.  You need to tell the developers how you want it to look and work.  Think of an RCR as a mini-design document.  Now, you don't have to get carried away:  some requests are fairly self-evident, and the developers can work with you to get the fine strokes worked out.  Just remember that if you don't know how the product would look after the problem is solved, the developers probably don't either.

 

Feature development is a dynamic collaborative process.  If there are details of the new feature that are not obvious or there is more than one way to solve the problem, this will result in follow-ups to the original submission.  If the missing details are not provided or there is no consensus on a preferred solution, this will stall the development process.  Everyone is welcome to submit input on a request.