[ckan-dev] CREPs - important proposal!

Fri May 6 12:44:27 UTC 2011

Hi all,

On Fri, May 6, 2011 at 12:17 PM, David Raznick <kindly at gmail.com> wrote:
> +1 for Cep.   Actually I think they should be call "Sebs" ...

+1 on "Sebs"

>> How about this: we could suggest that as a first step, people fire off
>> an email to ckan-dev with a one paragraph of their idea, and see if
>> the consensus is that they should write up a CEP for it?  This would
>> cover you and Will's concerns quite nicely.  The guideline would then
>> be that *every* idea should start with an email of any length at all
>> to ckan-dev; and CEPs should only be written if requested (or the
>> proposer thinks it's needed anyway)?

Just to chime in a bit: I'm pretty neutral on the idea - I think the
"enhancement protocol" concept applies much better to API projects and
that we should be honest to say that this is a waterfallish
requirements document that we're proposing, but maybe this is needed.
I don't think this fixes many of the core problems we have with CKAN
development, though. Let me explain the challenges that I see:

1) We have many clients with very specific requirements and these are
added as needed. Putting up a CEP for one of those after you're often
in practice under some contractual or personal obligation to do it
anyway seems a bit dishonest to me. If the question is "Should we add
X" and the UK government wants X - we should just have a quick
implementation discussion, not a "consensus-driven" CEP (which implies
some openness wrt. to the requirements IMO).

2) We need a way for the larger community to stay up to date with CKAN
development. The goal here IMO should be short blog posts and good
documentation of the actual implementation. This is not to say we
should not plan new functionality in an open way, just that the
specific problem of keeping people up to date just won't be fixed by
this.

3) We need to recognize and support the emerging workflows in and
around CKAN. These are small, unstable and initially not well defined
practices. Writing a 5 page document on "how people should do
cooperative work in CKAN" at this stage will in its best case miss the
point, in the worst case it may actively harm the use by imposing
rules based on a model that's not likely to be sufficiently inspired
by practice (see TimBLs 5 stars: academic best practices that hurt
reality).

Overall, I think that we might be better served by keeping a more
structured six-month backlog in which larger stories can be added and
are then broken down as their implementation approaches and which will
be priorised by some steering committee, rather than focusing on these
documents. They might look similar, but I'd like to stick with
describing desired functionality in a concise format rather than
formulating "CKAN theories".

- Friedrich