opendatainitiative / opendatainitiative.github.io Goto Github PK

Project: Policy
Part 2 of 3 mass open data projects
Standard data import through API support of Storage project
Configurable policy rules using datalog
Policy results through standardized API
Existing projects: openstack Congress

ugly, please change

Manual process (this is easy while the number of contributors is low)

1. There are three active projects. opendatalegislation and transparency project data is integrated in the opendatainitiative.github.io project that creates the https://opendatainitiative.github.io/ website.
2. Each friday, each active project increments it's active branch revision number by 0.X.0 (tenth)
3. If your changes are small and need to pushed before the end of the week, use branch revision number incremented by 0.0.Y (hundredth)
4. Each contributor synchronizes their local repositories with the remote before starting work
5. Review the issues. Bugs are highest priority and may be quick work. Enhancements may take days to weeks.
6. Work the changes locally. Keep your work to a single problem or issue
7. Verify the changes fixes problems and doesn't create new problems by running Jekyll locally. If you are working on the opendatalegislation or transparency project branch, you will need to copy your changes into the opendatainitiateve.github.io local repository to verify functionality. Make sure your changes are not in the master branch, rather in the next revision branch.
8. When the branch changes are complete, push the branch to the repository. The commit message needs to include the issue (if any) that it closes or updates, e.g. "closes bug Correct CA legislation review first line to not public #35".
9. If the contributor is a member of the Core Contributor team, the pushed changes can be merged with the current branch immediately.
10. For everyone else, they need to create a Pull Request. One or more of the Core Contributor team member will review the change before the end of the week. Depending on the change, it may get merged with the master branch, request changes to the commit, request more explanation, delayed to a future revision, or declined.
11. When a Core Contributor merges pushed changes to a branch, any referenced issues will be updated and closed if appropriate.
12. When a branch is complete, a Core Contributor will take the branch and merge the revision branch with the master branch.
13. During the week, a Core Contributor can decide a 0.0.Y hundredth branch revision needs to be published of in any of the opendatainitiative projects
14. At the end of the business week (Friday), a Core Contributor will take the latest merged branch 0.X.Y, 0.J.K revisions of the opendatalegislation and transparency project data, copy the files into the branch 0.B.C revision of the opendatainitiative.github.io project. This consists of matching the changes in each project since the last merged branch to the current branch. Each of these files gets copied into the opendatainitiative.github.io project. The resulting local website will be double checked for errors. If the site fails to load or has other serious errors, the opendatainitiative.github.io project branch 0.B.C revision can be delayed until the end of the week (Sunday). If the end of the week opendatainitiative.github.io project branch 0.B.C revision is missed, then the revision is postponed until the following end of the business week.
15. For the opendatainitiative.github.io project branch 0.B.C commit message, use each of the project branch URL
16. After the all the project branches are updated, now the master branches need to be merged with the each of the latest branches. Once completed, each project latest branch and master must be pointing at the same, most recent change.
17. Create the next revision branch in each project and change the focus to that branch, so your local changes always land in the correct place.

Future

1. Code part or all of these steps to eliminate errors, speed development time, and allow more time to create unit and integration tests
2. Continue to allow local CI toolchain while running the CI toolchain remotely. Each push would get some basic tests run, results logged, and published for core contributors to review.

display as a progress bar of open verses closed bugs just below the issue progress bar

about images are tiny!

1. Github commits by repo
2. Open linked issues
3. Comment at top
4. Drop notes into repo dir

future

1. Create tarball.opendatainitiatve.io
2. script the process

layout, font, headers, logo, and buttons

https://jekyllrb.com/docs/pagination/

https://jekyllrb.com/docs/templates/

{% highlight ruby linenos %}
def foo
puts 'foo'
end
{% endhighlight %}

1. Work on navbar
2. Discussion iframe plus pending long term issues
3. Move project work from resources
4. Most of page shows issues, projects
5. Small upper right corner shows discussion with iframe of archive, how we work
6. Each item points to issue
7. Assign hours to issue
8. All projects in one place
9. Share this with ahmed and university

Liquid Warning: Liquid syntax error (line 15): Expected id but found number in "{{name.2016-pirg-score | times: 0.80 | plus: name.accessibility | plus: name.downloadability | round: 1 }}" in transparency.md
Liquid Warning: Liquid syntax error (line 19): Expected id but found number in "{{ name.2016-pirg-score }}" in transparency.md

1. PIRG and Sunlight Foundation have expressed interest in co-organizing
2. Focus on Livermore, BART, and then Walnut Creek for three separate events
3. I have reached out to CA Assembly Rep Baker to use these events as a springboard to get attention to open data legislation and the 'state' of government financial transparency in CA

Data Coalition generally runs these. They have a DC June 2018 date planned.
May 2018 is the ideal date for Ohio due to 2018 being an election season.
We need

1. sponsors
2. speakers
3. session set aside for DataOhio meeting
4. Organization to act as the bank and AR
5. Schedule
6. Site
7. Lodging
8. Registration

Project: Storage
Part 1 of 3 mass open data projects
Import mass PDF as tokens stored in NoSQL
Import simple formats and XBRL
Other common RDBMS export formats or interfaces?
Create JSON, XBRL, and other formats from converted data sets for export
Provide standardized API access
Existing projects: pdftotext, pdfbox, pandoc

1. for code review, collaboration
2. proving out project management tools for the rest of ODI projects
3. adding unit tests
4. plan on adding integration tests for ODI 1.0 future releases

pull in the active and closed issue counts to create a milestone progress bar

https://jekyllrb.com/docs/templates/
{{ page.tags | sort }}
{{ site.posts | sort: 'author' }}
{{ site.pages | sort: 'title', 'last' }}

transparency and legislation pages will have their project revision followed by the opendatainitiative.github.io project revision

the border is hard set, while the content does not dynamically scale

Bring up the contributor.md instructions page. Dynamic link to the editable page. Focus on simplest way to get first time contributors to push their edits to github for review.

Project: Visualization
Part 3 of 3 mass open data projects
Provide standard visualization through Storage and Policy project APIs
Search results
Existing projects: Tableau, Superset : Python, React, Redash: Python, AngularJs, Metabase: Clojure, React