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

Implementation of Elections spec #82

Merged
merged 31 commits into from
Jul 17, 2017
Merged

Conversation

gordonje
Copy link
Contributor

As defined in this draft proposal.

@coveralls
Copy link

coveralls commented May 10, 2017

Coverage Status

Coverage decreased (-1.3%) to 98.286% when pulling c952cde on california-civic-data-coalition:master into 8e3abb0 on opencivicdata:master.

@gordonje
Copy link
Contributor Author

@jamesturk given the movement toward separate apps, should spike this PR and submit another after PR #85 is merged?

Or I could also make a PR on the split-apps branch, and this could all go up together.

@jamesturk
Copy link
Member

let's keep these in separate PRs, but yeah I think we should wait to merge until we've decided one way or another on #83- I'll ping the relevant parties to see if they're OK with the plan

@gordonje gordonje changed the title Implementation of Elections spec WIP: Implementation of Elections spec Jun 1, 2017
@coveralls
Copy link

coveralls commented Jun 1, 2017

Coverage Status

Coverage decreased (-28.4%) to 70.358% when pulling 8e3fd0e on california-civic-data-coalition:master into 4d0c164 on opencivicdata:master.

@coveralls
Copy link

coveralls commented Jun 5, 2017

Coverage Status

Coverage decreased (-26.5%) to 72.254% when pulling acf5503 on california-civic-data-coalition:master into 5f97a77 on opencivicdata:master.

@coveralls
Copy link

coveralls commented Jun 5, 2017

Coverage Status

Coverage decreased (-26.5%) to 72.231% when pulling 3bf12ef on california-civic-data-coalition:master into 5f97a77 on opencivicdata:master.

@coveralls
Copy link

coveralls commented Jun 5, 2017

Coverage Status

Coverage decreased (-26.8%) to 71.938% when pulling 9e95522 on california-civic-data-coalition:master into 5f97a77 on opencivicdata:master.

@coveralls
Copy link

coveralls commented Jun 5, 2017

Coverage Status

Coverage decreased (-11.9%) to 86.838% when pulling 3e1e045 on california-civic-data-coalition:master into 5f97a77 on opencivicdata:master.

@coveralls
Copy link

coveralls commented Jun 5, 2017

Coverage Status

Coverage decreased (-1.5%) to 97.27% when pulling 4cd41a4 on california-civic-data-coalition:master into 5f97a77 on opencivicdata:master.

@coveralls
Copy link

coveralls commented Jun 22, 2017

Coverage Status

Coverage decreased (-1.5%) to 97.27% when pulling bba89e4 on california-civic-data-coalition:master into 5f97a77 on opencivicdata:master.

3 similar comments
@coveralls
Copy link

Coverage Status

Coverage decreased (-1.5%) to 97.27% when pulling bba89e4 on california-civic-data-coalition:master into 5f97a77 on opencivicdata:master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-1.5%) to 97.27% when pulling bba89e4 on california-civic-data-coalition:master into 5f97a77 on opencivicdata:master.

@coveralls
Copy link

coveralls commented Jun 22, 2017

Coverage Status

Coverage decreased (-1.5%) to 97.27% when pulling bba89e4 on california-civic-data-coalition:master into 5f97a77 on opencivicdata:master.

@coveralls
Copy link

Coverage Status

Coverage decreased (-1.5%) to 97.27% when pulling b348cf6 on california-civic-data-coalition:master into 5f97a77 on opencivicdata:master.

1 similar comment
@coveralls
Copy link

coveralls commented Jun 23, 2017

Coverage Status

Coverage decreased (-1.5%) to 97.27% when pulling b348cf6 on california-civic-data-coalition:master into 5f97a77 on opencivicdata:master.

@coveralls
Copy link

coveralls commented Jun 23, 2017

Coverage Status

Coverage decreased (-1.5%) to 97.27% when pulling 8b4bdf3 on california-civic-data-coalition:master into 5f97a77 on opencivicdata:master.

@coveralls
Copy link

coveralls commented Jun 23, 2017

Coverage Status

Coverage increased (+0.3%) to 98.999% when pulling 2de4af2 on california-civic-data-coalition:master into b38b6dd on opencivicdata:master.

@coveralls
Copy link

coveralls commented Jun 23, 2017

Coverage Status

Coverage increased (+0.3%) to 98.999% when pulling 2a133f1 on california-civic-data-coalition:master into b38b6dd on opencivicdata:master.

@gordonje
Copy link
Contributor Author

@jamesturk This one is ready for review again. Below are some notes on differences since I first put in the PR.

