|
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). Ken
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).
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 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.
---------------------------------------------------------- |