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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- Stephen J. McConnell
OSM SARL digital products for a global economy mailto:[EMAIL PROTECTED] http://www.osm.net -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
