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

# Mailing List Descriptions

- To: <announce@dieboldes.com>
- Subject: Mailing List Descriptions
- From: "Ken Clark" <ken@dieboldes.com>
- Date: Wed, 27 Jan 1999 09:56:31 -0600
- Importance: Normal

This message was sent in December, but I think it is probably a good idea if I re-send it every once in a while. Even if you think you have seen this message before, please take a few minutes to read it. Following the guidelines here will make it easier for support and development to respond to your messages.

announce@dieboldes.com

This list is for general announcements. Software releases and status updates in particular are sent to this list. You can post an annoucement about whatever you think is of interest here. In general, messages sent to the announce list are not followed up on the announce list. If you have a support or RCR related question that relates to a software announcement, post a follow up to those lists, not the announce list. The exception to this would be the original poster correcting errors in the announcement.

support@dieboldes.com

All support related discussion should be sent here. These include questions about our hardware and software, bug reports, information on upcoming and past elections, etc. Everyone is allowed and expected to respond to questions on the support 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. Since all lists are archined, we can use the archive to build a database of questions and answers for solving support problems.

rcr@dieboldes.com

Requests for changes to our software product should be sent here.

I am not very concerned with the format of people's RCRs as I am with the content. All RCRs need the following information:

- Submitter's name.
- A one line synopsis (title of the request).
- Why it is needed.
- Detailed description of the change or enhancement.

If the RCR is needed for a particular election, then the request also requires:

- What jurisdiction needs it (i.e. what county).
- What election it is needed for. When the ballots are due for the election, when early voting starts, and when election day is.

Each RCR must contain only one request. Minor related items can slide in of course, but unrelated items are a definite no-no. Bug fixes are not RCRs. Send bug fix requests to the support mailing list, or directly to your favorite developer. Small enhancements can also be sent to the support mailing list, and will get as much attention as RCRs. RCRs should be of a "project" nature. Adding a button or a field to the user interface because it would make the software more useable is usually not an RCR. Making GEMS or the Accu-Vote do something it didn't do before is definately an RCR. Use your judgement.
The description part of the RCR is the most important. The better job you do in describing how you would like the software to work, the easier (and quicker) it is to satisfy your request. Several RCRs that have been sent in have outstanding issues that need to be addressed before any work can be done. That is what the rcr@ mailing list is all about. Even if you did not submit the RCR, your are encouraged to follow up with your own ideas and suggestions as to how the change should work.
Remember a simple rule: 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 X. 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 GEMS would look after the problem is solved, the developers probably don't either.
For example, a reasonable request might be for GEMS to be able have "Vote Both Sides" printed on the ballots. Great. But how would you like that to work in GEMS? What dialog would the text be entered in? What options would there be? Would "Vote Both Sides" be printed even on single side ballots? In a multi-card ballot would it say "Vote Next Card?" Would the text be the same on all ballots, or could it be different on some? Would it take up all columns or just the last column? Would it be at the bottom of the card always, or right after the last race? This is just an example, but you get the idea.
If you feel your RCR has been lost in the noise, then follow up in the rcr@ mailing list asking for a status update. I will do my best to give RCR status reports when requested, if at least to say it is not being worked on currently. In general no-news is bad-news. The usual GEMS and Accu-Vote announcements on the announce@ mailing list will indicate when an RCR has been completed. We will also try to keep you informed as to what we are currently working on.

----------------------------------------------------------
Ken Clark
Global Election Systems
Slippery when wet.

- Prev by Date: Central Count 2.00e
- Next by Date: Accu-Vote Release 1.94f>
- Index(es):
  - Chronological
  - Thread