OpenSpending Next is the next generation of the OpenSpending platform. All the documentation and specifications for work on Open Spending Next can be found here.
General architecture overview
The following presentation gives an overview of where we are going with OpenSpending Next.
First iteration architecture (MVP)
The initial focus within the roadmap will be on creating a "minimum viable product" version of OpenSpending Next. Primary goals are set out here and in the associated diagram:
- Provide a simple flow for a user to start with a file of spend data and have it visualized in a few of steps
- Provide basic validation of the concepts in OSEP-01
- Provide a good testing ground for iterating on OpenSpending Data Package
- Provide a migration path for all existing data in openspending.org to the new Datastore
Paul Walsh is Technical Lead for OpenSpending Next. For any questions, or to participate, feel free to get in touch directly.
Additionally, the OpenSpending Tech Lead Group is a group of developers and domain experts who are helping Open Knowledge push forward with the new Open Spending roadmap.
Tasks the group is involved with:
- Working through the existing OpenSpending Enhancement Proposals, and making new ones (of course, **anyone** can submit an OSEP, just follow the guidelines here)
- Breaking up the general architecture into sets of specific components that individuals or teams can work on
- Synchronising our plans with other spend data projects - it is a complex area, and one we all want to solve well, so we want to do it together
This is **not** a formal committee that has to sign off on every step along the path. Rather, it will be a group that helps bring the existing ideas into fruition, as well as discuss, debate and enhance them. The group will be limited to 5-10 participants.
Current Tech Lead Group:
Open Spending Enhancement Proposals (OSEPs) are how we introduce large changes to OpenSpending. Anyone can put forward an enhancement proposal.
One of the best ways to contribute right now is by adding data sources to our registry tracker.
- Open a new issue
- Write a brief description of the data
- Provide a link to the data (hosted as flat files on GitHub would be best, if possible)
This allows us to look at the data and see how well it fits with our current assumptions. We can then work together on steps to get the data imported into the flat file DataStore.