Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add an OfficeGroup element #287

Open
jdmgoogle opened this issue Oct 2, 2015 · 19 comments
Open

Add an OfficeGroup element #287

jdmgoogle opened this issue Oct 2, 2015 · 19 comments

Comments

@jdmgoogle
Copy link
Contributor

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

@jdmgoogle jdmgoogle added the bug label Oct 2, 2015
@jdmgoogle jdmgoogle modified the milestones: Up for Debate, Version 5.1 Oct 2, 2015
@jdmgoogle jdmgoogle added enhancement and removed bug labels Oct 2, 2015
@cjerdonek
Copy link
Contributor

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
Copy link
Contributor Author

@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
Copy link
Contributor

@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
Copy link
Contributor Author

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
Copy link

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

johnpwack@gmail.com

301.640.6626 - cell

301.975.3411 - office

On Tue, Nov 17, 2015 at 5:16 PM, jdmgoogle notifications@github.com 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
Copy link
Contributor Author

@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
Copy link

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

johnpwack@gmail.com

301.640.6626 - cell

301.975.3411 - office

On Wed, Nov 18, 2015 at 12:14 PM, jdmgoogle notifications@github.com
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
Copy link
Contributor Author

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
Copy link
Contributor Author

@johnpwack Friendly ping.

@jdmgoogle
Copy link
Contributor Author

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
Copy link
Contributor

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

@jdmgoogle
Copy link
Contributor Author

Bumping to 5.2.

@afsmythe
Copy link

afsmythe commented Jan 6, 2020

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
Copy link
Contributor Author

SGTM. Thanks.

@afsmythe afsmythe modified the milestones: Version 5.2, Version 6.0 Jan 8, 2020
@jswiesner
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link

This is still true in 2021.

@jswiesner
Copy link
Collaborator

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 afsmythe modified the milestones: Version 6.0, Up for Debate Jun 29, 2021
@afsmythe
Copy link

Assigning to Up for Debate for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants