[openspending-dev] Dimensions editor is broken

Sat Apr 18 20:53:41 UTC 2015

On 18 April 2015 at 08:48, Friedrich Lindenberg <friedrich at pudo.org> wrote:

> Hey guys,
>
> so I've been trying to help a guy add a dataset to OffenerHaushalt, but it
> seems the dimensions editor is just full of bugs on this one. There's at
> least two: one where the loader tries to access a non-existing row, and one
> where the schema doesn't get dropped when altering the model:
>
> https://openspending.org/lhm_20150415/editor
>
> Do you have any intention to fix this or is all energy on the BDP stuff
> now?
>

There's three parts to that:

1. Who is "you" in the "you have any intention". Do you mean will someone
like Tryggvi or I or ...?

2. Should "we" in some general sense fix this? My sense is probably not -
rather let's focus on building the next version of the improved import
system as fast as possible.

Worth setting out some reasoning for this.

Dimensions editor has been "broken" for a long time - in fact its the
brokenness of the dimensions editor both in terms of specific bugs and just
UX that motivates quite a lot the current new model (at least for me).
Watching folks struggle again and again with the import process at the open
data maker nights made it clear we need to improve that (to be clear I'm
not criticising the current effort: it was a major improvement over what we
had before and this is not easy). Thinking about how we want to improve led
to thinking about the overall import process (e.g. checking data at the
start) and to the system architecture (e.g. datastore, code modularization
- e.g. i should be able to tweak and test the dimensions editor without
installing the whole stack ... - i've actually tried this about 18m ago in
order to fix my own bugs with dim editor and failed)

So right now, whilst painful I think we have to leave the current system as
is (as we have done for ~18m) and focus all our possible energies on
getting an improved system up and running (reusing where possible existing
components - e.g. dimensions editor if split out could be reused ...?)

BTW: if interested there's some in progress user stories around import
process here
<https://docs.google.com/a/okfn.org/document/d/100y9bbwuQTWJRjFG4NS_lkR4ZgLZ9jJBu35Bw6qInjI/edit#>
plus
a(and a very in progess top-level user stories here
<https://docs.google.com/a/okfn.org/document/d/1PerSrYpdCUPrQH5M3kZD_UnIaPhZ9RCmjH0BI4LoP7Y/edit#>
)

3. What is (all) the energy on (e.g. is it BDP)? Strictly, the energy is
not on "BDP" per se - rather its on implementing OSEP 1 - and, since that's
everything, more specifically, to start with I think focus could/should be
a great (new) import workflow (this discussion of roadmap prioritisation
should be a separate thread and i have a booted a thread on the forum for
this <http://discuss.okfn.org/t/2015-near-term-roadmap-for-openspending/264>
)

Aside: In fact, i think it would be useful to put "BDP" per se to one side
(though we almost certainly will build on that spec in some way). BDP is
just a spec whose role is to help us get some other useful thing done. In
addition, its almost certain we need to extend BDP in some way to support
OS immediate use cases - see e.g.
http://discuss.okfn.org/t/openspending-data-package-structure/239

Rufus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/openspending-dev/attachments/20150418/f196faeb/attachment-0002.html>