[ckan-dev] CREPs - important proposal!

[Seb Bacon]

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