[openspending-dev] Dimensions editor is broken

[Rufus Pollock]

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

> 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.
>

Understood. I had also encountered real bugs and not just UX bugs. Can you
open an issue detailing the problem and especially the schema issues. Also,
as always, any patches are welcome and would get deployed.


> 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.
>

Its a tough one as its clear that people are successfully uploading files -
if you track the uploads about one dataset is added every day or so - and
we don't want to discourage those people. The situation has not really
changed much over the last 18m. That said, having some banner indicating
that active work is going on to create a new ETL setup could be useful -
though it would be more useful when actually in alpha.

Rufus

- 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
>>
>
>


-- 

*Rufus PollockFounder and President | skype: rufuspollock | @rufuspollock
<https://twitter.com/rufuspollock>Open Knowledge <http://okfn.org/> - see
how data can change the world**http://okfn.org/ <http://okfn.org/> | @okfn
<http://twitter.com/OKFN> | Open Knowledge on Facebook
<https://www.facebook.com/OKFNetwork> |  Blog <http://blog.okfn.org/>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/openspending-dev/attachments/20150419/cd383edb/attachment-0002.html>