OPEN SITES/BOARDS

-----Original Message-----
From: Ken Clark <ken@dieboldes.com>
To: announce@dieboldes.com <announce@dieboldes.com>
Date: Wednesday, February 10, 1999 11:03 AM
Subject: Mailing List Descriptions

Okay, time for another "Mailing List Descriptions" post. Also time to stand on my soap box. This is not complicated kids. Announcements about your new born child goes to the announce@ list. Questions about why something is broken, how something works, or what is going on goes to the support@ list. Requests for new features in our software goes to the rcr@ list. Everything needs a subject.

This week's edition also adds the new list salestalk@dieboldes.com, plus devel@dieboldes.com which has been around forever wasn't included previously in this post because it is a closed list.

I am also open to the idea of closing salestalk@ to sales staff (I have talked to Rob about this) but in fairness that means we should create a closed support list as well. I have also considered adding a hardware@dieboldes.com for hardware related development. If you have any ideas on how the lists might be better organized, feel free to post to the support list (but you already knew that would be the right place).

This list is for general announcements. Software releases and status updates in particular are sent to this list. You can post an announcement 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.

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 archived, we can use the archive to build a database of questions and answers for solving support problems.

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.

Software programming and design discussion. Closed to developers. Also contains some hardware related discussion currently for want of a better place (although Ian is not on the list right now).

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

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 definitely 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.