8000 Document fields in baked results · Issue #23 · openelections/docs · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Document fields in baked results #23

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

Open
ghing opened this issue Nov 7, 2014 · 7 comments
Open

Document fields in baked results #23

ghing opened this issue Nov 7, 2014 · 7 comments
Assignees

Comments

@ghing
Copy link
Contributor
ghing commented Nov 7, 2014

I realized when we were talking about differences between rows in baked RawResults because of different structures of the input files that we didn't have any documentation for the fields in the baked results. They're obvious for anyone who's looked at the models, but less so from someone just consuming the data.

Writing this will be fast and straightforward, but my one question is about where this should live, on www.openelections.net or on docs.openelections.net and link to it. I'm inclined toward putting it with the docs because that seems more maintainable. But I'm open to other opinions.

@ghing ghing self-assigned this Nov 7, 2014
@dwillis
Copy link
Contributor
dwillis commented Nov 7, 2014

+1 for docs.openelections.net

@benlk
8000 Copy link
Contributor
benlk commented Mar 5, 2017

This may be state-specific, bake-specific data. How would you like to organize this?

@dwillis
Copy link
Contributor
dwillis commented Mar 5, 2017

My inclination is to document the fields that aren't state-specific on docs.openelections.net and then have any state-specific stuff in state results repositories.

@benlk
Copy link
Contributor
benlk commented Mar 5, 2017

That makes sense.

After skimming through the docs, the most-likely-looking place to add this is https://github.com/openelections/docs/blob/master/dataentry.md#instructions, but that's not likely to be someplace where people who are using your data will look for descriptions of the column headers. Is there a better place?

After looking at Florida and Arizona, these columns seem common:

updated_at
id
start_date
end_date
election_type
result_type
special
office
district
name_raw
last_name
first_name
suffix
middle_name
party
jurisdiction
division
votes
votes_type
total_votes
winner
write_in
year

@dwillis
Copy link
Contributor
dwillis commented Mar 5, 2017

I think this would be its own section on the docs site, maybe called "Results" with a subsection called "Common Fields"?

benlk added a commit to benlk/docs that referenced this issue Mar 5, 2017
dwillis added a commit that referenced this issue Mar 6, 2017
Create list of common fields for #23
@benlk
Copy link
Contributor
benlk commented Mar 7, 2017

How do you want to handle writing definitions for http://docs.openelections.net/common-fields/ ?

@dwillis
Copy link
Contributor
dwillis commented Mar 7, 2017

In my haze on Sunday I neglected to mention this

DLu pushed a commit to DLu/docs that referenced this issue Sep 11, 2024
* adding navfn and planner server param descriptions

* Update configuration/packages/configuring-navfn.rst

Co-authored-by: Marwan Taher <marokhaled99@gmail.com>

* Update configuration/packages/configuring-navfn.rst

Co-authored-by: Marwan Taher <marokhaled99@gmail.com>
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

3 participants
0