openelections-data-tx
openelections-data-tx copied to clipboard
Precinct data file style guidelines, CONTRIBUTING.md
Issues
While reviewing the OpenElections docs, I noticed two areas where my data violated the guidelines:
- The data extracted included countywide and precinct-level races (county courts, precinct chairmanships).
- My precinct numbers in the latter half of my data left padded precincts with zeroes, as that's how they're rendered in the Texas Legislative Council's DistrictViewer.
Should I even bother trying to fix 1?
I can fix 2 easily, but while doing so, ran into a few other minor style questions:
- Which
newline
scheme should files use? There are two main options: a. Bothcarriage return
andline feed
(\r\n). Windows uses this format. b. Justline feed
(\n). Linux and macOS use this format. If you were to ask me, I would prefer option B; Windows can handle files ending in just (\n) without a problem, while some programs on Unix-based platforms sometimes showcarriage return
characters as visible extra characters. - Should there be a
newline
at the end of each file? Currently, many of the files have nonewline
at the end of the file. Again, my opinion is that there should be a newline at the end of each file.
Contributing Guidelines
Another recommendation is that these and other guidelines be codified in a CONTRIBUTING.md
file; that way, anyone who contributes will be aware of them, and we'll need to spend less time fixing style errors after the fact.
If desired, it could probably be possible to eventually enforce style checks on PRs. But that's a topic to be discussed at a later date, if ever.
For the -data-
repos, we're liberal in what we accept. When we produce the files contained in -results-
repos, we limit it to the races we care about, but if people submit converted data that contains other races, that's fine and there's no need to fix what you submitted. But you are right; we should say so in the docs.
In terms of the padded precincts, we don't have a style on those, but I don't think it's necessary to have them.
I agree that option b is preferable for newlines, and that we should have a newline at the end of the file.