[ckan-dev] CREPs - important proposal!

[Adrià Mercader]

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. Maybe we should
define the minimum sections that should be filled in the "draft" stage
and create a less scary template for them.

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


Adrià



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
>