[ckan-dev] CREPs - important proposal!

[Seb Bacon]

2011/5/6 Adrià Mercader <amercadero at gmail.com>:
> I agree with the idea of some kind of formal process to
> propose/discuss/publicize new features, being called CEP, CREP, RFC or
> whatever is chosen.
> However, I'm with Will in trying to minimize "bureaucracy". I don't
> think I personally can write a CEP as complete as the one one proposed
> in the template in 20 minutes, and probably that could discourage some
> external developer willing to contribute to CKAN.

That one took me more than an hour, so you're right.

> Maybe we should
> define the minimum sections that should be filled in the "draft" stage
> and create a less scary template for them.

This is a good idea.  There's an obvious sliding scale of detail
required which I think most people should instinctively understand.
The bigger the change, the more detail there should be.  I think an
hour spent writing up a proposal would be an hour extremely well spent
for something that will take many days to implement.  In fact I would
expect it should often *save* time -- I have a tendency to dive in and
start coding which isn't always the best idea.  On the other hand, it
would be mad to spend more than 10 minutes writing up something that
will take a day to implement.

Not everything would require a CEP, even things that would take many
days to implement; it's just for things that people are likely to have
opinions on or specialist knowledge about.  This is always going to be
a matter of judgement.

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

> Will the CEPs include proposals for just CKAN core or for extensions too?

I think it would only be considered essential for CKAN core, but
should be encouraged for extensions as a protocol for getting
discussion around them (especially for extensions that are written by
the core team, as these are more likely to end up being packaged as a
default CKAN somehow).  The intention is partly to improve code design
quality, but mainly to improve communication.  So I think perhaps the
"email everything first" guideline might apply here too.

Thanks

Seb


> 2011/5/5 Seb Bacon <seb.bacon at gmail.com>:
>> On 5 May 2011 16:58, William Waites <ww at styx.org> wrote:
>>> * [2011-05-05 16:04:31 +0100] Seb Bacon <seb.bacon at gmail.com> écrit:
>>>
>>> ] (where did Will add that? I missed it)
>>>
>>> In the Trac.
>>>
>>> ] All too often I hear about some
>>> ] great new thing someone has started implementing (or already has
>>> ] implemented) too late for my input.
>>>
>>> I agree this is a problem - I found out to my suprise about some
>>> interesting planned changes from James just by accident because he
>>> happend to be in town over the past few days. However a less-formal
>>> "discuss it or send a note to the mailing list" would fix this as
>>> well.
>>
>> "discuss it" wouldn't fix it.  Things are already being discussed
>> (I've chatted with James about   interesting planned changes on Skype,
>> for example).  That's not the problem; the problem is that they're not
>> being discussed in a manner that actively encourages the widest input
>> (e.g. from the community as a whole).  And are my interesting planned
>> changes the same as your interesting planned changes?
>>
>> "send a note to the mailing list" is so vague I don't think people
>> would do it.  IMO we *need* people to write out a brief overview and
>> plan for major changes so we can *all* discuss it if we want.  I don't
>> see that giving them a suggested structure for the overview and saying
>> they should write something up as a default is masses of bureaucracy.
>> I do, of course, see your point, but I can't see the alternative,
>> which I think is essentially do nothing, as a good option (but please
>> do flesh out the alternative a bit more as I may be charicaturising it
>> :)
>>
>>> The formal process of PEP and DEP are not really comparable to CKAN
>>> because the scope and requirements are vastly different. Python and
>>> Debian have to support third-party developers that expect API
>>> stability through and through in the long term. CKAN is a web
>>> application. Its development and user communities are orders of
>>> magnitude smaller. Its code base is orders of magnitude smaller.
>>> There are vanishingly few third party modules that depend in any way
>>> on the code. It seems to me that this kind of process would drag
>>> people down farther into document production when they would be better
>>> off and happier making improvements to the software.
>>
>> When you say they're not really comparable, it depends what you're
>> comparing.  You, I think, are comparing the technical systems which
>> are subject to the proposal workflows.  I'm comparing the human
>> communication problems which are subject to the proposal workflows.
>> Part of the intent of  the PEP process is to give an assurance of
>> stablity, but I'd argue that's not their main purpose.  PEPs are often
>> about adding entirely new features, the backwards compatibility of
>> which is vital, but a small part of the overall discussion.  To me,
>> they are about having a clear, open discussion about the
>> implementation and/or desirability of new features.
>>
>>
>>> I would support a more formal process in some important areas - like
>>> changes to the JSON protocol because that affects third parties and
>>> interoperability. Changes to the JSON protocol can break things that
>>> are not under the control of the CKAN developers so more care is
>>> needed.
>>>
>>> I write this knowing that it will likely be the minority viewpoint.
>>
>> And I write this in the dogged hope that I can change your mind :)
>>
>> Seb
>>
>> _______________________________________________
>> ckan-dev mailing list
>> ckan-dev at lists.okfn.org
>> http://lists.okfn.org/mailman/listinfo/ckan-dev
>>
>



-- 
skype: seb.bacon
mobile: 07790 939224
land: 01531 671074
web: http://baconconsulting.co.uk