Add an OfficeGroup element

[jdmgoogle]

The NIST standard has an OfficeGroup element which creates grouping of offices (e.g., "State House") for reporting purposes.

[cjerdonek]

Can you explain the proposal more fully? For example, how would one know whether to form an OfficeGroup, and what if there is more than one way to do so? It looks like there is also "OfficeCollection" and "SubOfficeGroup" to account for. This looks like it could be trying to model the structure of government, which I thought we were trying to avoid?

[jdmgoogle]

@cjerdonek Yeah, this goes back to #42 where you proposed an OfficeBody object and I argued against it. This might be better described as "up for discussion" than "enhancement" since I'm still not 100% sold on it, but my thinking has somewhat come around to what you were advocating back then. I've started writing code to parse NIST results feeds, and it turns out it would be useful to have that, given our (Google's) representation of elections; I imagine other organizations have similar needs.

@johnpwack I'd like to explore the idea of creating office groups which could contain arbitrary sets of offices. I'd also like to figure out the best way to do this and then have it be included in both VIP 5.1 and NIST 1.1.

[cjerdonek]

@jdmgoogle Yes, I was remembering that discussion. Personally, my instinct is that as long as it's light-weight and does the minimum to support reporting, I think it should be okay. If it goes beyond that (e.g. into modeling government hierarchy), I fear it could be too hard to develop a model in the desired timeframe that's adequate and evolvable going forward. What might help here is having a collection of representative use cases that you see this supporting (e.g. displaying city council members ordered by district under a "City Council" header and whatever else you can think of / have come across).

[jdmgoogle]

Circling back on this, there are two possible ways to view this:

1. a grouping of offices into a single office body (e.g., "all of these offices are part of the House of Representatives"); or
2. a grouping of contests to be displayed together on a ballot under a common heading (e.g., "Federal", "State", "State Legislature", etc).

Which one of these more closely describes what you're looking for?

Paging @johnpwack to weigh in on the purpose of the NIST OfficeGroup element.

[johnpwack]

OfficeGroup was not something I pushed for, but I've been advised that it
is desired simply as method for categorizing offices, perhaps mirroring how
some DBs are laid out, e.g., Judicial Offices, Federal Offices, StateWide
Offices, etc. I don't think the categorization is intended to be any more
than that - a hierarchical categorization for the sake of it, no
relationship to contests or ballot contents.

I can see of Ohio used it in their recent election - I don't think they did
but I'll check.

---

John P. Wack

[email protected]

301.640.6626 - cell

301.975.3411 - office

On Tue, Nov 17, 2015 at 5:16 PM, jdmgoogle [email protected] wrote:

Circling back on this, there are two possible ways to view this:

1. a grouping of offices into a single office body (e.g., "all of
   these offices are part of the House of Representatives"); or
2. a grouping of contests to be displayed together on a ballot under a
   common heading (e.g., "Federal", "State", "State Legislature", etc).

Which one of these more closely describes what you're looking for?

Paging @johnpwack https://github.com/johnpwack to weigh in on the
purpose of the NIST OfficeGroup element.

—
Reply to this email directly or view it on GitHub
#287 (comment)
.

[jdmgoogle]

@johnpwack: Do you know if the motivating factor for this element was after-the-fact analysis (e.g., wanting to group similar contests), more accurate sample ballot creation, something different, or some combination of "all of the above"?

[johnpwack]

OH wanted it and 'had' to have it as part of their desire to use the spec
state-wide. Speculating, their DB was organized this way and they said
that, in their opinion, other states probably would have contests arranged
in a similar manner.

It may be useful down the road in V2 for categorizing offices, but too soon
to tell.

Cheers, John

---

John P. Wack

[email protected]

301.640.6626 - cell

301.975.3411 - office

On Wed, Nov 18, 2015 at 12:14 PM, jdmgoogle [email protected]
wrote:

@johnpwack https://github.com/johnpwack: Do you know if the motivating
factor for this element was after-the-fact analysis (e.g., wanting to group
similar contests), more accurate sample ballot creation, something
different, or some combination of "all of the above"?

—
Reply to this email directly or view it on GitHub
#287 (comment)
.

[jdmgoogle]

Circling back to this....

@johnpwack Does Ohio want this to make aggregating contests across counties easier, or because they want to use a pre-election NIST file for some other purpose?

[jdmgoogle]

@johnpwack Friendly ping.

[jdmgoogle]

Ping to @johnpwack @pstenbjorn @cjerdonek:

Unless there is a strong case to have this in 5.1 (e.g., it will cause significant problems to Pew or the states when generating ballot data) I'm going to push this back to 5.2. Deadline for comments -- even if it's just "please hold" is 8am ET Friday morning (tomorrow). Deadline for resolution is by 5pm ET Friday (tomorrow).

[pstenbjorn]

@jdmgoogle from the VIP perspective I believe we are fine moving this to 5.2.

[jdmgoogle]

Bumping to 5.2.

[afsmythe]

Proposing we bump this to 5.3 (or 6.0?). I'm not aware of instances where the absence of an OfficeGroup is preventing data providers from providing ballot data to VIP. And the only state currently proving a NIST feed to VIP (Wisconsin, 1500-100) is not using OfficeGroup.

[jdmgoogle]

SGTM. Thanks.

[jswiesner]

I'm not aware of instances where the absence of an OfficeGroup is preventing data providers from providing ballot data to VIP.

Is this still true in 2021? And do you expect this may change by 2024?

[jswiesner]

I'm not aware of instances where the absence of an OfficeGroup is preventing data providers from providing ballot data to VIP.

Is this still true in 2021? And do you expect this may change by 2024?

@afsmythe

[afsmythe]

This is still true in 2021.

[jswiesner]

Thanks for confirming. Since there is no immediate need for this feature, can we move this to either a 6.1 or 7.0 milestone?

[afsmythe]

Assigning to Up for Debate for now.