Removed inheritance from non-abstract models

  • Election no longer subclasses Event. There's been some discussion, though, about adding an abstract EventBase in opencivicdata.core someday.
    • In the mean time, I'm not clear on the proper format for Election.id. I currently have it as ocd-election/..., but should it be ocd-event/...?
  • ContestBase is now an abstract model from which all the contest models inherit.
  • RetentionContest no longer inherits from BallotMeasureContest but remains under the contests.ballot_measure namespace.

Added models

  • ElectionSource, which mirrors the EventSource model. I don't think any of the other event-related models have any relevance to elections.
  • RetentionContestOption, which mirrors BallotMeasureContestOption.
  • Split up ContestIdentifier into four contest-class specific models.
  • Same as above for ContestSource.

Removed models

  • Replaced Party model with references to Organization from core (per issue #89 from the specs repo). These foreign key relationships (e.g., Candidacy.party) are limited to only organizations with the classification "party", though I believe that's only forced on Django forms, not by the ORM or db.

@gordonje gordonje changed the title WIP: Implementation of Elections spec Implementation of Elections spec Jun 23, 2017
Copy link
Member

@jamesturk jamesturk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks pretty good to me, I wasn't as involved in the OCDEP process so apologies if any of my questions were already covered

opencivicdata/legislative/migrations/*
opencivicdata/legislative/admin/*
opencivicdata/*/migrations/*
opencivicdata/*/admin/*
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

'updated_at',
)
# date_hierarchy across relations was added to django 1.11
if django_version[0] >= 1 and django_version[1] >= 11:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm curious if you have a need for Django < 1.11 support? technically this supports 1.10 right now, but since 1.11 is LTS I'm OK w/ new stuff requiring 1.11

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Our package that will depend on python-opencivicdata currently supports Django>=1.9, but this particular feature isn't super important. Just adds a nicer filter option to this admin for users who are at least at Django 1.11.

@@ -6,4 +6,4 @@
from .vote import (VoteEvent, VoteCount, PersonVote, VoteSource)
from .event import (Event, EventLocation, EventMedia, EventMediaLink, EventDocument, EventLink,
EventSource, EventParticipant, EventAgendaItem, EventRelatedEntity,
EventAgendaMedia, EventAgendaMediaLink, EventDocumentLink)
EventAgendaMedia, EventAgendaMediaLink, EventDocumentLink)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this might be a mistake?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I'm not sure what happened exactly, as I would not have had any reason to change this file. Looks like the newline at the end of the file was deleted. I just added it back.

max_length=300,
help_text="For preserving the candidate's name as it was of the candidacy."
)
filed_date = models.DateField(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be a fuzzy date or will we always require Y-m-d

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In our case, all of these dates are exact. I think the source for this data in most states will be a form the candidate files with an election authority. I think you'll either have the full date or no date at all.

But maybe we want to allow users to put in their best guess for the date? Or if the default for OCD is to use fuzzy dates unless there's a good reason to be exact, we would be fine with that.

max_length=300,
help_text='Name of the Election.',
)
date = models.DateField(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this being an exact date makes sense to me

I think we agreed to sideline questions about multi-day elections (e.g. vote-by-mail)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO even vote by mail elections will want to be tied to a specific date on which the votes are expected to be counted and the results will be published. But, yeah, a convo for another time when we know users will need to track when ballots can be cast.

@coveralls
Copy link

coveralls commented Jul 7, 2017

Coverage Status

Coverage increased (+0.3%) to 98.999% when pulling 4ed4d34 on california-civic-data-coalition:master into b38b6dd on opencivicdata:master.

@gordonje
Copy link
Contributor Author

@jamesturk so I think the proposed changes are:

  1. Drop the election date hierarchy filter on CandidacyAdmin so as not to introduce a Django >= 1.11 feature just yet.
  2. Make Candidacy.filed_date a fuzzy date field, rather inheriting from DateField in django.db.models.

Should I go ahead and make either or both of these?

@jamesturk
Copy link
Member

  • no need to drop the date hierarchy filter, definitely want to support Django >= 1.11
  • I'll defer to you on the filed_date issue, I don't know the data well enough to know if a fuzzy date is necessary, but if you think it'd be useful I'd switch it to that

I don't think I have any further changes, I think we could go ahead and accept this & consider it provisional (so a bit less strict on backwards incompatible changes until it stabilizes)

@gordonje
Copy link
Contributor Author

Cool! Let's do this.

@palewire
Copy link
Contributor

This is excellent news. Thrilled to see this merged and released.

@jamesturk jamesturk merged commit 63953bf into opencivicdata:master Jul 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants