The goal of this document is to lay out timelines and procedures for developing drafts of the Fiscal Data Package specification.
Fiscal Data Package is a lightweight, descriptive data model that can be used to describe and compare a wide variety of fiscal data. Therefore, we encourage feedback and contributions from all types of fiscal data producers, intermediaries (e.g. journalists and researchers), as well as consumers.
Rufus Pollock of Open Knowledge International (@rgrp) is acting as the current "Czar" of the standard, providing high-level guidance and overseeing its development. Dan Fowler, Developer Advocate Open Knowledge International (@danfowler), is acting as the current "standards team", supporting the day-to-day progression of the specification, responding to comments, and ensuring adherence to the timelines and procedures described in this document.
- Sign up for a GitHub account if you don't already have one
- Learn the basics of submitting an issue on GitHub
- Familiarize yourself with the Data Package and Tabular Data Package specifications, upon which Fiscal Data Package is based
Upon receipt of a new issue, the standards team will tag the issue as one of:
- Discussion
- Meta
The default state for a new issue is Discussion
. This is especially so if the issue relates to more than one specific aspect of the standard. The Meta
tag is reserved for issues "about" the standards process (e.g. this contribution document). This initial assessment of the issue should happen within 3 working days, though more likely within 1 working day.
While an issue is in the Discussion state, interested parties are invited to provide feedback on the merits of the issue and how to properly address it. We aim for broad consensus on resolution, but in the interests of rapid iteration, we intend to keep issues open for discussion no longer than 10 working days. If a clear resolution has been broadly agreed within this time period, a new issue specifically outlining the proposed change will be created by a member of the standards team and tagged as one of the following:
- Proposal (breaking change): for major changes that would break existing implementations
- Proposal (enhancement): for minor, non-breaking changes
- Proposal (trivial): for minor formatting, grammar, or other clarification of existing text
This issue is itself presented for discussion for no longer than 5 working days. Note: a “trivial” Proposal issue may be raised without any previous discussion.
Discussion may also lead to an acknowledgement that some further work must be done to aid resolution. This will lead to a Discussion issue tagged with one of:
- Example Needed
- Clarification Needed
- Research Needed
An additional 5 working days for resolution is given to discussions tagged as such.
If no clear resolution has been achieved in the time allotted to the discussion, it will be tagged as one of:
- Wontfix
- Duplicate
- Invalid
And closed with justification provided.
Once a concrete proposal has been submitted, a Pull Request directly addressing that proposal can be submitted. A Pull Request is a concrete set of changes to the text that ready to merge into the existing text of the specification (https://github.com/openspending/fiscal-data-package/blob/master/spec/index.md)
Starting at version 0.3.0., when the core of the standard is more stable, we will likely move to Semantic Versioning 2.0.0.
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
- General GitHub documentation
- GitHub pull request documentation
- #openspending IRC channel on freenode.org (Archive)
- OpenSpending Discussion List