You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2002/11/25 11:59:38 UTC
[proposal] development process
quoting Sam Ruby:
----------------
The alternative is to require consensus. Strive always to do as Noel so
eloquently described with the words "we did it as a community, we
support it as a community, and if necessary we'll fix it as a
community.". Achieving this will require changes in behavior from
pretty much everybody here. It will also be hard work. And require
much patience. And endurance.
----------------
These points have been brought up several times over the past few weeks.
My proposals are that, for the immediately foreseeable future, we as a
community simply do the following:
No Veto
-------
We will refrain from the use of vetoes on medium to long-term issues on
all code in all avalon cvses.
+1 from me
Isolate controversy
-------------------
We will place all code that might be controversial in the avalon-sandbox
cvs until there is a consensus (ie it becomes non-controversial).
+1 from me
Consensus
---------
we will require consensus on the issues that would normally be subject
to majority vote.
+1 from me
Comments on these proposals
---------------------------
- "immediate foreseeable future" would be until there is consensus that
the "community issues" we're looking at currently have been resolved.
- I think all standing vetoes (but unresolved) should be abandoned too,
as should all declarations of invalid stainding vetoes, revolutions,
etc. ie rather than discuss how we messed this up in the past, I suggest
we dump all that static from our thoughts. The subjects of these past
discussions can be (should be!) brought up again if still valid, but we
should look at the past vetoes only as "there is no consensus yet". Note
controversial and revolution code would go into the sandbox.
- IIUC, these proposals are something that the PMC could decide upon and
impose upon the rest of the community if the PMC feels it necessary to
do so. I'd rather see that we actually have community consensus that
this stuff is a good idea than have a "some up-high committee" (as I
think some, incorrectly, perceive the PMC ;) impose something like this.
- I'm not calling for votes from any particular "body". I'd like to
encourage everyone who has anything to do with avalon to express an
opinion without worrying about "binding" vs "non-binding".
- these proposals are specifically not about any kind of permanent setup
or intended as being part of any charter or bylaw.
- the reasoning behind these proposals is long, and it would be
difficult to summarize completely. Fact of the matter is that in recent
history, we've had lots of vetoes, revolutions, and other stuff, which
has been hurtful to the community. We need to move away from that
development process, make it more fun to be here again.
- note consensus can still be lazy!
- I don't want to block use of vetoes based on stuff like security
issues. They're a safety net in this regard.
cheers,
- Leo Simons
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] development process
Posted by Peter Donald <pe...@realityforge.org>.
On Tue, 26 Nov 2002 00:16, Greg Stein wrote:
> It is quite easy to release crap, realize that later, and want to change
> it. Don't let history get in the way of what is Right. Pay mind to your
> users, but also pay mind to what the code really needs. Is it Goodness?
> Or does it need to change in some way?
Even if it sucks we need to provide a migration path. There are several things
that we have released in the path that are definetly not something we still
recomend. However until we get a replacement in position we can not deprecate
the product.
--
Cheers,
Peter Donald
-----------------------------------------------------------
Don't take life too seriously --
you'll never get out of it alive.
-----------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] development process
Posted by Greg Stein <gs...@lyra.org>.
In article <3D...@apache.org>, "Stephen McConnell"
<mc...@apache.org> wrote:
>...
>>>I do not agree that this is the dumping ground for contentious code. It
>>>was my understanding that this is the area for non-released code,
>>>experiments, and evolving content. I don't think we should change that.
>>
>>agreed. However, the things I think that are currently contentious are
>>unreleased evolving experiments :D
>...
> If something is released it's non-contentious. If something is not
> released - then its sandbox - and its auto contentious because it hasn't
> been through a release process. Contentious or otherwise is a very
> subjective thing - I don't think anything I am working on is
> contentious, but I know some people think otherwise. That's why we
> delineate things through a release process is important.
I don't see that "is released" implies non-contentious. Are you trying to
say that just because one hunk of code happened to get popped out to
users, then it is suddenly Right? No... that doesn't follow at all.
It is quite easy to release crap, realize that later, and want to change
it. Don't let history get in the way of what is Right. Pay mind to your
users, but also pay mind to what the code really needs. Is it Goodness?
Or does it need to change in some way?
I can certainly offer up a lot of httpd/apr code that was total crap, yet
it was released. But I suppose "just knowing" is more important than
having a pointer :-)
Cheers,
-g
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] development process
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
>On Mon, 2002-11-25 at 12:33, Stephen McConnell wrote:
>
>
>>Leo:
>>
>>I understand and support the principal you are putting forward in you email.
>>
>>
>
>all I want, really :)
>
>
>
>>I don't support the approach.
>>
>>Following the transition there was a lot of discussion about
>>reorganization - to-date only a small number of the issues have been
>>addressed - there are things that need to be done. Instead of padding
>>the cells with cotton-wool, isn't it a better idea to pull together some
>>level of position - identification of issue/actions, etc. Keep things
>>under [PROPOSAL] state being maybe a little more formal
>>
>>
>
>how about informal but distinctive ;)
>
It works for me.
>
>>about
>>distinguishing between discussion versus decision - where discussion is
>>done to death - and theres consensus - we can move forward with a [VOTE]
>>- where the discussion is problematic - lets a least get to the point of
>>knowing this.
>>
>>
>
>okay.
>
>
>
>>One more point - avalon-sandpad.
>>
>>
>
>sandbox ;)
>
>
:-)
>
>
>>I do not agree that this is the dumping ground for contentious code.
>>It was my understanding that this is the area for non-released code,
>>experiments, and evolving content. I don't think we should change that.
>>
>>
>
>agreed. However, the things I think that are currently contentious are
>unreleased evolving experiments :D
>
>also, what I think is that we should make sure that
>
>ContentiousCode extends UnreleasedCode {}
>
I don't really follow the extension logic here - but aside from that I
think I disagree with the implications.
;-)
If something is released it's non-contentious.
If something is not released - then its sandbox - and its auto
contentious because it hasn't been through a release process.
Contentious or otherwise is a very subjective thing - I don't think
anything I am working on is contentious, but I know some people think
otherwise. That's why we delineate things through a release process is
important.
Cheers, Steve.
>cheers,
>
>- Leo
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] development process
Posted by Leo Simons <le...@apache.org>.
On Mon, 2002-11-25 at 12:33, Stephen McConnell wrote:
> Leo:
>
> I understand and support the principal you are putting forward in you email.
all I want, really :)
> I don't support the approach.
>
> Following the transition there was a lot of discussion about
> reorganization - to-date only a small number of the issues have been
> addressed - there are things that need to be done. Instead of padding
> the cells with cotton-wool, isn't it a better idea to pull together some
> level of position - identification of issue/actions, etc. Keep things
> under [PROPOSAL] state being maybe a little more formal
how about informal but distinctive ;)
> about
> distinguishing between discussion versus decision - where discussion is
> done to death - and theres consensus - we can move forward with a [VOTE]
> - where the discussion is problematic - lets a least get to the point of
> knowing this.
okay.
> One more point - avalon-sandpad.
sandbox ;)
> I do not agree that this is the dumping ground for contentious code.
> It was my understanding that this is the area for non-released code,
> experiments, and evolving content. I don't think we should change that.
agreed. However, the things I think that are currently contentious are
unreleased evolving experiments :D
also, what I think is that we should make sure that
ContentiousCode extends UnreleasedCode {}
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] development process
Posted by Stephen McConnell <mc...@apache.org>.
Leo:
I understand and support the principal you are putting forward in you email.
I don't support the approach.
Following the transition there was a lot of discussion about
reorganization - to-date only a small number of the issues have been
addressed - there are things that need to be done. Instead of padding
the cells with cotton-wool, isn't it a better idea to pull together some
level of position - identification of issue/actions, etc. Keep things
under [PROPOSAL] state being maybe a little more formal about
distinguishing between discussion versus decision - where discussion is
done to death - and theres consensus - we can move forward with a [VOTE]
- where the discussion is problematic - lets a least get to the point of
knowing this. If divisive subjects are directly related to out
restructuring then that is something the PMC is responsible for dealing
with if we (the community) cannot reach finalization on particular issues.
Let's not be afraid of what we have established - lets be respectful
about the fact that we are changing things in Avalon - let's attempt to
resolve things along the lines you describe (with the exception on one
point below) - but lets also hold in equal respect the right of everyone
based on policies and procedures established here in Apache.
One more point - avalon-sandpad.
I do not agree that this is the dumping ground for contentious code.
It was my understanding that this is the area for non-released code,
experiments, and evolving content. I don't think we should change that.
Cheers, Steve.
Leo Simons wrote:
>quoting Sam Ruby:
>----------------
>The alternative is to require consensus. Strive always to do as Noel so
>eloquently described with the words "we did it as a community, we
>support it as a community, and if necessary we'll fix it as a
>community.". Achieving this will require changes in behavior from
>pretty much everybody here. It will also be hard work. And require
>much patience. And endurance.
>----------------
>
>These points have been brought up several times over the past few weeks.
>
>My proposals are that, for the immediately foreseeable future, we as a
>community simply do the following:
>
>No Veto
>-------
>We will refrain from the use of vetoes on medium to long-term issues on
>all code in all avalon cvses.
>
>+1 from me
>
>Isolate controversy
>-------------------
>We will place all code that might be controversial in the avalon-sandbox
>cvs until there is a consensus (ie it becomes non-controversial).
>
>+1 from me
>
>Consensus
>---------
>we will require consensus on the issues that would normally be subject
>to majority vote.
>
>+1 from me
>
>
>Comments on these proposals
>---------------------------
>- "immediate foreseeable future" would be until there is consensus that
>the "community issues" we're looking at currently have been resolved.
>
>- I think all standing vetoes (but unresolved) should be abandoned too,
>as should all declarations of invalid stainding vetoes, revolutions,
>etc. ie rather than discuss how we messed this up in the past, I suggest
>we dump all that static from our thoughts. The subjects of these past
>discussions can be (should be!) brought up again if still valid, but we
>should look at the past vetoes only as "there is no consensus yet". Note
>controversial and revolution code would go into the sandbox.
>
>- IIUC, these proposals are something that the PMC could decide upon and
>impose upon the rest of the community if the PMC feels it necessary to
>do so. I'd rather see that we actually have community consensus that
>this stuff is a good idea than have a "some up-high committee" (as I
>think some, incorrectly, perceive the PMC ;) impose something like this.
>
>- I'm not calling for votes from any particular "body". I'd like to
>encourage everyone who has anything to do with avalon to express an
>opinion without worrying about "binding" vs "non-binding".
>
>- these proposals are specifically not about any kind of permanent setup
>or intended as being part of any charter or bylaw.
>
>- the reasoning behind these proposals is long, and it would be
>difficult to summarize completely. Fact of the matter is that in recent
>history, we've had lots of vetoes, revolutions, and other stuff, which
>has been hurtful to the community. We need to move away from that
>development process, make it more fun to be here again.
>
>- note consensus can still be lazy!
>
>- I don't want to block use of vetoes based on stuff like security
>issues. They're a safety net in this regard.
>
>cheers,
>
>- Leo Simons
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] development process
Posted by Leo Simons <le...@apache.org>.
On Mon, 2002-11-25 at 11:59, Leo Simons wrote:
<snip type="lots of blaat"/>
This thread is counterproductive, sorry for real bad wording guys. I can
see people who clearly agree with me (and everyone else) on sentiment &
principle feeling a need to respond something I put really badly.
here's what I perhaps should have said:
there has been a lot of talk about how vetoes have been used and
misused, how it will be good for the community to go forward based on
consensus if at all possible, etc etc.
I just thought I'd bring this up in a separate thread so unaware people
can be made aware and respond if they disagree with the general
sentiment.
> quoting Sam Ruby:
> ----------------
> The alternative is to require consensus. Strive always to do as Noel so
> eloquently described with the words "we did it as a community, we
> support it as a community, and if necessary we'll fix it as a
> community.". Achieving this will require changes in behavior from
> pretty much everybody here. It will also be hard work. And require
> much patience. And endurance.
> ----------------
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] development process
Posted by Leo Simons <le...@apache.org>.
On Mon, 2002-11-25 at 12:33, Paul Hammant wrote:
> > No Veto
> > -------
> > We will refrain from the use of vetoes on medium to long-term issues on
> > all code in all avalon cvses.
> >
> > +1 from me
>
> Can we define what a veto is?
disclaimer: I am not a rules lawyer :D
in both cases it depends on whether the particular issue is subject to
majority vote or consensus vote and whether the vote is lazy. A veto is
only valid if an explanation is provided, in a majority vote a -1 is not
a veto so you need not explain.
> Question #1 : If ten people vote +1 for something and one votes -1, is it vetoed?
if majority vote rules: no
if lazy majority vote rules: no
if consensus vote rules: yes
if lazy consensus vote rules: yes
> Question #2 : If one person votes +1 for something and one votes -1, is it vetoed?
if majority vote rules: no
if lazy majority vote rules: no
(however, the result of the vote is undefined until there are 3 positive
votes)
if consensus vote rules: yes
if lazy consensus vote rules: yes
the distinction between all this of course only matters when someone
votes -1. Especially if the -1 is not on something proposed under
'[VOTE]' but something subject to lazy consensus.
--------
My line of thought is that we temporarily make everything subject to
consensus voting (lazy or not), hence every -1 is a veto. If we then
agree that we need consensus, what we need to do is make sure there is
always consensus. ie probably put a lot of time and effort into
discussion in the event where something goes from lazy consensus to
nonlazy consensus.
It's (IMO) not so much about rules and actual definitions as it is about
agreeing on the general principles. More eloquent people than me can
worry about translating principle into rule ;)
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [proposal] development process
Posted by Paul Hammant <pa...@yahoo.com>.
> No Veto
> -------
> We will refrain from the use of vetoes on medium to long-term issues on
> all code in all avalon cvses.
>
> +1 from me
Can we define what a veto is?
Question #1 : If ten people vote +1 for something and one votes -1, is it vetoed?
Question #2 : If one person votes +1 for something and one votes -1, is it vetoed?
- Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>