Too many rules? (Re: When does one become a committer?)

[Ross Gardler <rg...@opendirective.com>]

On 23 July 2011 22:50, Shane Curcuru <as...@shanecurcuru.org> wrote:
> If people find this work interesting, that's great.  But in terms of rules
> and procedures, sometimes it's fine to not over-document the rules until
> there's a case where they're really needed.

+1000 (I'm referring to the general concept not any specific
discussion about potential rules)

I don't mean to say that the establishment of rules is a pointless
exercise. However, for the majority of software developers rules are
at best a diversion, at worst restrictive.

In general the vast majority of situations you will come up against
(or at least can imagine coming up against) will already have been
experienced somewhere in the ASF at some point. When trying to figure
out how to handle a given situation there will be someone who can help
guide the decision making.

Remember an ASF project is about consensus, not about rules and
regulations. It's about the community deciding what is best for the
community as a whole at that point in time. There is no shortage of
people to help you build consensus by providing options. Even when you
graduate you will be able to call on the experience of everyone here
and everyone in the ASF as a whole.

Ross

Re: Too many rules? (Re: When does one become a committer?)

[Ross Gardler <rg...@opendirective.com>]

On 24 July 2011 01:06, Rob Weir <ap...@robweir.com> wrote:
> On Sat, Jul 23, 2011 at 5:59 PM, Ross Gardler
> <rg...@opendirective.com> wrote:
>> On 23 July 2011 22:50, Shane Curcuru <as...@shanecurcuru.org> wrote:
>>> If people find this work interesting, that's great.  But in terms of rules
>>> and procedures, sometimes it's fine to not over-document the rules until
>>> there's a case where they're really needed.
>>
>> +1000 (I'm referring to the general concept not any specific
>> discussion about potential rules)
>>
>> I don't mean to say that the establishment of rules is a pointless
>> exercise. However, for the majority of software developers rules are
>> at best a diversion, at worst restrictive.
>>
>
> For the vast majority of software developers, unit tests and coding
> standards are also a diversion, and at worst restrictive.  So  what?

He He - fair comment. Amazingly I blogged about exactly that on Friday
http://osswatch.jiscinvolve.org/wp/2011/07/22/writing-good-software/

However, in the context I intended this email the above interpretation
is a diversion from my key point. It's not possible to write rules
that encompass everything that will occur and tryng to generalise on
rules, such as how long to leave committer invitations open, is
dependent on why those invitations were made in the first place.

> The PPMC has oversight responsibility for the project. This is
> addition to roles we might individually also have as software
> developers.   Written rules are tools, and can be a useful one at
> that.  ASF certainly finds them to be useful on occasion.  So have
> other Apache projects.

Sure. as I tried to convey, my comments are not about *every* rule
that the PPMC might want to put into place.

>> In general the vast majority of situations you will come up against
>> (or at least can imagine coming up against) will already have been
>> experienced somewhere in the ASF at some point. When trying to figure
>> out how to handle a given situation there will be someone who can help
>> guide the decision making.
>>
>
> Great.  I'd like to think that a good rule is based on experience and
> not just made up out of thin air.  But as we've seen from my
> hypothetical question about when a committer becomes a committer,
> different people have different experiences and different opinions.

On that specific case I don't agree. I see consensus in that thread,
it's been expressed in different ways, but there appears to be
consensus on the timing.

> So this PPMC needs to chart its own course on this, synthesizing what
> wisdom we can collect from others' experience.  But once we've done
> that, I can think of no better way of ensuring that such wisdom is
> applied consistently going forward than writing it down as a rule.

In some cases this makes sense, one example would be coding standards.
But in community issues it is unlikely that two cases will be the
same, no set of rules can encompass all eventualities. I am only
seeking to caution against trying to codify these more nuanced
situations with rules and then claiming they can be applied uniformly
to every similar situation (and I believe that was Shanes original
intent).

Ross

Re: Too many rules? (Re: When does one become a committer?)

[Rob Weir <ap...@robweir.com>]

On Sat, Jul 23, 2011 at 5:59 PM, Ross Gardler
<rg...@opendirective.com> wrote:
> On 23 July 2011 22:50, Shane Curcuru <as...@shanecurcuru.org> wrote:
>> If people find this work interesting, that's great.  But in terms of rules
>> and procedures, sometimes it's fine to not over-document the rules until
>> there's a case where they're really needed.
>
> +1000 (I'm referring to the general concept not any specific
> discussion about potential rules)
>
> I don't mean to say that the establishment of rules is a pointless
> exercise. However, for the majority of software developers rules are
> at best a diversion, at worst restrictive.
>

For the vast majority of software developers, unit tests and coding
standards are also a diversion, and at worst restrictive.  So  what?
The PPMC has oversight responsibility for the project. This is
addition to roles we might individually also have as software
developers.   Written rules are tools, and can be a useful one at
that.  ASF certainly finds them to be useful on occasion.  So have
other Apache projects.

> In general the vast majority of situations you will come up against
> (or at least can imagine coming up against) will already have been
> experienced somewhere in the ASF at some point. When trying to figure
> out how to handle a given situation there will be someone who can help
> guide the decision making.
>

Great.  I'd like to think that a good rule is based on experience and
not just made up out of thin air.  But as we've seen from my
hypothetical question about when a committer becomes a committer,
different people have different experiences and different opinions.
So this PPMC needs to chart its own course on this, synthesizing what
wisdom we can collect from others' experience.  But once we've done
that, I can think of no better way of ensuring that such wisdom is
applied consistently going forward than writing it down as a rule.

> Remember an ASF project is about consensus, not about rules and
> regulations. It's about the community deciding what is best for the
> community as a whole at that point in time. There is no shortage of
> people to help you build consensus by providing options. Even when you
> graduate you will be able to call on the experience of everyone here
> and everyone in the ASF as a whole.
>

Yes, yes, yes.  But a rule is one way in which consensus can be
recorded.  It is not different than consensus.  It is about making
that consensus be transparent, reusable and consistent, so project
members (and non project members) can have reasonable expectations
about future actions and decisions.  This has been true since
Runnymede and King John.  It is not sufficient to have consensus.  We
also need to be seen as being fair, consistent and predictable.  This
is important for members as well as non-members.  A capricious
consensus helps no one.

-Rob

> Ross
>