[openspending-dev] Dimensions editor is broken

[Friedrich Lindenberg]

Ok, just to be clear: I wasn't referring to some abstract sort of
brokenness of the dimensions editor, but to two concrete bugs in the loader
that have surfaced wrt the LHM dataset, one of which appears to break
schema integrity of the underlying database.

I understand your explanation. If the OpenSpending platform as it currently
operates is no longer maintained, would it make sense to place a banner
somewhere on the site that indicates this; as well as possibly disabling
the data manager entirely? I get two or three people a month who want to
contribute to Offener Haushalt, and I'd rather be upfront if that isn't an
option any more.

- Friedrich


On Sat, Apr 18, 2015 at 10:53 PM, Rufus Pollock <rufus.pollock at okfn.org>
wrote:

> 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/20150419/7a666400/attachment-0002.html>