[ckan-dev] CREPs - important proposal!

[Seb Bacon]

On 5 May 2011 16:57, David Read <david.read at okfn.org> wrote:
> On 5 May 2011 16:04, Seb Bacon <seb.bacon at gmail.com> wrote:
>> 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.
>
> I think crep is not used elsewhere because it resembles a profanity
> and is therefore unprofessional. I don't think it is too much of a
> requirement for googlers to go to the trouble of two search terms:
> 'ckan cep'. I guess any term under 7 characters is going to be hard to
> find on google.

OK, then I sense a majority so far for "CEP".

>>>> 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)
>
> It's on the ticket.

Then I need to update my trac-fu, as I expected to get an update via
email when comments were added to 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?
>
> I think it is overly optimistic that someone will throw away work,
> reverting changes, because someone later doesn't agree with something.
> Inertia is too strong.
>
> We actually currently have an ethic where people informally get buy in
> from other people before major changes. Your suggestion might be a
> step back from that - people can just write a ticket and do a day's
> work in a potentially disagreeable direction before many people would
> have a chance to think it through and get back.

Hmm, I see what you mean.  But I guess my intention is that if (with a
little cajoling from a CEP champ) people get into the habit of writing
up a brief proposal, they will actually find it useful, rather than a
drag.

One thing that's important for this to work is that people actually
think it's a good idea, rather than a stupid thing they're being made
to do!

I don't think it's at all a bad thing to do some work as part of
scoping something out.  So I'm not sure where the right compromise is
on this.

>> 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.
>
> +1
>
> Whether my comments are good or bad, it's great to see creps progress
> :-) Cheers Seb,

Well that's two in favour and one against in my mission to get
consensus on the consensus process :)

Seb