[ckan-dev] CREPs - important proposal!

Fri May 6 14:45:08 UTC 2011

On 6 May 2011 13:44, Friedrich Lindenberg <friedrich.lindenberg at okfn.org> wrote:
> 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 think as long as a CEP details small enough chunks, and reacts to
change, it is suitably agile. The CEP template is a little traditional
in style though. Modern analysis with use cases / abstraction etc. is
a challenge. However, I think rather than be too strict/pushy on the
template, I'd prefer people to express the basics how they want and if
needed, the team can highlight any missed use cases or future
possibilities etc.

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

I have a lot more faith in an open process than any form of top-down
committee directing, because it actually requires you to explain plans
and build consensus. Direction from above should only be to support
the team's work, direct priorities and contribute to debate through
excellent and persuasive arguments.

It is not a lot of discipline/effort for someone to propose: change X
because of Y's new requirement Z and ensuring W still works. The key
benefit is it might well prevent hours of grief (for several reasons)
further down the line for other team members.

David

> They might look similar, but I'd like to stick with
> describing desired functionality in a concise format rather than
> formulating "CKAN theories".
>
> - Friedrich
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>