|
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.
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.
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.
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:
If the RCR is needed for a particular
election, then the request also requires:
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.
---------------------------------------------------------- |