[openspending-dev] OpenSpendingJS structure and going forward

Sun May 25 20:19:13 UTC 2014

Rufus Pollock just submitted the following as an issue for OpenSpendingJS:
"Structuring OpenSpending JS code (and this repo) going forward":
https://github.com/openspending/openspendingjs/issues/63

I felt this was better suited for discussion on the developer mailing list.

    Current Situation

/This is my rough understanding and is likely wrong - please correct and
amend!/

README states

    Visualisations and other utils that use data from OpenSpending to
    help people understand where and how money is being spent.

Note in terms of file structure:

    We are currently in a migration stage in order to make contributions
    easier and more consistent, so the code base might be a little
    confusing. The best place to add your visualisation is src/. We're
    in the process of moving all of our visualisations and utils into
    that folder (to make the build process cleaner and simpler).

    External libraries (requirements) are placed in lib/vendor/. There
    are a lot of files there at the moment. Some of those files are old
    versions of these libraries. We're in the process of cleaning these
    files up, removing unused files.

So, basically we have:

  * |src/utils| - common core code
  * |src/visualisations| - visualisations

Sort of deprecated:

  * |lib| Common core code such as JS that wraps the OpenSpending API
  * |app| - various viz / apps (see below)

apps:

|bob  # the query builder (?)
browser # data browser (?)
bubblemap # bubblemap viz
dailybread # dailybread viz
data_table # data_table browser
dimensions-editor # dimensions editor (OS import process) (cf http://nickstenning.github.io/openspending.modeleditor/)
faceter # not sure 
spending-map # not sure but maybe the front page map on OS.org
treetable # not sure ...
|

    The Future

Here's a proposal for discussion:

  * Core JS library (no visualizations) lives in openspending.js (could
    keep openspendingjs name but rename might be useful to symbolize change)
  * Every visualization gets its own separate repo named e.g.
    |openspending.{vizname}.js|

Lastly some process points:

  * We should complete clean-up of this repo asap (possibly in tandem
    with doing the split-out)
  * Anyone can develop a new viz but for it to live in openspending
    orgnanization it needs to "approved" (i.e. checked for quality,
    documentation, and that there is an ongoing maintainer).
  * We document the set of visualizations people can use off-the-shelf
    somewhere prominent

      Why?

  * Core code is more clearly demarcated from apps/viz and can be
    maintained more easily going forward. It also can become a core
    dependency that people can more easily use in their own work without
    getting caught up in viz stuff
  * By splitting out visualizations we make them easier to work on and
    more clearly distinct. Dependencies are also clearer etc.

-- 

Tryggvi Björgvinsson

Technical Lead, OpenSpending

The Open Knowledge Foundation <http://okfn.org>

/Empowering through Open Knowledge/

http://okfn.org/ | @okfn <http://twitter.com/OKFN> | OKF on Facebook
<https://facebook.com/OKFNetwork> | Blog <http://blog.okfn.org/> |
Newsletter <http://okfn.org/about/newsletter>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.okfn.org/pipermail/openspending-dev/attachments/20140525/b9704939/attachment.html>