----- Original Message -----
Sent: Thursday, January 25, 2001 5:35
PM
Subject: RE: question? Not counted box in
race editor
What does this box do exactly
when you check it? and what would be an example of when you would use
it?
Ignorantly yours,
Tari
Good
question...
Below is a post from our internal development
list. It is a little technical, but hopefully the gist comes
across. There are cases you want different headers for the same set of
races. Problem is that ballot styles (sic, not card
styles) are determined by their unique set of races only, not
headers. The expedient solution was to create this flag
to allow "placeholder races that are not really races". You can use this flag to force a new ballot style by
creating a dummy placeholder race. You can then hang headers off of this
placeholder race, like any other race, but the race won't show up on reports
or the AVTS screen.
If this all
sounds like a hack, you're right. We'd be more than open to better
solutions for Gwennett, so long as it didn't break other cases, but trust
me this is a tough design nut to crack. Well, Tab and I were
not been able to find a better solution so far at
least.
Ken
-----Original
Message-----
From: Ken Clark [mailto:ken@gesn.com]
Sent:
Thursday, April 06, 2000 4:50 PM
To:
devel@gesn.com
Subject: Races that are not
races
I talked to Tab about this for about an hour a week
or two ago. I'm now at implementation point though and wanted to get
some details hashed out.
The BallotRotRaceRot table does not store headers
(duh). The GEMS design is that headers come along for the ride as
decoration for a set of races. We have a mechanism to ensure that only
headers of a given vgroup pair appears on a vgroup-specific card, but you
can't use a header to force a different vgroup-specific ballot. Note I
am being careful about the terms card and ballot here.
Gwinnett wants a different card header
for absentees despite the fact that the absentee race set is identical to
the polling race set. There are a number of ways we can deal with
this, but the current work around is to create a dummy race with no
candidates to differentiate the ballots. This works, but this race
then gets downloaded to the AV and TS. On the AV the race shows up in
the reports. On the TS the race ends up on the screen. It
probably shouldn't do either. I don't think SOVC and Summary include
races with no candidates, but that is more of an oversight than a
design.
Here is what I propose:
- New race field
"DontCount". If nonzero, the race is not downloaded to the AV, and
is filtered from all reports, candidates or not. This is a
convenience field so people don't have to create special race filter sets
to exclude the race. Also makes a nice "withdraw race" flag if
we like.
- New race field
"CountMethodMask". Same as the one in Header. The original
logic was that a race on paper must by definition also be on touch.
If the race isn't counted that is not necessarily the case, and hell who
knows maybe there are crazy reasons to do this with other races
too.
One other
possibility would be to not have the CountMethodMask race field and say that
DontCount races also never appear on either an AV card or a TS screen.
If users want, they can always attach a significant header to the DontCount
race if they want text to appear on the card or screen. I'd probably
call this a "PlaceHolder" race type rather than a separate DontCount
flag. This is not as general as my proposal, and means they have to go
through the extra step of creating the sig header (likely with
the identical name), but I am not thrilled with the idea of two new
race fields either. Let me know if you like this better, or have other
ideas.
I am moving
forward with this because MN is going to need to be able to force separate
card ids just like Gwinnette, only this time its so we can do the high-order
precinct id bit trick for absentees without header
cards.
Ken