[ckan-dev] CREPs - important proposal!

[Seb Bacon]

On 5 May 2011 15:48, David Read <david.read at okfn.org> wrote:
> On 5 May 2011 14:22, Rufus Pollock <rufus.pollock at okfn.org> wrote:
>> On 5 May 2011 14:16, Seb Bacon <seb.bacon at okfn.org> wrote:
>>> Hi all,
>>>
>>> Following some discussion a couple of weeks ago, please review and
>>> provide feedback on the following: http://trac.ckan.org/ticket/1127
>>
>> I'm +1 but have 2 minor suggestions:
>>
>> a) We use the CEPs named (CREP sounds sort of 'creepy' ;)
>
> Holy crep! I think I prefer Rufus' name.

You'll have seen the justification for it *not* being CEP; I don't
feel attached to CREP but would rather it was something uniqueish
enough to google.

>> b) We do use a versioning repo for the C(R)EPs rather than use trac (i
>> think this will be more useful long term and better for editing
>> substantial stuff -- and easier to transfer into proper docs).
>
> +1 to Seb's suggestion of keeping this in the trac, to lower the
> barrier between small features and CEP features. It also includes them
> in our weekly meetings nicely.

That was my intention.  It also provides an inline place for people to
add quick comments, which bitbucket doesn't.

Also Trac uses reStructuredText, so I don't see it's particularly
harder to transfer into proper docs; and I edited that one in a text
editor and copied it in, so it was dead easy to edit.

> (Will added)
>> The idea itself is a double-edged sword. It will promote stability which is good but can also tend towards rigidity and stagnation which is bad. Each added bit of bureaucracy and process means fewer people will be willing to collaborate or participate in improving the software.
> I think 20 minutes writing a clear CREP and getting agreement is an
> excellent use of time in (say) a few day's work on a feature. I think
> contributions can only improve a proposal.

(where did Will add that? I missed it)

Agreed with what David said.  It is surely a double edged sword but
that's better than a blunt sword :)  All too often I hear about some
great new thing someone has started implementing (or already has
implemented) too late for my input.  This is confusing, a little
demotivating, and will sometimes lead to worse design decisions
(people can always ignore my input when it's rubbish).  In fact, with
a clear, documented mechanism for making a proposal and discussing it,
we should open the gates for *more* people to collaborate or
participate.

> I do worry about lag though, between writing the proposal and being
> able to start work on it. I think the one-day threshold of requiring a
> CREP may be better at two days.
>
> How about suggesting that allowing one working day is a good amount of
> time to allow for initial responses, which might be 'please can we
> talk about this more?' or 'I'd like more time to respond'.

Well, there's nothing to say you can't start work on it as soon as you
want -- even before writing the CREP.  The only implication (which I
can make explicit) is that you can  expect to modify your work in
response to feedback until the CREP is accepted.  I think that's an OK
compromise?

Also, if we were all to get into the habit of writing up a CREP *as
soon as we had the idea*, that would typically allow for plenty of
time for feedback as invariably we have other stuff to actually work
on first.

Seb