You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@citi-us.com> on 2002/12/03 19:54:34 UTC
Kick-starting the Charter process
At this location, you can see the current XML Project charter:
http://cvs.apache.org/viewcvs.cgi/xml-admin/charter.txt
I propose that we take that charter and adapt it to ours since it
is easier to start from something already accepted ;P .
If we like it, let's commit it to CVS so that we can track changes.
(I would do it, but I am behind a corporate firewall).
Below is my first stab. Aside from writing the mission statement
(which needs to be updated and commented on), I added this phrase
to the PMC section:
" It is also
possible for a project depending on Avalon to nominate a representative.
The representative of the client project still needs to be unanimously
approved by all PMC members, and a two-thirds majority vote of
committers. "
The only other work I did was changing all references from XML to
Avalon.
------------------------ avalon.apache.org -----------------------------
avalon.apache.org is a collaborative software development project
dedicated to providing robust, full-featured, commercial-quality, and
freely available component architecture. This project is managed in
cooperation with various individuals worldwide (both independent and
company-affiliated experts), who use the Internet to communicate, plan,
and develop Avalon component software and related documentation.
This charter briefly describes the mission, history, organization, and
processes of the project.
MISSION
=======
avalon.apache.org exists to promote the use of Avalon components.
Component Based Design is a proven practice that helps create systems
that are loosely coupled and easy to maintain. Component Based
Design requires a general framework, components, and containers to
function properly.
avalon.apache.org defines the framework, the reference implementation
of the containers, the compliance testing suite, and a set of components
that can be used in third party projects. These components plug into each
other using standard APIs (formal, de facto, or proposed). The components
must be high performance, reliable, secure, and easy to use. The
components must be part of an underlying architectural orchestration that
will allow them to work together without major negotiations or breakage.
We believe that the best way to define this Avalon architecture is by
having both individuals and corporations collaborate on the best possible
infrastructure, APIs, code, testing, and release cycles. Components must
be vendor neutral and usable as core components for all.
In order to achieve a coherent architecture between avalon.apache.org
components and other components and applications, standards (formal or
de facto) will be used as much as possible for both protocols and
APIs. We will also allow the innovation of new protocols, APIs, and
components in order to seed new concepts not yet defined by standards.
HISTORY
=======
This project was established under the direction of the newly-formed
Apache Software Foundation in November 2002 to facilitate joint
open-source development.
THE PROJECT MANAGEMENT COMMITTEE
================================
The avalon.apache.org project is managed by a small, core group of
contributors known as the Project Management Committee [PMC]. The PMC
must have at least one officer from the Apache Board, who will be the
Chairperson and report to the Apache Board. See
http://www.apache.org/foundation/bylaws.html for reference.
The PMC has the following responsibilities:
1) Accepting new subproject proposals, formally submitting these
proposals for committer vote, and creating the subproject (see
SUBPROJECTS below).
2) Facilitating code or other donations by individuals or companies.
3) Resolving license issues and other legal issues.
4) Approving new committers.
5) Ensuring that administrative and infrastructure work is completed.
6) Facilitating relationships among projects.
7) Facilitating relationships between avalon.apache.org and the external
world.
8) Overseeing avalon.apache.org to ensure that the mission defined in
this document is being fulfilled.
9) Resolving conflicts within the project.
To become a member of the PMC, an individual must be nominated by a
contributor, unanimously approved by all PMC members, and approved by
a two-thirds majority of committers. In most cases, developers will
have actively contributed to development for at least six months
before being considered for membership on the PMC. It is also
possible for a project depending on Avalon to nominate a representative.
The representative of the client project still needs to be unanimously
approved by all PMC members, and a two-thirds majority vote of
committers. The goal is to keep the membership of the core group
at four to seven people in order to minimize the bureaucratic overhead
required to keep the project operational.
In the unlikely event that a member of the PMC becomes disruptive to
the process or ceases to contribute for an extended period, said
member may be removed by unanimous vote of remaining PMC members.
The PMC is responsible for maintaining and updating this
charter. Development must follow the process outlined below, so any
change to the development process necessitates a change to the
charter. Changes must be unanimously approved by all members of the
PMC. A contributor may challenge a change to the charter at any time
and ask for a vote of all committers, in which case a two-thirds
majority must approve the change.
SUBPROJECTS
===========
avalon.apache.org is comprised of subprojects; a subproject is a
component whose scope is well defined. Each subproject has its own
set of developers.
A new subproject proposal is submitted to the PMC, accepted by majority
committer vote, and then subject to final approval by the PMC.
COMMITTERS
==========
Each subproject has a set of committers. Committers are developers who
have read/write access to the source code repository. New committers
are added when a developer is nominated by a committer and approved by
at least 50 percent of the committers for that subproject with no
opposing votes. In most cases, new committers will already be
participating in the development process by submitting suggestions
and/or fixes via the bug report page or mailing lists.
CONTRIBUTORS
============
Like all Apache projects, the Avalon project is a meritocracy -- the more
work you do, the more you are allowed to do. Occasional contributors
will be able to report bugs and participate in the mailing lists.
Specific changes to a product proposed for discussion or voting on the
appropriate development mailing list should be presented in the form
of input to the patch command. When sent to the mailing list, the
message should contain a subject beginning with [PATCH] and including
a distinctive one-line summary that corresponds to the action item for
that patch.
Use the diff -u command from the original software file(s) to the
modified software file(s) to create the patch. Patches should be
submitted against the latest CVS versions of the software to avoid
conflicts and ensure that you are not submitting a patch for a problem
that has already been resolved.
Developers who make regular and substantial contributions may become
committers as described above.
INFRASTRUCTURE
==============
The avalon.apache.org project site must provide the following:
Bug Database -- This is a system for tracking bugs and feature
requests.
Subproject Source Repositories -- These are several CVS repositories
containing both the source code and documentation for the
subprojects. Each subproject will have a set of committers to its
repository.
Website -- An avalon.apache.org website will contain information about
the avalon.apache.org project, including documentation, downloads of
releases, and this charter. Each subproject will have its own website
with subproject information.
PMC Mailing List -- This list is for PMC business requiring
confidentiality, particularly when an individual or company requests
discretion. All other PMC business should be done on the general
mailing list.
General Mailing List -- This mailing list is open to the public. It is
intended for discussions that cross subprojects.
Subproject Mailing Lists -- Each subproject should have a devoted mailing
list. Many subprojects may wish to have both user and development
lists. The individual subprojects may decide on the exact structure of
their mailing lists.
LICENSING
=========
All contributions to the avalon.apache.org project adhere to the "ASF
Source Code License." All further contributions must be made under the
same terms. All contributions must contain the following copyright
notice: [This changes now that the license is available]
Copyright (c) {date} {name of contributor} and others. All rights
reserved. This program and the accompanying materials are made
available under the terms of the ASF Source Code License, as found in
the file ASF.code.license.html that is included in this distribution.
THE DEVELOPMENT PROCESS
=======================
The development process is intentionally lightweight; like other
Apache projects, the committers decide which changes may be committed
to the repository. Three +1 ('yes' votes) with no -1 ('no' votes or
vetoes) are needed to approve a code change. For efficiency, some code
changes from some contributors (e.g. feature additions, bug fixes) may
be approved in advance, in which case they may be committed first and
changed as needed, with conflicts resolved by majority vote of the
committers.
SUBPROJECT REQUIREMENTS
=======================
Each subproject must have a set of requirements as well as an
up-to-date release plan and design document on its dedicated web page.
It must be possible for each subproject to plug into the Gump nightly
build system (see http://jakarta.apache.org/builds/gump). It is
recommended that each subproject have a smoke-test system that works at
least as a basic integration test.
RELATIONSHIP TO OTHER APACHE PROJECTS
=====================================
The avalon.apache.org project should work closely with other Apache
projects, such as Jakarta and the Apache Server, to avoid redundancy
and achieve a coherent architecture among avalon.apache.org and these
projects.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Kick-starting the Charter process
Posted by Danny Angus <da...@apache.org>.
Leo,
Sounds like an excellent idea.
Perhaps people could commit existing charters/drafts of new charters to the "commiters" CVS module? (I'd suggest commiters/docs/pmccharters)
It would allow people to see what everyone else was doing without imposing anything. Unless PMC charters are already in CVS in which case I suppose someone would need to symlink them.
This pre-supposes that we can be trusted not to deface each others efforts.
d.
> From: Leo Simons [mailto:leosimons@apache.org]
> Should we work intimately together on this? If so, where/how/etc?
Re: Kick-starting the Charter process
Posted by Leo Simons <le...@apache.org>.
Hi all,
there's a few new projects with a few new PMCs. They all need a charter.
My gut feeling tells me that large parts of the various charters for the
various projects will turn out to be quite similar to each other.
It makes sense to me that we pour together resources to work on this
together. It also makes sense to me to have as many of the "Wise and
Knowledgeable Apache Elders" as possible help out with this and provide,
well, wisdom and knowledge.
Should we work intimately together on this? If so, where/how/etc?
cheers,
- Leo the Reuse Fanatic
Re: Kick-starting the Charter process
Posted by Leo Simons <le...@apache.org>.
Hi all,
there's a few new projects with a few new PMCs. They all need a charter.
My gut feeling tells me that large parts of the various charters for the
various projects will turn out to be quite similar to each other.
It makes sense to me that we pour together resources to work on this
together. It also makes sense to me to have as many of the "Wise and
Knowledgeable Apache Elders" as possible help out with this and provide,
well, wisdom and knowledge.
Should we work intimately together on this? If so, where/how/etc?
cheers,
- Leo the Reuse Fanatic
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Kick-starting the Charter process
Posted by "Noel J. Bergman" <no...@devtech.com>.
> IMHO, You are likely to get better (and quicker) results in incubator@.
That's why I asked. :-)
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Kick-starting the Charter process
Posted by "Noel J. Bergman" <no...@devtech.com>.
> IMHO, You are likely to get better (and quicker) results in incubator@.
That's why I asked. :-)
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Kick-starting the Charter process
Posted by "Noel J. Bergman" <no...@devtech.com>.
> IMHO, You are likely to get better (and quicker) results in incubator@.
That's why I asked. :-)
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Kick-starting the Charter process
Posted by Sam Ruby <ru...@apache.org>.
Noel J. Bergman wrote:
>
> Is community@ the correct place to raise this issue generally? Seems that
> if there is going to be a push to promote more projects, that there ought to
> be an approved template.
IMHO, You are likely to get better (and quicker) results in incubator@.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Kick-starting the Charter process
Posted by Sam Ruby <ru...@apache.org>.
Noel J. Bergman wrote:
>
> Is community@ the correct place to raise this issue generally? Seems that
> if there is going to be a push to promote more projects, that there ought to
> be an approved template.
IMHO, You are likely to get better (and quicker) results in incubator@.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Kick-starting the Charter process
Posted by Sam Ruby <ru...@apache.org>.
Noel J. Bergman wrote:
>
> Is community@ the correct place to raise this issue generally? Seems that
> if there is going to be a push to promote more projects, that there ought to
> be an approved template.
IMHO, You are likely to get better (and quicker) results in incubator@.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Kick-starting the Charter process
Posted by "Noel J. Bergman" <no...@devtech.com>.
> We need a starting point, and this is the only example of a PMC
> charter I could find. That's all it is for.
Is community@ the correct place to raise this issue generally? Seems that
if there is going to be a push to promote more projects, that there ought to
be an approved template.
> I want it to be VERY difficult to remove someone. As a result, I
> personally would stick with UNANIMOUS vote to remove someone.
> we must legally protect ourselves by stating the rules in which
> someone can be removed.
See the ASF Bylaws, section 6.5.
> > There are much stronger guidelines that this comming out of the
> > incubator project - the above is insufficient.
> Where are they? Provide some details.
http://incubator.apache.org/drafts/voting.html at the moment.
FWIW, I think that the Charter ought to incorporate by reference rather than
by value.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Kick-starting the Charter process
Posted by "Noel J. Bergman" <no...@devtech.com>.
> We need a starting point, and this is the only example of a PMC
> charter I could find. That's all it is for.
Is community@ the correct place to raise this issue generally? Seems that
if there is going to be a push to promote more projects, that there ought to
be an approved template.
> I want it to be VERY difficult to remove someone. As a result, I
> personally would stick with UNANIMOUS vote to remove someone.
> we must legally protect ourselves by stating the rules in which
> someone can be removed.
See the ASF Bylaws, section 6.5.
> > There are much stronger guidelines that this comming out of the
> > incubator project - the above is insufficient.
> Where are they? Provide some details.
http://incubator.apache.org/drafts/voting.html at the moment.
FWIW, I think that the Charter ought to incorporate by reference rather than
by value.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Kick-starting the Charter process
Posted by "Noel J. Bergman" <no...@devtech.com>.
> We need a starting point, and this is the only example of a PMC
> charter I could find. That's all it is for.
Is community@ the correct place to raise this issue generally? Seems that
if there is going to be a push to promote more projects, that there ought to
be an approved template.
> I want it to be VERY difficult to remove someone. As a result, I
> personally would stick with UNANIMOUS vote to remove someone.
> we must legally protect ourselves by stating the rules in which
> someone can be removed.
See the ASF Bylaws, section 6.5.
> > There are much stronger guidelines that this comming out of the
> > incubator project - the above is insufficient.
> Where are they? Provide some details.
http://incubator.apache.org/drafts/voting.html at the moment.
FWIW, I think that the Charter ought to incorporate by reference rather than
by value.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Kick-starting the Charter process
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Berin Loritsch wrote:
>
> >At this location, you can see the current XML Project charter:
> >http://cvs.apache.org/viewcvs.cgi/xml-admin/charter.txt
> >
> >I propose that we take that charter and adapt it to ours since it
> >is easier to start from something already accepted ;P .
> >
>
> -1
>
> From a clear an unambigouse process perspective its not a
> good example.
> Yes - its perhaps a starting point but al of the stuff to do with
> unanimouse decision making is a recepie for making the PMC totally
> disfunctional.
We need a starting point, and this is the only example of a PMC
charter I could find. That's all it is for.
> >If we like it, let's commit it to CVS so that we can track changes.
> >(I would do it, but I am behind a corporate firewall).
> >
> >Below is my first stab. Aside from writing the mission statement
> >(which needs to be updated and commented on), I added this phrase
> >to the PMC section:
> >
> >" It is also
> >possible for a project depending on Avalon to nominate a
> representative.
> >The representative of the client project still needs to be
> unanimously
> >approved by all PMC members, and a two-thirds majority vote of
> >committers. "
>
> This can be much more cleanly addressed by simply reducing word - not
> adding them. More notes below.
Ok. You're words?
> >The only other work I did was changing all references from XML to
> >Avalon.
> >
> >
> >------------------------ avalon.apache.org
> -----------------------------
> >
> >avalon.apache.org is a collaborative software development project
> >dedicated to providing robust, full-featured, commercial-quality, and
> >freely available component architecture.
> >
>
> "component and service architecture" - no just "component
> architecture"
Services are components, so they are included. However your point is
made.
>
> Sounds like a mission for commons - needs to be replaced with
> a concrete
> mission that defines Avalon objectives.
It's a starting point. I took a stab, what's yours?
> >HISTORY
> >=======
> >
> >This project was established under the direction of the newly-formed
> >Apache Software Foundation in November 2002 to facilitate joint
> >open-source development.
> >
> >
>
> History should be more complete - including reference to
> Jakarta Avalon.
Copy and paste. All I did was make it accurate as regards us.
> >THE PROJECT MANAGEMENT COMMITTEE
> >================================
> >The avalon.apache.org project is managed by a small, core group of
> >contributors known as the Project Management Committee
> [PMC]. The PMC
> >must have at least one officer from the Apache Board, who will be the
> >Chairperson and report to the Apache Board. See
> >http://www.apache.org/foundation/bylaws.html for reference.
> >
> >
>
> I would change the first sentence to:
>
> The avalon.apache.org project is managed by a elected group
> known as the Project Management Committee [PMC].
Ok.
> >The PMC has the following responsibilities:
> >
> >1) Accepting new subproject proposals, formally submitting these
> > proposals for committer vote, and creating the subproject (see
> > SUBPROJECTS below).
> >
>
> Don;t like this notion of SUBPROJECT scope - the issue is not about
> accepting a new subproject or not - its about properly managing the
> project. Breaking out subprojects isn't management.
Copy and paste. what is your wording?
> >2) Facilitating code or other donations by individuals or companies.
> >3) Resolving license issues and other legal issues.
> >4) Approving new committers.
> >5) Ensuring that administrative and infrastructure work is completed.
>
> Point 5 is infussiently defined and more an action item - should be
> reworded to a responsibility. Is probably redundant anyway
> with respect
> to point 8.
Again, copy and paste. What is your preferred wording?
> >To become a member of the PMC, an individual must be nominated by a
> >contributor, unanimously approved by all PMC members, and approved by
> >a two-thirds majority of committers. In most cases, developers will
> >have actively contributed to development for at least six months
> >before being considered for membership on the PMC.
> >
>
> Disagree.
>
> If a single PMC member can veto the introduction of another member or
> any process - we have a lame duck PMC. This whiole notion of
> "you must
> be a committer" - "in most cases" - etc. is unnecessary noise
> - instead
> this needs to be written with the objective of laying down the laws
> about PMC evolution that gaurantee member representation.
>
> Don;t have a replacement at the moment but coiinsider this as
> a big -1
> on current wording here.
This is a copy from the wording at XML. Remember I didn't do alot of
fussing with it.
> >It is also
> >possible for a project depending on Avalon to nominate a
> representative.
> >The representative of the client project still needs to be
> unanimously
> >approved by all PMC members,
>
> No, no no - any criteria for a unanimouse action is just plain
> off-the-planet in terms of procedure - it would dramatically
> change my
> perception of who I would consider for PMC membership - and
> for all the
> wrong reasons.
Propose something different. Don't say no. Counter-propose.
> >and a two-thirds majority vote of
> >committers. The goal is to keep the membership of the core group
> >at four to seven people in order to minimize the
> bureaucratic overhead
> >required to keep the project operational.
>
> Size qualification is unnecessry - this should be abiout the
> process for
> change - which should be up to the community based on the procedures.
> This sort of noice should be dropped from the charter.
Ok.
> >In the unlikely event that a member of the PMC becomes disruptive to
> >the process or ceases to contribute for an extended period, said
> >member may be removed by unanimous vote of remaining PMC members.
>
> Same issue here - these sort of things should not be qualified by
> "disruptive" - maybe soneone is being disruptive because the
> PMC isn't
> doing what needs to be done - whatever - the policies should not
> precondition a procedure with adjectives like this - and
> secondly - the
> ugly "unanimous" word appears again - in any sort of body that is
> anywhaere near representative - things like thins are at worst case a
> 2/3 majority - as are things like changing the charter.
I want it to be VERY difficult to remove someone. As a result, I
personally would stick with UNANIMOUS vote to remove someone.
Points are taken in regards to PMC not doing their job, but bear in
mind that there are a few people (not many) who are so hard-headed
and bent on undermining something that even if the PMC was doing
their job, the only solution for the COMMUNITY's sake is to remove
that person. We have yet to run into one of those people (Peter does
not qualify according to the information I have), but we must
legally protect ourselves by stating the rules in which someone
can be removed.
> >The PMC is responsible for maintaining and updating this
> >charter. Development must follow the process outlined below, so any
> >change to the development process necessitates a change to the
> >charter. Changes must be unanimously approved by all members of the
> >PMC.
>
> 2/3 - not unanimous.
Ok.
> >A contributor may challenge a change to the charter at any time
> >and ask for a vote of all committers, in which case a two-thirds
> >majority must approve the change.
> >
>
> Disagree.
> A contribnuter should intervi8ne though participation as an
> elected member.
> This should be dropped.
Not all Avalon committers are on the PMC. If we as the PMC
introduce something that an Avalon committer is uneasy with,
unknown to him until the deed is done, the Avalon committer
needs an outlet to let his voice be heard.
> >SUBPROJECTS
> >===========
> >avalon.apache.org is comprised of subprojects; a subproject is a
> >component whose scope is well defined. Each subproject has its own
> >set of developers.
> >
> >A new subproject proposal is submitted to the PMC, accepted
> by majority
> >committer vote, and then subject to final approval by the PMC.
> >
> >
>
> Not relevant to Avalon.
> We should not be subproject driven.
Ok.
> >COMMITTERS
> >==========
> >
> >Each subproject has a set of committers.
> >
> -1
> A recepie for fragmentation.
If we have no sub-projects, there is no issue here.
> >Committers are developers who
> >have read/write access to the source code repository. New committers
> >are added when a developer is nominated by a committer and
> approved by
> >at least 50 percent of the committers for that subproject with no
> >opposing votes. In most cases, new committers will already be
> >participating in the development process by submitting suggestions
> >and/or fixes via the bug report page or mailing lists.
>
> Probably needs to be rewritten from our perspective of a single
> committer community.
Ok. Propose something.
> Don't think this contributors text is needed because iut does
> not seem
> to impact the procedures.
We need to document the procedures for becoming a Committer.
>
> >INFRASTRUCTURE
> >==============
> >The avalon.apache.org project site must provide the following:
> >
> >Bug Database -- This is a system for tracking bugs and feature
> >requests.
> >
> >Subproject Source Repositories -- These are several CVS repositories
> >containing both the source code and documentation for the
> >subprojects. Each subproject will have a set of committers to its
> >repository.
> >
> >
> -1
>
> Recepie for fragmentation.
Again, if there is only one project and no subprojects, this
is a non-issue.
> >LICENSING
> >=========
> >All contributions to the avalon.apache.org project adhere to the "ASF
> >Source Code License." All further contributions must be made
> under the
> >same terms. All contributions must contain the following copyright
> >notice: [This changes now that the license is available]
> >
> >Copyright (c) {date} {name of contributor} and others. All rights
> >reserved. This program and the accompanying materials are made
> >available under the terms of the ASF Source Code License, as found in
> >the file ASF.code.license.html that is included in this distribution.
> >
>
> Should be revised to include the full ASF license in the
> source header.
+1
> >THE DEVELOPMENT PROCESS
> >=======================
> >The development process is intentionally lightweight; like other
> >Apache projects, the committers decide which changes may be committed
> >to the repository. Three +1 ('yes' votes) with no -1 ('no' votes or
> >vetoes) are needed to approve a code change. For efficiency,
> some code
> >changes from some contributors (e.g. feature additions, bug
> fixes) may
> >be approved in advance, in which case they may be committed first and
> >changed as needed, with conflicts resolved by majority vote of the
> >committers.
> >
>
> There are much stronger guidelines that this comming out of the
> incubator project - the above is insufficient.
Where are they? Provide some details.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Kick-starting the Charter process
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Berin Loritsch wrote:
>
> >At this location, you can see the current XML Project charter:
> >http://cvs.apache.org/viewcvs.cgi/xml-admin/charter.txt
> >
> >I propose that we take that charter and adapt it to ours since it
> >is easier to start from something already accepted ;P .
> >
>
> -1
>
> From a clear an unambigouse process perspective its not a
> good example.
> Yes - its perhaps a starting point but al of the stuff to do with
> unanimouse decision making is a recepie for making the PMC totally
> disfunctional.
We need a starting point, and this is the only example of a PMC
charter I could find. That's all it is for.
> >If we like it, let's commit it to CVS so that we can track changes.
> >(I would do it, but I am behind a corporate firewall).
> >
> >Below is my first stab. Aside from writing the mission statement
> >(which needs to be updated and commented on), I added this phrase
> >to the PMC section:
> >
> >" It is also
> >possible for a project depending on Avalon to nominate a
> representative.
> >The representative of the client project still needs to be
> unanimously
> >approved by all PMC members, and a two-thirds majority vote of
> >committers. "
>
> This can be much more cleanly addressed by simply reducing word - not
> adding them. More notes below.
Ok. You're words?
> >The only other work I did was changing all references from XML to
> >Avalon.
> >
> >
> >------------------------ avalon.apache.org
> -----------------------------
> >
> >avalon.apache.org is a collaborative software development project
> >dedicated to providing robust, full-featured, commercial-quality, and
> >freely available component architecture.
> >
>
> "component and service architecture" - no just "component
> architecture"
Services are components, so they are included. However your point is
made.
>
> Sounds like a mission for commons - needs to be replaced with
> a concrete
> mission that defines Avalon objectives.
It's a starting point. I took a stab, what's yours?
> >HISTORY
> >=======
> >
> >This project was established under the direction of the newly-formed
> >Apache Software Foundation in November 2002 to facilitate joint
> >open-source development.
> >
> >
>
> History should be more complete - including reference to
> Jakarta Avalon.
Copy and paste. All I did was make it accurate as regards us.
> >THE PROJECT MANAGEMENT COMMITTEE
> >================================
> >The avalon.apache.org project is managed by a small, core group of
> >contributors known as the Project Management Committee
> [PMC]. The PMC
> >must have at least one officer from the Apache Board, who will be the
> >Chairperson and report to the Apache Board. See
> >http://www.apache.org/foundation/bylaws.html for reference.
> >
> >
>
> I would change the first sentence to:
>
> The avalon.apache.org project is managed by a elected group
> known as the Project Management Committee [PMC].
Ok.
> >The PMC has the following responsibilities:
> >
> >1) Accepting new subproject proposals, formally submitting these
> > proposals for committer vote, and creating the subproject (see
> > SUBPROJECTS below).
> >
>
> Don;t like this notion of SUBPROJECT scope - the issue is not about
> accepting a new subproject or not - its about properly managing the
> project. Breaking out subprojects isn't management.
Copy and paste. what is your wording?
> >2) Facilitating code or other donations by individuals or companies.
> >3) Resolving license issues and other legal issues.
> >4) Approving new committers.
> >5) Ensuring that administrative and infrastructure work is completed.
>
> Point 5 is infussiently defined and more an action item - should be
> reworded to a responsibility. Is probably redundant anyway
> with respect
> to point 8.
Again, copy and paste. What is your preferred wording?
> >To become a member of the PMC, an individual must be nominated by a
> >contributor, unanimously approved by all PMC members, and approved by
> >a two-thirds majority of committers. In most cases, developers will
> >have actively contributed to development for at least six months
> >before being considered for membership on the PMC.
> >
>
> Disagree.
>
> If a single PMC member can veto the introduction of another member or
> any process - we have a lame duck PMC. This whiole notion of
> "you must
> be a committer" - "in most cases" - etc. is unnecessary noise
> - instead
> this needs to be written with the objective of laying down the laws
> about PMC evolution that gaurantee member representation.
>
> Don;t have a replacement at the moment but coiinsider this as
> a big -1
> on current wording here.
This is a copy from the wording at XML. Remember I didn't do alot of
fussing with it.
> >It is also
> >possible for a project depending on Avalon to nominate a
> representative.
> >The representative of the client project still needs to be
> unanimously
> >approved by all PMC members,
>
> No, no no - any criteria for a unanimouse action is just plain
> off-the-planet in terms of procedure - it would dramatically
> change my
> perception of who I would consider for PMC membership - and
> for all the
> wrong reasons.
Propose something different. Don't say no. Counter-propose.
> >and a two-thirds majority vote of
> >committers. The goal is to keep the membership of the core group
> >at four to seven people in order to minimize the
> bureaucratic overhead
> >required to keep the project operational.
>
> Size qualification is unnecessry - this should be abiout the
> process for
> change - which should be up to the community based on the procedures.
> This sort of noice should be dropped from the charter.
Ok.
> >In the unlikely event that a member of the PMC becomes disruptive to
> >the process or ceases to contribute for an extended period, said
> >member may be removed by unanimous vote of remaining PMC members.
>
> Same issue here - these sort of things should not be qualified by
> "disruptive" - maybe soneone is being disruptive because the
> PMC isn't
> doing what needs to be done - whatever - the policies should not
> precondition a procedure with adjectives like this - and
> secondly - the
> ugly "unanimous" word appears again - in any sort of body that is
> anywhaere near representative - things like thins are at worst case a
> 2/3 majority - as are things like changing the charter.
I want it to be VERY difficult to remove someone. As a result, I
personally would stick with UNANIMOUS vote to remove someone.
Points are taken in regards to PMC not doing their job, but bear in
mind that there are a few people (not many) who are so hard-headed
and bent on undermining something that even if the PMC was doing
their job, the only solution for the COMMUNITY's sake is to remove
that person. We have yet to run into one of those people (Peter does
not qualify according to the information I have), but we must
legally protect ourselves by stating the rules in which someone
can be removed.
> >The PMC is responsible for maintaining and updating this
> >charter. Development must follow the process outlined below, so any
> >change to the development process necessitates a change to the
> >charter. Changes must be unanimously approved by all members of the
> >PMC.
>
> 2/3 - not unanimous.
Ok.
> >A contributor may challenge a change to the charter at any time
> >and ask for a vote of all committers, in which case a two-thirds
> >majority must approve the change.
> >
>
> Disagree.
> A contribnuter should intervi8ne though participation as an
> elected member.
> This should be dropped.
Not all Avalon committers are on the PMC. If we as the PMC
introduce something that an Avalon committer is uneasy with,
unknown to him until the deed is done, the Avalon committer
needs an outlet to let his voice be heard.
> >SUBPROJECTS
> >===========
> >avalon.apache.org is comprised of subprojects; a subproject is a
> >component whose scope is well defined. Each subproject has its own
> >set of developers.
> >
> >A new subproject proposal is submitted to the PMC, accepted
> by majority
> >committer vote, and then subject to final approval by the PMC.
> >
> >
>
> Not relevant to Avalon.
> We should not be subproject driven.
Ok.
> >COMMITTERS
> >==========
> >
> >Each subproject has a set of committers.
> >
> -1
> A recepie for fragmentation.
If we have no sub-projects, there is no issue here.
> >Committers are developers who
> >have read/write access to the source code repository. New committers
> >are added when a developer is nominated by a committer and
> approved by
> >at least 50 percent of the committers for that subproject with no
> >opposing votes. In most cases, new committers will already be
> >participating in the development process by submitting suggestions
> >and/or fixes via the bug report page or mailing lists.
>
> Probably needs to be rewritten from our perspective of a single
> committer community.
Ok. Propose something.
> Don't think this contributors text is needed because iut does
> not seem
> to impact the procedures.
We need to document the procedures for becoming a Committer.
>
> >INFRASTRUCTURE
> >==============
> >The avalon.apache.org project site must provide the following:
> >
> >Bug Database -- This is a system for tracking bugs and feature
> >requests.
> >
> >Subproject Source Repositories -- These are several CVS repositories
> >containing both the source code and documentation for the
> >subprojects. Each subproject will have a set of committers to its
> >repository.
> >
> >
> -1
>
> Recepie for fragmentation.
Again, if there is only one project and no subprojects, this
is a non-issue.
> >LICENSING
> >=========
> >All contributions to the avalon.apache.org project adhere to the "ASF
> >Source Code License." All further contributions must be made
> under the
> >same terms. All contributions must contain the following copyright
> >notice: [This changes now that the license is available]
> >
> >Copyright (c) {date} {name of contributor} and others. All rights
> >reserved. This program and the accompanying materials are made
> >available under the terms of the ASF Source Code License, as found in
> >the file ASF.code.license.html that is included in this distribution.
> >
>
> Should be revised to include the full ASF license in the
> source header.
+1
> >THE DEVELOPMENT PROCESS
> >=======================
> >The development process is intentionally lightweight; like other
> >Apache projects, the committers decide which changes may be committed
> >to the repository. Three +1 ('yes' votes) with no -1 ('no' votes or
> >vetoes) are needed to approve a code change. For efficiency,
> some code
> >changes from some contributors (e.g. feature additions, bug
> fixes) may
> >be approved in advance, in which case they may be committed first and
> >changed as needed, with conflicts resolved by majority vote of the
> >committers.
> >
>
> There are much stronger guidelines that this comming out of the
> incubator project - the above is insufficient.
Where are they? Provide some details.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Kick-starting the Charter process
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Berin Loritsch wrote:
>
> >At this location, you can see the current XML Project charter:
> >http://cvs.apache.org/viewcvs.cgi/xml-admin/charter.txt
> >
> >I propose that we take that charter and adapt it to ours since it
> >is easier to start from something already accepted ;P .
> >
>
> -1
>
> From a clear an unambigouse process perspective its not a
> good example.
> Yes - its perhaps a starting point but al of the stuff to do with
> unanimouse decision making is a recepie for making the PMC totally
> disfunctional.
We need a starting point, and this is the only example of a PMC
charter I could find. That's all it is for.
> >If we like it, let's commit it to CVS so that we can track changes.
> >(I would do it, but I am behind a corporate firewall).
> >
> >Below is my first stab. Aside from writing the mission statement
> >(which needs to be updated and commented on), I added this phrase
> >to the PMC section:
> >
> >" It is also
> >possible for a project depending on Avalon to nominate a
> representative.
> >The representative of the client project still needs to be
> unanimously
> >approved by all PMC members, and a two-thirds majority vote of
> >committers. "
>
> This can be much more cleanly addressed by simply reducing word - not
> adding them. More notes below.
Ok. You're words?
> >The only other work I did was changing all references from XML to
> >Avalon.
> >
> >
> >------------------------ avalon.apache.org
> -----------------------------
> >
> >avalon.apache.org is a collaborative software development project
> >dedicated to providing robust, full-featured, commercial-quality, and
> >freely available component architecture.
> >
>
> "component and service architecture" - no just "component
> architecture"
Services are components, so they are included. However your point is
made.
>
> Sounds like a mission for commons - needs to be replaced with
> a concrete
> mission that defines Avalon objectives.
It's a starting point. I took a stab, what's yours?
> >HISTORY
> >=======
> >
> >This project was established under the direction of the newly-formed
> >Apache Software Foundation in November 2002 to facilitate joint
> >open-source development.
> >
> >
>
> History should be more complete - including reference to
> Jakarta Avalon.
Copy and paste. All I did was make it accurate as regards us.
> >THE PROJECT MANAGEMENT COMMITTEE
> >================================
> >The avalon.apache.org project is managed by a small, core group of
> >contributors known as the Project Management Committee
> [PMC]. The PMC
> >must have at least one officer from the Apache Board, who will be the
> >Chairperson and report to the Apache Board. See
> >http://www.apache.org/foundation/bylaws.html for reference.
> >
> >
>
> I would change the first sentence to:
>
> The avalon.apache.org project is managed by a elected group
> known as the Project Management Committee [PMC].
Ok.
> >The PMC has the following responsibilities:
> >
> >1) Accepting new subproject proposals, formally submitting these
> > proposals for committer vote, and creating the subproject (see
> > SUBPROJECTS below).
> >
>
> Don;t like this notion of SUBPROJECT scope - the issue is not about
> accepting a new subproject or not - its about properly managing the
> project. Breaking out subprojects isn't management.
Copy and paste. what is your wording?
> >2) Facilitating code or other donations by individuals or companies.
> >3) Resolving license issues and other legal issues.
> >4) Approving new committers.
> >5) Ensuring that administrative and infrastructure work is completed.
>
> Point 5 is infussiently defined and more an action item - should be
> reworded to a responsibility. Is probably redundant anyway
> with respect
> to point 8.
Again, copy and paste. What is your preferred wording?
> >To become a member of the PMC, an individual must be nominated by a
> >contributor, unanimously approved by all PMC members, and approved by
> >a two-thirds majority of committers. In most cases, developers will
> >have actively contributed to development for at least six months
> >before being considered for membership on the PMC.
> >
>
> Disagree.
>
> If a single PMC member can veto the introduction of another member or
> any process - we have a lame duck PMC. This whiole notion of
> "you must
> be a committer" - "in most cases" - etc. is unnecessary noise
> - instead
> this needs to be written with the objective of laying down the laws
> about PMC evolution that gaurantee member representation.
>
> Don;t have a replacement at the moment but coiinsider this as
> a big -1
> on current wording here.
This is a copy from the wording at XML. Remember I didn't do alot of
fussing with it.
> >It is also
> >possible for a project depending on Avalon to nominate a
> representative.
> >The representative of the client project still needs to be
> unanimously
> >approved by all PMC members,
>
> No, no no - any criteria for a unanimouse action is just plain
> off-the-planet in terms of procedure - it would dramatically
> change my
> perception of who I would consider for PMC membership - and
> for all the
> wrong reasons.
Propose something different. Don't say no. Counter-propose.
> >and a two-thirds majority vote of
> >committers. The goal is to keep the membership of the core group
> >at four to seven people in order to minimize the
> bureaucratic overhead
> >required to keep the project operational.
>
> Size qualification is unnecessry - this should be abiout the
> process for
> change - which should be up to the community based on the procedures.
> This sort of noice should be dropped from the charter.
Ok.
> >In the unlikely event that a member of the PMC becomes disruptive to
> >the process or ceases to contribute for an extended period, said
> >member may be removed by unanimous vote of remaining PMC members.
>
> Same issue here - these sort of things should not be qualified by
> "disruptive" - maybe soneone is being disruptive because the
> PMC isn't
> doing what needs to be done - whatever - the policies should not
> precondition a procedure with adjectives like this - and
> secondly - the
> ugly "unanimous" word appears again - in any sort of body that is
> anywhaere near representative - things like thins are at worst case a
> 2/3 majority - as are things like changing the charter.
I want it to be VERY difficult to remove someone. As a result, I
personally would stick with UNANIMOUS vote to remove someone.
Points are taken in regards to PMC not doing their job, but bear in
mind that there are a few people (not many) who are so hard-headed
and bent on undermining something that even if the PMC was doing
their job, the only solution for the COMMUNITY's sake is to remove
that person. We have yet to run into one of those people (Peter does
not qualify according to the information I have), but we must
legally protect ourselves by stating the rules in which someone
can be removed.
> >The PMC is responsible for maintaining and updating this
> >charter. Development must follow the process outlined below, so any
> >change to the development process necessitates a change to the
> >charter. Changes must be unanimously approved by all members of the
> >PMC.
>
> 2/3 - not unanimous.
Ok.
> >A contributor may challenge a change to the charter at any time
> >and ask for a vote of all committers, in which case a two-thirds
> >majority must approve the change.
> >
>
> Disagree.
> A contribnuter should intervi8ne though participation as an
> elected member.
> This should be dropped.
Not all Avalon committers are on the PMC. If we as the PMC
introduce something that an Avalon committer is uneasy with,
unknown to him until the deed is done, the Avalon committer
needs an outlet to let his voice be heard.
> >SUBPROJECTS
> >===========
> >avalon.apache.org is comprised of subprojects; a subproject is a
> >component whose scope is well defined. Each subproject has its own
> >set of developers.
> >
> >A new subproject proposal is submitted to the PMC, accepted
> by majority
> >committer vote, and then subject to final approval by the PMC.
> >
> >
>
> Not relevant to Avalon.
> We should not be subproject driven.
Ok.
> >COMMITTERS
> >==========
> >
> >Each subproject has a set of committers.
> >
> -1
> A recepie for fragmentation.
If we have no sub-projects, there is no issue here.
> >Committers are developers who
> >have read/write access to the source code repository. New committers
> >are added when a developer is nominated by a committer and
> approved by
> >at least 50 percent of the committers for that subproject with no
> >opposing votes. In most cases, new committers will already be
> >participating in the development process by submitting suggestions
> >and/or fixes via the bug report page or mailing lists.
>
> Probably needs to be rewritten from our perspective of a single
> committer community.
Ok. Propose something.
> Don't think this contributors text is needed because iut does
> not seem
> to impact the procedures.
We need to document the procedures for becoming a Committer.
>
> >INFRASTRUCTURE
> >==============
> >The avalon.apache.org project site must provide the following:
> >
> >Bug Database -- This is a system for tracking bugs and feature
> >requests.
> >
> >Subproject Source Repositories -- These are several CVS repositories
> >containing both the source code and documentation for the
> >subprojects. Each subproject will have a set of committers to its
> >repository.
> >
> >
> -1
>
> Recepie for fragmentation.
Again, if there is only one project and no subprojects, this
is a non-issue.
> >LICENSING
> >=========
> >All contributions to the avalon.apache.org project adhere to the "ASF
> >Source Code License." All further contributions must be made
> under the
> >same terms. All contributions must contain the following copyright
> >notice: [This changes now that the license is available]
> >
> >Copyright (c) {date} {name of contributor} and others. All rights
> >reserved. This program and the accompanying materials are made
> >available under the terms of the ASF Source Code License, as found in
> >the file ASF.code.license.html that is included in this distribution.
> >
>
> Should be revised to include the full ASF license in the
> source header.
+1
> >THE DEVELOPMENT PROCESS
> >=======================
> >The development process is intentionally lightweight; like other
> >Apache projects, the committers decide which changes may be committed
> >to the repository. Three +1 ('yes' votes) with no -1 ('no' votes or
> >vetoes) are needed to approve a code change. For efficiency,
> some code
> >changes from some contributors (e.g. feature additions, bug
> fixes) may
> >be approved in advance, in which case they may be committed first and
> >changed as needed, with conflicts resolved by majority vote of the
> >committers.
> >
>
> There are much stronger guidelines that this comming out of the
> incubator project - the above is insufficient.
Where are they? Provide some details.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Kick-starting the Charter process
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>At this location, you can see the current XML Project charter:
>http://cvs.apache.org/viewcvs.cgi/xml-admin/charter.txt
>
>I propose that we take that charter and adapt it to ours since it
>is easier to start from something already accepted ;P .
>
-1
From a clear an unambigouse process perspective its not a good example.
Yes - its perhaps a starting point but al of the stuff to do with
unanimouse decision making is a recepie for making the PMC totally
disfunctional.
>
>If we like it, let's commit it to CVS so that we can track changes.
>(I would do it, but I am behind a corporate firewall).
>
>Below is my first stab. Aside from writing the mission statement
>(which needs to be updated and commented on), I added this phrase
>to the PMC section:
>
>" It is also
>possible for a project depending on Avalon to nominate a representative.
>The representative of the client project still needs to be unanimously
>approved by all PMC members, and a two-thirds majority vote of
>committers. "
>
>
This can be much more cleanly addressed by simply reducing word - not
adding them. More notes below.
>The only other work I did was changing all references from XML to
>Avalon.
>
>
>------------------------ avalon.apache.org -----------------------------
>
>avalon.apache.org is a collaborative software development project
>dedicated to providing robust, full-featured, commercial-quality, and
>freely available component architecture.
>
"component and service architecture" - no just "component architecture"
> This project is managed in
>cooperation with various individuals worldwide (both independent and
>company-affiliated experts), who use the Internet to communicate, plan,
>and develop Avalon component software and related documentation.
>
>This charter briefly describes the mission, history, organization, and
>processes of the project.
>
>MISSION
>=======
>
>avalon.apache.org exists to promote the use of Avalon components.
>Component Based Design is a proven practice that helps create systems
>that are loosely coupled and easy to maintain. Component Based
>Design requires a general framework, components, and containers to
>function properly.
>
>avalon.apache.org defines the framework, the reference implementation
>of the containers, the compliance testing suite, and a set of components
>that can be used in third party projects. These components plug into each
>other using standard APIs (formal, de facto, or proposed). The components
>must be high performance, reliable, secure, and easy to use. The
>components must be part of an underlying architectural orchestration that
>will allow them to work together without major negotiations or breakage.
>
>We believe that the best way to define this Avalon architecture is by
>having both individuals and corporations collaborate on the best possible
>infrastructure, APIs, code, testing, and release cycles. Components must
>be vendor neutral and usable as core components for all.
>
>In order to achieve a coherent architecture between avalon.apache.org
>components and other components and applications, standards (formal or
>de facto) will be used as much as possible for both protocols and
>APIs. We will also allow the innovation of new protocols, APIs, and
>components in order to seed new concepts not yet defined by standards.
>
>
Sounds like a mission for commons - needs to be replaced with a concrete
mission that defines Avalon objectives.
>HISTORY
>=======
>
>This project was established under the direction of the newly-formed
>Apache Software Foundation in November 2002 to facilitate joint
>open-source development.
>
>
History should be more complete - including reference to Jakarta Avalon.
>THE PROJECT MANAGEMENT COMMITTEE
>================================
>The avalon.apache.org project is managed by a small, core group of
>contributors known as the Project Management Committee [PMC]. The PMC
>must have at least one officer from the Apache Board, who will be the
>Chairperson and report to the Apache Board. See
>http://www.apache.org/foundation/bylaws.html for reference.
>
>
I would change the first sentence to:
The avalon.apache.org project is managed by a elected group
known as the Project Management Committee [PMC].
>The PMC has the following responsibilities:
>
>1) Accepting new subproject proposals, formally submitting these
> proposals for committer vote, and creating the subproject (see
> SUBPROJECTS below).
>
Don;t like this notion of SUBPROJECT scope - the issue is not about
accepting a new subproject or not - its about properly managing the
project. Breaking out subprojects isn't management.
>2) Facilitating code or other donations by individuals or companies.
>3) Resolving license issues and other legal issues.
>4) Approving new committers.
>5) Ensuring that administrative and infrastructure work is completed.
>
Point 5 is infussiently defined and more an action item - should be
reworded to a responsibility. Is probably redundant anyway with respect
to point 8.
>6) Facilitating relationships among projects.
>7) Facilitating relationships between avalon.apache.org and the external
> world.
>8) Overseeing avalon.apache.org to ensure that the mission defined in
> this document is being fulfilled.
>9) Resolving conflicts within the project.
>
>To become a member of the PMC, an individual must be nominated by a
>contributor, unanimously approved by all PMC members, and approved by
>a two-thirds majority of committers. In most cases, developers will
>have actively contributed to development for at least six months
>before being considered for membership on the PMC.
>
Disagree.
If a single PMC member can veto the introduction of another member or
any process - we have a lame duck PMC. This whiole notion of "you must
be a committer" - "in most cases" - etc. is unnecessary noise - instead
this needs to be written with the objective of laying down the laws
about PMC evolution that gaurantee member representation.
Don;t have a replacement at the moment but coiinsider this as a big -1
on current wording here.
>It is also
>possible for a project depending on Avalon to nominate a representative.
>The representative of the client project still needs to be unanimously
>approved by all PMC members,
>
No, no no - any criteria for a unanimouse action is just plain
off-the-planet in terms of procedure - it would dramatically change my
perception of who I would consider for PMC membership - and for all the
wrong reasons.
>and a two-thirds majority vote of
>committers. The goal is to keep the membership of the core group
>at four to seven people in order to minimize the bureaucratic overhead
>required to keep the project operational.
>
>
Size qualification is unnecessry - this should be abiout the process for
change - which should be up to the community based on the procedures.
This sort of noice should be dropped from the charter.
>In the unlikely event that a member of the PMC becomes disruptive to
>the process or ceases to contribute for an extended period, said
>member may be removed by unanimous vote of remaining PMC members.
>
>
Same issue here - these sort of things should not be qualified by
"disruptive" - maybe soneone is being disruptive because the PMC isn't
doing what needs to be done - whatever - the policies should not
precondition a procedure with adjectives like this - and secondly - the
ugly "unanimous" word appears again - in any sort of body that is
anywhaere near representative - things like thins are at worst case a
2/3 majority - as are things like changing the charter.
>The PMC is responsible for maintaining and updating this
>charter. Development must follow the process outlined below, so any
>change to the development process necessitates a change to the
>charter. Changes must be unanimously approved by all members of the
>PMC.
>
2/3 - not unanimous.
>A contributor may challenge a change to the charter at any time
>and ask for a vote of all committers, in which case a two-thirds
>majority must approve the change.
>
Disagree.
A contribnuter should intervi8ne though participation as an elected member.
This should be dropped.
>
>SUBPROJECTS
>===========
>avalon.apache.org is comprised of subprojects; a subproject is a
>component whose scope is well defined. Each subproject has its own
>set of developers.
>
>A new subproject proposal is submitted to the PMC, accepted by majority
>committer vote, and then subject to final approval by the PMC.
>
>
Not relevant to Avalon.
We should not be subproject driven.
>COMMITTERS
>==========
>
>Each subproject has a set of committers.
>
-1
A recepie for fragmentation.
>Committers are developers who
>have read/write access to the source code repository. New committers
>are added when a developer is nominated by a committer and approved by
>at least 50 percent of the committers for that subproject with no
>opposing votes. In most cases, new committers will already be
>participating in the development process by submitting suggestions
>and/or fixes via the bug report page or mailing lists.
>
>
Probably needs to be rewritten from our perspective of a single
committer community.
>CONTRIBUTORS
>============
>Like all Apache projects, the Avalon project is a meritocracy -- the more
>work you do, the more you are allowed to do. Occasional contributors
>will be able to report bugs and participate in the mailing lists.
>
>Specific changes to a product proposed for discussion or voting on the
>appropriate development mailing list should be presented in the form
>of input to the patch command. When sent to the mailing list, the
>message should contain a subject beginning with [PATCH] and including
>a distinctive one-line summary that corresponds to the action item for
>that patch.
>
>Use the diff -u command from the original software file(s) to the
>modified software file(s) to create the patch. Patches should be
>submitted against the latest CVS versions of the software to avoid
>conflicts and ensure that you are not submitting a patch for a problem
>that has already been resolved.
>
>Developers who make regular and substantial contributions may become
>committers as described above.
>
>
Don't think this contributors text is needed because iut does not seem
to impact the procedures.
>INFRASTRUCTURE
>==============
>The avalon.apache.org project site must provide the following:
>
>Bug Database -- This is a system for tracking bugs and feature
>requests.
>
>Subproject Source Repositories -- These are several CVS repositories
>containing both the source code and documentation for the
>subprojects. Each subproject will have a set of committers to its
>repository.
>
>
-1
Recepie for fragmentation.
>Website -- An avalon.apache.org website will contain information about
>the avalon.apache.org project, including documentation, downloads of
>releases, and this charter. Each subproject will have its own website
>with subproject information.
>
>PMC Mailing List -- This list is for PMC business requiring
>confidentiality, particularly when an individual or company requests
>discretion. All other PMC business should be done on the general
>mailing list.
>
>General Mailing List -- This mailing list is open to the public. It is
>intended for discussions that cross subprojects.
>
>
Would change the above to "Mailing Lists" (plural) and not go into
details here.
>Subproject Mailing Lists -- Each subproject should have a devoted mailing
>list. Many subprojects may wish to have both user and development
>lists. The individual subprojects may decide on the exact structure of
>their mailing lists.
>
>
-1
Recipe for fragmentation.
>LICENSING
>=========
>All contributions to the avalon.apache.org project adhere to the "ASF
>Source Code License." All further contributions must be made under the
>same terms. All contributions must contain the following copyright
>notice: [This changes now that the license is available]
>
>Copyright (c) {date} {name of contributor} and others. All rights
>reserved. This program and the accompanying materials are made
>available under the terms of the ASF Source Code License, as found in
>the file ASF.code.license.html that is included in this distribution.
>
Should be revised to include the full ASF license in the source header.
>
>THE DEVELOPMENT PROCESS
>=======================
>The development process is intentionally lightweight; like other
>Apache projects, the committers decide which changes may be committed
>to the repository. Three +1 ('yes' votes) with no -1 ('no' votes or
>vetoes) are needed to approve a code change. For efficiency, some code
>changes from some contributors (e.g. feature additions, bug fixes) may
>be approved in advance, in which case they may be committed first and
>changed as needed, with conflicts resolved by majority vote of the
>committers.
>
There are much stronger guidelines that this comming out of the
incubator project - the above is insufficient.
>
>SUBPROJECT REQUIREMENTS
>=======================
>Each subproject must have a set of requirements as well as an
>up-to-date release plan and design document on its dedicated web page.
>
>It must be possible for each subproject to plug into the Gump nightly
>build system (see http://jakarta.apache.org/builds/gump). It is
>recommended that each subproject have a smoke-test system that works at
>least as a basic integration test.
>
Should be replaced with Avalon project requierements concerning actions
plans, release plans, goals, etc. This could be broken down into
product plans - but subprojects.
>
>RELATIONSHIP TO OTHER APACHE PROJECTS
>=====================================
>The avalon.apache.org project should work closely with other Apache
>projects, such as Jakarta and the Apache Server, to avoid redundancy
>and achieve a coherent architecture among avalon.apache.org and these
>projects.
>
>
>
This is ok.
Cheers, Steve.
>
>--
>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: Kick-starting the Charter process
Posted by Leo Simons <le...@apache.org>.
Hi all,
there's a few new projects with a few new PMCs. They all need a charter.
My gut feeling tells me that large parts of the various charters for the
various projects will turn out to be quite similar to each other.
It makes sense to me that we pour together resources to work on this
together. It also makes sense to me to have as many of the "Wise and
Knowledgeable Apache Elders" as possible help out with this and provide,
well, wisdom and knowledge.
Should we work intimately together on this? If so, where/how/etc?
cheers,
- Leo the Reuse Fanatic
Re: Kick-starting the Charter process
Posted by Leo Simons <le...@apache.org>.
Hi all,
there's a few new projects with a few new PMCs. They all need a charter.
My gut feeling tells me that large parts of the various charters for the
various projects will turn out to be quite similar to each other.
It makes sense to me that we pour together resources to work on this
together. It also makes sense to me to have as many of the "Wise and
Knowledgeable Apache Elders" as possible help out with this and provide,
well, wisdom and knowledge.
Should we work intimately together on this? If so, where/how/etc?
cheers,
- Leo the Reuse Fanatic
Re: Kick-starting the Charter process
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>At this location, you can see the current XML Project charter:
>http://cvs.apache.org/viewcvs.cgi/xml-admin/charter.txt
>
>I propose that we take that charter and adapt it to ours since it
>is easier to start from something already accepted ;P .
>
-1
From a clear an unambigouse process perspective its not a good example.
Yes - its perhaps a starting point but al of the stuff to do with
unanimouse decision making is a recepie for making the PMC totally
disfunctional.
>
>If we like it, let's commit it to CVS so that we can track changes.
>(I would do it, but I am behind a corporate firewall).
>
>Below is my first stab. Aside from writing the mission statement
>(which needs to be updated and commented on), I added this phrase
>to the PMC section:
>
>" It is also
>possible for a project depending on Avalon to nominate a representative.
>The representative of the client project still needs to be unanimously
>approved by all PMC members, and a two-thirds majority vote of
>committers. "
>
>
This can be much more cleanly addressed by simply reducing word - not
adding them. More notes below.
>The only other work I did was changing all references from XML to
>Avalon.
>
>
>------------------------ avalon.apache.org -----------------------------
>
>avalon.apache.org is a collaborative software development project
>dedicated to providing robust, full-featured, commercial-quality, and
>freely available component architecture.
>
"component and service architecture" - no just "component architecture"
> This project is managed in
>cooperation with various individuals worldwide (both independent and
>company-affiliated experts), who use the Internet to communicate, plan,
>and develop Avalon component software and related documentation.
>
>This charter briefly describes the mission, history, organization, and
>processes of the project.
>
>MISSION
>=======
>
>avalon.apache.org exists to promote the use of Avalon components.
>Component Based Design is a proven practice that helps create systems
>that are loosely coupled and easy to maintain. Component Based
>Design requires a general framework, components, and containers to
>function properly.
>
>avalon.apache.org defines the framework, the reference implementation
>of the containers, the compliance testing suite, and a set of components
>that can be used in third party projects. These components plug into each
>other using standard APIs (formal, de facto, or proposed). The components
>must be high performance, reliable, secure, and easy to use. The
>components must be part of an underlying architectural orchestration that
>will allow them to work together without major negotiations or breakage.
>
>We believe that the best way to define this Avalon architecture is by
>having both individuals and corporations collaborate on the best possible
>infrastructure, APIs, code, testing, and release cycles. Components must
>be vendor neutral and usable as core components for all.
>
>In order to achieve a coherent architecture between avalon.apache.org
>components and other components and applications, standards (formal or
>de facto) will be used as much as possible for both protocols and
>APIs. We will also allow the innovation of new protocols, APIs, and
>components in order to seed new concepts not yet defined by standards.
>
>
Sounds like a mission for commons - needs to be replaced with a concrete
mission that defines Avalon objectives.
>HISTORY
>=======
>
>This project was established under the direction of the newly-formed
>Apache Software Foundation in November 2002 to facilitate joint
>open-source development.
>
>
History should be more complete - including reference to Jakarta Avalon.
>THE PROJECT MANAGEMENT COMMITTEE
>================================
>The avalon.apache.org project is managed by a small, core group of
>contributors known as the Project Management Committee [PMC]. The PMC
>must have at least one officer from the Apache Board, who will be the
>Chairperson and report to the Apache Board. See
>http://www.apache.org/foundation/bylaws.html for reference.
>
>
I would change the first sentence to:
The avalon.apache.org project is managed by a elected group
known as the Project Management Committee [PMC].
>The PMC has the following responsibilities:
>
>1) Accepting new subproject proposals, formally submitting these
> proposals for committer vote, and creating the subproject (see
> SUBPROJECTS below).
>
Don;t like this notion of SUBPROJECT scope - the issue is not about
accepting a new subproject or not - its about properly managing the
project. Breaking out subprojects isn't management.
>2) Facilitating code or other donations by individuals or companies.
>3) Resolving license issues and other legal issues.
>4) Approving new committers.
>5) Ensuring that administrative and infrastructure work is completed.
>
Point 5 is infussiently defined and more an action item - should be
reworded to a responsibility. Is probably redundant anyway with respect
to point 8.
>6) Facilitating relationships among projects.
>7) Facilitating relationships between avalon.apache.org and the external
> world.
>8) Overseeing avalon.apache.org to ensure that the mission defined in
> this document is being fulfilled.
>9) Resolving conflicts within the project.
>
>To become a member of the PMC, an individual must be nominated by a
>contributor, unanimously approved by all PMC members, and approved by
>a two-thirds majority of committers. In most cases, developers will
>have actively contributed to development for at least six months
>before being considered for membership on the PMC.
>
Disagree.
If a single PMC member can veto the introduction of another member or
any process - we have a lame duck PMC. This whiole notion of "you must
be a committer" - "in most cases" - etc. is unnecessary noise - instead
this needs to be written with the objective of laying down the laws
about PMC evolution that gaurantee member representation.
Don;t have a replacement at the moment but coiinsider this as a big -1
on current wording here.
>It is also
>possible for a project depending on Avalon to nominate a representative.
>The representative of the client project still needs to be unanimously
>approved by all PMC members,
>
No, no no - any criteria for a unanimouse action is just plain
off-the-planet in terms of procedure - it would dramatically change my
perception of who I would consider for PMC membership - and for all the
wrong reasons.
>and a two-thirds majority vote of
>committers. The goal is to keep the membership of the core group
>at four to seven people in order to minimize the bureaucratic overhead
>required to keep the project operational.
>
>
Size qualification is unnecessry - this should be abiout the process for
change - which should be up to the community based on the procedures.
This sort of noice should be dropped from the charter.
>In the unlikely event that a member of the PMC becomes disruptive to
>the process or ceases to contribute for an extended period, said
>member may be removed by unanimous vote of remaining PMC members.
>
>
Same issue here - these sort of things should not be qualified by
"disruptive" - maybe soneone is being disruptive because the PMC isn't
doing what needs to be done - whatever - the policies should not
precondition a procedure with adjectives like this - and secondly - the
ugly "unanimous" word appears again - in any sort of body that is
anywhaere near representative - things like thins are at worst case a
2/3 majority - as are things like changing the charter.
>The PMC is responsible for maintaining and updating this
>charter. Development must follow the process outlined below, so any
>change to the development process necessitates a change to the
>charter. Changes must be unanimously approved by all members of the
>PMC.
>
2/3 - not unanimous.
>A contributor may challenge a change to the charter at any time
>and ask for a vote of all committers, in which case a two-thirds
>majority must approve the change.
>
Disagree.
A contribnuter should intervi8ne though participation as an elected member.
This should be dropped.
>
>SUBPROJECTS
>===========
>avalon.apache.org is comprised of subprojects; a subproject is a
>component whose scope is well defined. Each subproject has its own
>set of developers.
>
>A new subproject proposal is submitted to the PMC, accepted by majority
>committer vote, and then subject to final approval by the PMC.
>
>
Not relevant to Avalon.
We should not be subproject driven.
>COMMITTERS
>==========
>
>Each subproject has a set of committers.
>
-1
A recepie for fragmentation.
>Committers are developers who
>have read/write access to the source code repository. New committers
>are added when a developer is nominated by a committer and approved by
>at least 50 percent of the committers for that subproject with no
>opposing votes. In most cases, new committers will already be
>participating in the development process by submitting suggestions
>and/or fixes via the bug report page or mailing lists.
>
>
Probably needs to be rewritten from our perspective of a single
committer community.
>CONTRIBUTORS
>============
>Like all Apache projects, the Avalon project is a meritocracy -- the more
>work you do, the more you are allowed to do. Occasional contributors
>will be able to report bugs and participate in the mailing lists.
>
>Specific changes to a product proposed for discussion or voting on the
>appropriate development mailing list should be presented in the form
>of input to the patch command. When sent to the mailing list, the
>message should contain a subject beginning with [PATCH] and including
>a distinctive one-line summary that corresponds to the action item for
>that patch.
>
>Use the diff -u command from the original software file(s) to the
>modified software file(s) to create the patch. Patches should be
>submitted against the latest CVS versions of the software to avoid
>conflicts and ensure that you are not submitting a patch for a problem
>that has already been resolved.
>
>Developers who make regular and substantial contributions may become
>committers as described above.
>
>
Don't think this contributors text is needed because iut does not seem
to impact the procedures.
>INFRASTRUCTURE
>==============
>The avalon.apache.org project site must provide the following:
>
>Bug Database -- This is a system for tracking bugs and feature
>requests.
>
>Subproject Source Repositories -- These are several CVS repositories
>containing both the source code and documentation for the
>subprojects. Each subproject will have a set of committers to its
>repository.
>
>
-1
Recepie for fragmentation.
>Website -- An avalon.apache.org website will contain information about
>the avalon.apache.org project, including documentation, downloads of
>releases, and this charter. Each subproject will have its own website
>with subproject information.
>
>PMC Mailing List -- This list is for PMC business requiring
>confidentiality, particularly when an individual or company requests
>discretion. All other PMC business should be done on the general
>mailing list.
>
>General Mailing List -- This mailing list is open to the public. It is
>intended for discussions that cross subprojects.
>
>
Would change the above to "Mailing Lists" (plural) and not go into
details here.
>Subproject Mailing Lists -- Each subproject should have a devoted mailing
>list. Many subprojects may wish to have both user and development
>lists. The individual subprojects may decide on the exact structure of
>their mailing lists.
>
>
-1
Recipe for fragmentation.
>LICENSING
>=========
>All contributions to the avalon.apache.org project adhere to the "ASF
>Source Code License." All further contributions must be made under the
>same terms. All contributions must contain the following copyright
>notice: [This changes now that the license is available]
>
>Copyright (c) {date} {name of contributor} and others. All rights
>reserved. This program and the accompanying materials are made
>available under the terms of the ASF Source Code License, as found in
>the file ASF.code.license.html that is included in this distribution.
>
Should be revised to include the full ASF license in the source header.
>
>THE DEVELOPMENT PROCESS
>=======================
>The development process is intentionally lightweight; like other
>Apache projects, the committers decide which changes may be committed
>to the repository. Three +1 ('yes' votes) with no -1 ('no' votes or
>vetoes) are needed to approve a code change. For efficiency, some code
>changes from some contributors (e.g. feature additions, bug fixes) may
>be approved in advance, in which case they may be committed first and
>changed as needed, with conflicts resolved by majority vote of the
>committers.
>
There are much stronger guidelines that this comming out of the
incubator project - the above is insufficient.
>
>SUBPROJECT REQUIREMENTS
>=======================
>Each subproject must have a set of requirements as well as an
>up-to-date release plan and design document on its dedicated web page.
>
>It must be possible for each subproject to plug into the Gump nightly
>build system (see http://jakarta.apache.org/builds/gump). It is
>recommended that each subproject have a smoke-test system that works at
>least as a basic integration test.
>
Should be replaced with Avalon project requierements concerning actions
plans, release plans, goals, etc. This could be broken down into
product plans - but subprojects.
>
>RELATIONSHIP TO OTHER APACHE PROJECTS
>=====================================
>The avalon.apache.org project should work closely with other Apache
>projects, such as Jakarta and the Apache Server, to avoid redundancy
>and achieve a coherent architecture among avalon.apache.org and these
>projects.
>
>
>
This is ok.
Cheers, Steve.
>
>--
>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: Kick-starting the Charter process
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>At this location, you can see the current XML Project charter:
>http://cvs.apache.org/viewcvs.cgi/xml-admin/charter.txt
>
>I propose that we take that charter and adapt it to ours since it
>is easier to start from something already accepted ;P .
>
-1
From a clear an unambigouse process perspective its not a good example.
Yes - its perhaps a starting point but al of the stuff to do with
unanimouse decision making is a recepie for making the PMC totally
disfunctional.
>
>If we like it, let's commit it to CVS so that we can track changes.
>(I would do it, but I am behind a corporate firewall).
>
>Below is my first stab. Aside from writing the mission statement
>(which needs to be updated and commented on), I added this phrase
>to the PMC section:
>
>" It is also
>possible for a project depending on Avalon to nominate a representative.
>The representative of the client project still needs to be unanimously
>approved by all PMC members, and a two-thirds majority vote of
>committers. "
>
>
This can be much more cleanly addressed by simply reducing word - not
adding them. More notes below.
>The only other work I did was changing all references from XML to
>Avalon.
>
>
>------------------------ avalon.apache.org -----------------------------
>
>avalon.apache.org is a collaborative software development project
>dedicated to providing robust, full-featured, commercial-quality, and
>freely available component architecture.
>
"component and service architecture" - no just "component architecture"
> This project is managed in
>cooperation with various individuals worldwide (both independent and
>company-affiliated experts), who use the Internet to communicate, plan,
>and develop Avalon component software and related documentation.
>
>This charter briefly describes the mission, history, organization, and
>processes of the project.
>
>MISSION
>=======
>
>avalon.apache.org exists to promote the use of Avalon components.
>Component Based Design is a proven practice that helps create systems
>that are loosely coupled and easy to maintain. Component Based
>Design requires a general framework, components, and containers to
>function properly.
>
>avalon.apache.org defines the framework, the reference implementation
>of the containers, the compliance testing suite, and a set of components
>that can be used in third party projects. These components plug into each
>other using standard APIs (formal, de facto, or proposed). The components
>must be high performance, reliable, secure, and easy to use. The
>components must be part of an underlying architectural orchestration that
>will allow them to work together without major negotiations or breakage.
>
>We believe that the best way to define this Avalon architecture is by
>having both individuals and corporations collaborate on the best possible
>infrastructure, APIs, code, testing, and release cycles. Components must
>be vendor neutral and usable as core components for all.
>
>In order to achieve a coherent architecture between avalon.apache.org
>components and other components and applications, standards (formal or
>de facto) will be used as much as possible for both protocols and
>APIs. We will also allow the innovation of new protocols, APIs, and
>components in order to seed new concepts not yet defined by standards.
>
>
Sounds like a mission for commons - needs to be replaced with a concrete
mission that defines Avalon objectives.
>HISTORY
>=======
>
>This project was established under the direction of the newly-formed
>Apache Software Foundation in November 2002 to facilitate joint
>open-source development.
>
>
History should be more complete - including reference to Jakarta Avalon.
>THE PROJECT MANAGEMENT COMMITTEE
>================================
>The avalon.apache.org project is managed by a small, core group of
>contributors known as the Project Management Committee [PMC]. The PMC
>must have at least one officer from the Apache Board, who will be the
>Chairperson and report to the Apache Board. See
>http://www.apache.org/foundation/bylaws.html for reference.
>
>
I would change the first sentence to:
The avalon.apache.org project is managed by a elected group
known as the Project Management Committee [PMC].
>The PMC has the following responsibilities:
>
>1) Accepting new subproject proposals, formally submitting these
> proposals for committer vote, and creating the subproject (see
> SUBPROJECTS below).
>
Don;t like this notion of SUBPROJECT scope - the issue is not about
accepting a new subproject or not - its about properly managing the
project. Breaking out subprojects isn't management.
>2) Facilitating code or other donations by individuals or companies.
>3) Resolving license issues and other legal issues.
>4) Approving new committers.
>5) Ensuring that administrative and infrastructure work is completed.
>
Point 5 is infussiently defined and more an action item - should be
reworded to a responsibility. Is probably redundant anyway with respect
to point 8.
>6) Facilitating relationships among projects.
>7) Facilitating relationships between avalon.apache.org and the external
> world.
>8) Overseeing avalon.apache.org to ensure that the mission defined in
> this document is being fulfilled.
>9) Resolving conflicts within the project.
>
>To become a member of the PMC, an individual must be nominated by a
>contributor, unanimously approved by all PMC members, and approved by
>a two-thirds majority of committers. In most cases, developers will
>have actively contributed to development for at least six months
>before being considered for membership on the PMC.
>
Disagree.
If a single PMC member can veto the introduction of another member or
any process - we have a lame duck PMC. This whiole notion of "you must
be a committer" - "in most cases" - etc. is unnecessary noise - instead
this needs to be written with the objective of laying down the laws
about PMC evolution that gaurantee member representation.
Don;t have a replacement at the moment but coiinsider this as a big -1
on current wording here.
>It is also
>possible for a project depending on Avalon to nominate a representative.
>The representative of the client project still needs to be unanimously
>approved by all PMC members,
>
No, no no - any criteria for a unanimouse action is just plain
off-the-planet in terms of procedure - it would dramatically change my
perception of who I would consider for PMC membership - and for all the
wrong reasons.
>and a two-thirds majority vote of
>committers. The goal is to keep the membership of the core group
>at four to seven people in order to minimize the bureaucratic overhead
>required to keep the project operational.
>
>
Size qualification is unnecessry - this should be abiout the process for
change - which should be up to the community based on the procedures.
This sort of noice should be dropped from the charter.
>In the unlikely event that a member of the PMC becomes disruptive to
>the process or ceases to contribute for an extended period, said
>member may be removed by unanimous vote of remaining PMC members.
>
>
Same issue here - these sort of things should not be qualified by
"disruptive" - maybe soneone is being disruptive because the PMC isn't
doing what needs to be done - whatever - the policies should not
precondition a procedure with adjectives like this - and secondly - the
ugly "unanimous" word appears again - in any sort of body that is
anywhaere near representative - things like thins are at worst case a
2/3 majority - as are things like changing the charter.
>The PMC is responsible for maintaining and updating this
>charter. Development must follow the process outlined below, so any
>change to the development process necessitates a change to the
>charter. Changes must be unanimously approved by all members of the
>PMC.
>
2/3 - not unanimous.
>A contributor may challenge a change to the charter at any time
>and ask for a vote of all committers, in which case a two-thirds
>majority must approve the change.
>
Disagree.
A contribnuter should intervi8ne though participation as an elected member.
This should be dropped.
>
>SUBPROJECTS
>===========
>avalon.apache.org is comprised of subprojects; a subproject is a
>component whose scope is well defined. Each subproject has its own
>set of developers.
>
>A new subproject proposal is submitted to the PMC, accepted by majority
>committer vote, and then subject to final approval by the PMC.
>
>
Not relevant to Avalon.
We should not be subproject driven.
>COMMITTERS
>==========
>
>Each subproject has a set of committers.
>
-1
A recepie for fragmentation.
>Committers are developers who
>have read/write access to the source code repository. New committers
>are added when a developer is nominated by a committer and approved by
>at least 50 percent of the committers for that subproject with no
>opposing votes. In most cases, new committers will already be
>participating in the development process by submitting suggestions
>and/or fixes via the bug report page or mailing lists.
>
>
Probably needs to be rewritten from our perspective of a single
committer community.
>CONTRIBUTORS
>============
>Like all Apache projects, the Avalon project is a meritocracy -- the more
>work you do, the more you are allowed to do. Occasional contributors
>will be able to report bugs and participate in the mailing lists.
>
>Specific changes to a product proposed for discussion or voting on the
>appropriate development mailing list should be presented in the form
>of input to the patch command. When sent to the mailing list, the
>message should contain a subject beginning with [PATCH] and including
>a distinctive one-line summary that corresponds to the action item for
>that patch.
>
>Use the diff -u command from the original software file(s) to the
>modified software file(s) to create the patch. Patches should be
>submitted against the latest CVS versions of the software to avoid
>conflicts and ensure that you are not submitting a patch for a problem
>that has already been resolved.
>
>Developers who make regular and substantial contributions may become
>committers as described above.
>
>
Don't think this contributors text is needed because iut does not seem
to impact the procedures.
>INFRASTRUCTURE
>==============
>The avalon.apache.org project site must provide the following:
>
>Bug Database -- This is a system for tracking bugs and feature
>requests.
>
>Subproject Source Repositories -- These are several CVS repositories
>containing both the source code and documentation for the
>subprojects. Each subproject will have a set of committers to its
>repository.
>
>
-1
Recepie for fragmentation.
>Website -- An avalon.apache.org website will contain information about
>the avalon.apache.org project, including documentation, downloads of
>releases, and this charter. Each subproject will have its own website
>with subproject information.
>
>PMC Mailing List -- This list is for PMC business requiring
>confidentiality, particularly when an individual or company requests
>discretion. All other PMC business should be done on the general
>mailing list.
>
>General Mailing List -- This mailing list is open to the public. It is
>intended for discussions that cross subprojects.
>
>
Would change the above to "Mailing Lists" (plural) and not go into
details here.
>Subproject Mailing Lists -- Each subproject should have a devoted mailing
>list. Many subprojects may wish to have both user and development
>lists. The individual subprojects may decide on the exact structure of
>their mailing lists.
>
>
-1
Recipe for fragmentation.
>LICENSING
>=========
>All contributions to the avalon.apache.org project adhere to the "ASF
>Source Code License." All further contributions must be made under the
>same terms. All contributions must contain the following copyright
>notice: [This changes now that the license is available]
>
>Copyright (c) {date} {name of contributor} and others. All rights
>reserved. This program and the accompanying materials are made
>available under the terms of the ASF Source Code License, as found in
>the file ASF.code.license.html that is included in this distribution.
>
Should be revised to include the full ASF license in the source header.
>
>THE DEVELOPMENT PROCESS
>=======================
>The development process is intentionally lightweight; like other
>Apache projects, the committers decide which changes may be committed
>to the repository. Three +1 ('yes' votes) with no -1 ('no' votes or
>vetoes) are needed to approve a code change. For efficiency, some code
>changes from some contributors (e.g. feature additions, bug fixes) may
>be approved in advance, in which case they may be committed first and
>changed as needed, with conflicts resolved by majority vote of the
>committers.
>
There are much stronger guidelines that this comming out of the
incubator project - the above is insufficient.
>
>SUBPROJECT REQUIREMENTS
>=======================
>Each subproject must have a set of requirements as well as an
>up-to-date release plan and design document on its dedicated web page.
>
>It must be possible for each subproject to plug into the Gump nightly
>build system (see http://jakarta.apache.org/builds/gump). It is
>recommended that each subproject have a smoke-test system that works at
>least as a basic integration test.
>
Should be replaced with Avalon project requierements concerning actions
plans, release plans, goals, etc. This could be broken down into
product plans - but subprojects.
>
>RELATIONSHIP TO OTHER APACHE PROJECTS
>=====================================
>The avalon.apache.org project should work closely with other Apache
>projects, such as Jakarta and the Apache Server, to avoid redundancy
>and achieve a coherent architecture among avalon.apache.org and these
>projects.
>
>
>
This is ok.
Cheers, Steve.
>
>--
>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: Kick-starting the Charter process
Posted by Leo Simons <le...@apache.org>.
Hi all,
there's a few new projects with a few new PMCs. They all need a charter.
My gut feeling tells me that large parts of the various charters for the
various projects will turn out to be quite similar to each other.
It makes sense to me that we pour together resources to work on this
together. It also makes sense to me to have as many of the "Wise and
Knowledgeable Apache Elders" as possible help out with this and provide,
well, wisdom and knowledge.
Should we work intimately together on this? If so, where/how/etc?
cheers,
- Leo the Reuse Fanatic
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Kick-starting the Charter process
Posted by Leo Simons <le...@apache.org>.
Hi all,
there's a few new projects with a few new PMCs. They all need a charter.
My gut feeling tells me that large parts of the various charters for the
various projects will turn out to be quite similar to each other.
It makes sense to me that we pour together resources to work on this
together. It also makes sense to me to have as many of the "Wise and
Knowledgeable Apache Elders" as possible help out with this and provide,
well, wisdom and knowledge.
Should we work intimately together on this? If so, where/how/etc?
cheers,
- Leo the Reuse Fanatic
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Kick-starting the Charter process
Posted by Sam Ruby <ru...@apache.org>.
I need to rush off, but some quick responses for now...
Noel J. Bergman wrote:
>
> Please understand that I am *not* trying to be difficult. I am simply
> trying to understand how the ASF Bylaws, which are a legal document of the
> Corporation, impact this process.
To the contrary, I very much appreciate the research that you have done.
If that did not show through, it is I that should appologize.
> So what you are saying is that the PMC Chairman is legally the Corporate
> Oficer who designates PMC members, but that as an internal process the
> designated Officer abides by whatever rules are established by the
> Community?
If the PMC Chairman does not abide by the charter of the project, the
board will take action.
>>Independent of prior charters that may have been approved, I
>>intend to review future charters with an eye for (1) effectively
>>demonstrating oversight and (2) adherance to the "collaborative,
>>consensus based development process" that is supposed to characterize
>>all Apache projects.
>
> Excellent! :-) Do you have a prototype that people can use to start?
No, I just plan to throw rocks. :-)
JUST KIDDING! Gotta run. More later.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Kick-starting the Charter process
Posted by Sam Ruby <ru...@apache.org>.
I need to rush off, but some quick responses for now...
Noel J. Bergman wrote:
>
> Please understand that I am *not* trying to be difficult. I am simply
> trying to understand how the ASF Bylaws, which are a legal document of the
> Corporation, impact this process.
To the contrary, I very much appreciate the research that you have done.
If that did not show through, it is I that should appologize.
> So what you are saying is that the PMC Chairman is legally the Corporate
> Oficer who designates PMC members, but that as an internal process the
> designated Officer abides by whatever rules are established by the
> Community?
If the PMC Chairman does not abide by the charter of the project, the
board will take action.
>>Independent of prior charters that may have been approved, I
>>intend to review future charters with an eye for (1) effectively
>>demonstrating oversight and (2) adherance to the "collaborative,
>>consensus based development process" that is supposed to characterize
>>all Apache projects.
>
> Excellent! :-) Do you have a prototype that people can use to start?
No, I just plan to throw rocks. :-)
JUST KIDDING! Gotta run. More later.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Kick-starting the Charter process
Posted by Sam Ruby <ru...@apache.org>.
I need to rush off, but some quick responses for now...
Noel J. Bergman wrote:
>
> Please understand that I am *not* trying to be difficult. I am simply
> trying to understand how the ASF Bylaws, which are a legal document of the
> Corporation, impact this process.
To the contrary, I very much appreciate the research that you have done.
If that did not show through, it is I that should appologize.
> So what you are saying is that the PMC Chairman is legally the Corporate
> Oficer who designates PMC members, but that as an internal process the
> designated Officer abides by whatever rules are established by the
> Community?
If the PMC Chairman does not abide by the charter of the project, the
board will take action.
>>Independent of prior charters that may have been approved, I
>>intend to review future charters with an eye for (1) effectively
>>demonstrating oversight and (2) adherance to the "collaborative,
>>consensus based development process" that is supposed to characterize
>>all Apache projects.
>
> Excellent! :-) Do you have a prototype that people can use to start?
No, I just plan to throw rocks. :-)
JUST KIDDING! Gotta run. More later.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Kick-starting the Charter process
Posted by "Noel J. Bergman" <no...@devtech.com>.
Sam,
Please understand that I am *not* trying to be difficult. I am simply
trying to understand how the ASF Bylaws, which are a legal document of the
Corporation, impact this process.
> The board appoints officers. Officers are empowered to appoint members.
> The appointment process is specified by the project's charter.
>From ASF Bylaw 6.3: "In addition to the officers of the corporation, the
Board of Directors may, by resolution, establish one or more Project
Management Committees consisting of at least one officer of the corporation,
who shall be designated chairman of such committee, and may include one or
more other members of the corporation."
Sorry, you are correct and I mis-read it initially. It isn't a ASF Board
member, it is an ASF Officer, whom are listed here:
http://www.apache.org/foundation/. The bylaws do state that the PMC
Chairman SHALL be an Officer of the Corporation. But ASF Bylaw 6.1 does
include: "and such other officers and assistant officers and agents as may
be deemed necessary may be elected or appointed by the Board of Directors
from time to time", so perhaps all that is necessary is for the Board to
designate each PMC Chairman (e.g., Nicola) as an ASF Officer.
>From ASF Bylaws 6.4: "The officers of the corporation and the members of
each existing Project Management Committee shall be appointed by the Board
of Directors or appointed by an officer empowered by the Board to make such
appointment."
So what you are saying is that the PMC Chairman is legally the Corporate
Oficer who designates PMC members, but that as an internal process the
designated Officer abides by whatever rules are established by the
Community?
> Nicola Ken is an ASF member. As are Berin and Stefano.
Sorry. I was going by http://www.apache.org/foundation/members.html, which
shows only Stefano from that list. Apologies (and congratulations) to
Nicola and Berin.
> Independent of prior charters that may have been approved, I
> intend to review future charters with an eye for (1) effectively
> demonstrating oversight and (2) adherance to the "collaborative,
> consensus based development process" that is supposed to characterize
> all Apache projects.
Excellent! :-) Do you have a prototype that people can use to start?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Kick-starting the Charter process
Posted by "Noel J. Bergman" <no...@devtech.com>.
Sam,
Please understand that I am *not* trying to be difficult. I am simply
trying to understand how the ASF Bylaws, which are a legal document of the
Corporation, impact this process.
> The board appoints officers. Officers are empowered to appoint members.
> The appointment process is specified by the project's charter.
>From ASF Bylaw 6.3: "In addition to the officers of the corporation, the
Board of Directors may, by resolution, establish one or more Project
Management Committees consisting of at least one officer of the corporation,
who shall be designated chairman of such committee, and may include one or
more other members of the corporation."
Sorry, you are correct and I mis-read it initially. It isn't a ASF Board
member, it is an ASF Officer, whom are listed here:
http://www.apache.org/foundation/. The bylaws do state that the PMC
Chairman SHALL be an Officer of the Corporation. But ASF Bylaw 6.1 does
include: "and such other officers and assistant officers and agents as may
be deemed necessary may be elected or appointed by the Board of Directors
from time to time", so perhaps all that is necessary is for the Board to
designate each PMC Chairman (e.g., Nicola) as an ASF Officer.
>From ASF Bylaws 6.4: "The officers of the corporation and the members of
each existing Project Management Committee shall be appointed by the Board
of Directors or appointed by an officer empowered by the Board to make such
appointment."
So what you are saying is that the PMC Chairman is legally the Corporate
Oficer who designates PMC members, but that as an internal process the
designated Officer abides by whatever rules are established by the
Community?
> Nicola Ken is an ASF member. As are Berin and Stefano.
Sorry. I was going by http://www.apache.org/foundation/members.html, which
shows only Stefano from that list. Apologies (and congratulations) to
Nicola and Berin.
> Independent of prior charters that may have been approved, I
> intend to review future charters with an eye for (1) effectively
> demonstrating oversight and (2) adherance to the "collaborative,
> consensus based development process" that is supposed to characterize
> all Apache projects.
Excellent! :-) Do you have a prototype that people can use to start?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Kick-starting the Charter process
Posted by "Noel J. Bergman" <no...@devtech.com>.
Sam,
Please understand that I am *not* trying to be difficult. I am simply
trying to understand how the ASF Bylaws, which are a legal document of the
Corporation, impact this process.
> The board appoints officers. Officers are empowered to appoint members.
> The appointment process is specified by the project's charter.
>From ASF Bylaw 6.3: "In addition to the officers of the corporation, the
Board of Directors may, by resolution, establish one or more Project
Management Committees consisting of at least one officer of the corporation,
who shall be designated chairman of such committee, and may include one or
more other members of the corporation."
Sorry, you are correct and I mis-read it initially. It isn't a ASF Board
member, it is an ASF Officer, whom are listed here:
http://www.apache.org/foundation/. The bylaws do state that the PMC
Chairman SHALL be an Officer of the Corporation. But ASF Bylaw 6.1 does
include: "and such other officers and assistant officers and agents as may
be deemed necessary may be elected or appointed by the Board of Directors
from time to time", so perhaps all that is necessary is for the Board to
designate each PMC Chairman (e.g., Nicola) as an ASF Officer.
>From ASF Bylaws 6.4: "The officers of the corporation and the members of
each existing Project Management Committee shall be appointed by the Board
of Directors or appointed by an officer empowered by the Board to make such
appointment."
So what you are saying is that the PMC Chairman is legally the Corporate
Oficer who designates PMC members, but that as an internal process the
designated Officer abides by whatever rules are established by the
Community?
> Nicola Ken is an ASF member. As are Berin and Stefano.
Sorry. I was going by http://www.apache.org/foundation/members.html, which
shows only Stefano from that list. Apologies (and congratulations) to
Nicola and Berin.
> Independent of prior charters that may have been approved, I
> intend to review future charters with an eye for (1) effectively
> demonstrating oversight and (2) adherance to the "collaborative,
> consensus based development process" that is supposed to characterize
> all Apache projects.
Excellent! :-) Do you have a prototype that people can use to start?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Kick-starting the Charter process
Posted by Sam Ruby <ru...@apache.org>.
Noel J. Bergman wrote:
>
> That is from the ASF Bylaws, section 6.3. Is the ASF Board really going to
> put a board member on each PMC as Chairman? The current board is posted
> here: http://www.apache.org/foundation/board/. I'll point out that Nicola
> is neither a board member, nor an ASF member.
The board appoints officers. Officers are empowered to appoint members.
The appointment process is specified by the project's charter.
Chairmen are typically officers. While this appointment is done by the
board, I am not aware of any cases to date where the wishes of the PMC
were not respected.
Jakarta's original process, for example, allowed any PMC member to
nominate another member. This initiated a vote administered by the
chairman. Depending on the results, the PMC chair then notified the
board of the appointment. Recently, the ASF bylaws were changed to make
such appointments effective 48 hours after acknowledgement of receipt by
any board member.
Nicola Ken is an ASF member. As are Berin and Stefano.
- Sam Ruby
P.S. Independent of prior charters that may have been approved, I
intend to review future charters with an eye for (1) effectively
demonstrating oversight and (2) adherance to the "collaborative,
consensus based development process" that is supposed to characterize
all Apache projects.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Kick-starting the Charter process
Posted by Sam Ruby <ru...@apache.org>.
Noel J. Bergman wrote:
>
> That is from the ASF Bylaws, section 6.3. Is the ASF Board really going to
> put a board member on each PMC as Chairman? The current board is posted
> here: http://www.apache.org/foundation/board/. I'll point out that Nicola
> is neither a board member, nor an ASF member.
The board appoints officers. Officers are empowered to appoint members.
The appointment process is specified by the project's charter.
Chairmen are typically officers. While this appointment is done by the
board, I am not aware of any cases to date where the wishes of the PMC
were not respected.
Jakarta's original process, for example, allowed any PMC member to
nominate another member. This initiated a vote administered by the
chairman. Depending on the results, the PMC chair then notified the
board of the appointment. Recently, the ASF bylaws were changed to make
such appointments effective 48 hours after acknowledgement of receipt by
any board member.
Nicola Ken is an ASF member. As are Berin and Stefano.
- Sam Ruby
P.S. Independent of prior charters that may have been approved, I
intend to review future charters with an eye for (1) effectively
demonstrating oversight and (2) adherance to the "collaborative,
consensus based development process" that is supposed to characterize
all Apache projects.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Kick-starting the Charter process
Posted by Sam Ruby <ru...@apache.org>.
Noel J. Bergman wrote:
>
> That is from the ASF Bylaws, section 6.3. Is the ASF Board really going to
> put a board member on each PMC as Chairman? The current board is posted
> here: http://www.apache.org/foundation/board/. I'll point out that Nicola
> is neither a board member, nor an ASF member.
The board appoints officers. Officers are empowered to appoint members.
The appointment process is specified by the project's charter.
Chairmen are typically officers. While this appointment is done by the
board, I am not aware of any cases to date where the wishes of the PMC
were not respected.
Jakarta's original process, for example, allowed any PMC member to
nominate another member. This initiated a vote administered by the
chairman. Depending on the results, the PMC chair then notified the
board of the appointment. Recently, the ASF bylaws were changed to make
such appointments effective 48 hours after acknowledgement of receipt by
any board member.
Nicola Ken is an ASF member. As are Berin and Stefano.
- Sam Ruby
P.S. Independent of prior charters that may have been approved, I
intend to review future charters with an eye for (1) effectively
demonstrating oversight and (2) adherance to the "collaborative,
consensus based development process" that is supposed to characterize
all Apache projects.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Kick-starting the Charter process
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Noel J. Bergman [mailto:noel@devtech.com]
>
> [Preface: just a few nits, and a couple of questions regarding the ASF
> Bylaws vs the PMC charter]
:) Its welcome just the same.
>
> > " It is also possible for a project depending on Avalon to nominate
> > a representative. The representative of the client project still
> > needs to be unanimously approved by all PMC members, and a
> two-thirds
> > majority vote of committers. "
>
> I think that you can (and should) remove the word "still". And change
> "representative of the client project" to "the client project's
> representative." Nit-picking, I know.
+1
> Also, please review section 6.4 of the Apache Bylaws. It
> states that the
> members of the PMC are appointed by the ASF Board (or a
> designated member).
> IANAL, so I'm not sure how to interpret that clause vis-a-vis the PMC
> charter.
It is largely cut and paste from XML's charter, so I am not sure
either. I'll be honest, the Apache Bylaws are pretty long and my
eyes glazed over as I read it.
> > ... direction of the newly-formed Apache Software Foundation ...
>
> Is the "newly-formed" adjective still appropriate?
Probably not.
> > The PMC must have at least one officer from the Apache Board,
> > who will be the Chairperson and report to the Apache Board.
>
> That is from the ASF Bylaws, section 6.3. Is the ASF Board
> really going to
> put a board member on each PMC as Chairman? The current
> board is posted
> here: http://www.apache.org/foundation/board/. I'll point
> out that Nicola
> is neither a board member, nor an ASF member.
Yep. Again, its a copy and paste thing. I am an ASF member, but
not a board member. I dunno. Maybe practicalities are different,
but I am open to how it *should* be written.
> Again, I'm just trying to understand this with respect to the
> ASF Bylaws,
> since I expect to be going through this again shortly with
> James. Perhaps
> Sam Ruby or Greg Stein can help clear up my confusion, since they are
> presently reading this list.
It would be a good thing.
> > (I would [commit] it, but I am behind a corporate firewall).
>
> Is SSH unable to penetrate your corporate firewall?
I have two machines--one is on a private network (no internet),
and the other I don't have my private key installed on. Either
way, I am not trying to make waves as I just got this job. ;P
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Kick-starting the Charter process
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Noel J. Bergman [mailto:noel@devtech.com]
>
> [Preface: just a few nits, and a couple of questions regarding the ASF
> Bylaws vs the PMC charter]
:) Its welcome just the same.
>
> > " It is also possible for a project depending on Avalon to nominate
> > a representative. The representative of the client project still
> > needs to be unanimously approved by all PMC members, and a
> two-thirds
> > majority vote of committers. "
>
> I think that you can (and should) remove the word "still". And change
> "representative of the client project" to "the client project's
> representative." Nit-picking, I know.
+1
> Also, please review section 6.4 of the Apache Bylaws. It
> states that the
> members of the PMC are appointed by the ASF Board (or a
> designated member).
> IANAL, so I'm not sure how to interpret that clause vis-a-vis the PMC
> charter.
It is largely cut and paste from XML's charter, so I am not sure
either. I'll be honest, the Apache Bylaws are pretty long and my
eyes glazed over as I read it.
> > ... direction of the newly-formed Apache Software Foundation ...
>
> Is the "newly-formed" adjective still appropriate?
Probably not.
> > The PMC must have at least one officer from the Apache Board,
> > who will be the Chairperson and report to the Apache Board.
>
> That is from the ASF Bylaws, section 6.3. Is the ASF Board
> really going to
> put a board member on each PMC as Chairman? The current
> board is posted
> here: http://www.apache.org/foundation/board/. I'll point
> out that Nicola
> is neither a board member, nor an ASF member.
Yep. Again, its a copy and paste thing. I am an ASF member, but
not a board member. I dunno. Maybe practicalities are different,
but I am open to how it *should* be written.
> Again, I'm just trying to understand this with respect to the
> ASF Bylaws,
> since I expect to be going through this again shortly with
> James. Perhaps
> Sam Ruby or Greg Stein can help clear up my confusion, since they are
> presently reading this list.
It would be a good thing.
> > (I would [commit] it, but I am behind a corporate firewall).
>
> Is SSH unable to penetrate your corporate firewall?
I have two machines--one is on a private network (no internet),
and the other I don't have my private key installed on. Either
way, I am not trying to make waves as I just got this job. ;P
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Kick-starting the Charter process
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Noel J. Bergman [mailto:noel@devtech.com]
>
> [Preface: just a few nits, and a couple of questions regarding the ASF
> Bylaws vs the PMC charter]
:) Its welcome just the same.
>
> > " It is also possible for a project depending on Avalon to nominate
> > a representative. The representative of the client project still
> > needs to be unanimously approved by all PMC members, and a
> two-thirds
> > majority vote of committers. "
>
> I think that you can (and should) remove the word "still". And change
> "representative of the client project" to "the client project's
> representative." Nit-picking, I know.
+1
> Also, please review section 6.4 of the Apache Bylaws. It
> states that the
> members of the PMC are appointed by the ASF Board (or a
> designated member).
> IANAL, so I'm not sure how to interpret that clause vis-a-vis the PMC
> charter.
It is largely cut and paste from XML's charter, so I am not sure
either. I'll be honest, the Apache Bylaws are pretty long and my
eyes glazed over as I read it.
> > ... direction of the newly-formed Apache Software Foundation ...
>
> Is the "newly-formed" adjective still appropriate?
Probably not.
> > The PMC must have at least one officer from the Apache Board,
> > who will be the Chairperson and report to the Apache Board.
>
> That is from the ASF Bylaws, section 6.3. Is the ASF Board
> really going to
> put a board member on each PMC as Chairman? The current
> board is posted
> here: http://www.apache.org/foundation/board/. I'll point
> out that Nicola
> is neither a board member, nor an ASF member.
Yep. Again, its a copy and paste thing. I am an ASF member, but
not a board member. I dunno. Maybe practicalities are different,
but I am open to how it *should* be written.
> Again, I'm just trying to understand this with respect to the
> ASF Bylaws,
> since I expect to be going through this again shortly with
> James. Perhaps
> Sam Ruby or Greg Stein can help clear up my confusion, since they are
> presently reading this list.
It would be a good thing.
> > (I would [commit] it, but I am behind a corporate firewall).
>
> Is SSH unable to penetrate your corporate firewall?
I have two machines--one is on a private network (no internet),
and the other I don't have my private key installed on. Either
way, I am not trying to make waves as I just got this job. ;P
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Kick-starting the Charter process
Posted by "Noel J. Bergman" <no...@devtech.com>.
[Preface: just a few nits, and a couple of questions regarding the ASF
Bylaws vs the PMC charter]
> " It is also possible for a project depending on Avalon to nominate
> a representative. The representative of the client project still
> needs to be unanimously approved by all PMC members, and a two-thirds
> majority vote of committers. "
I think that you can (and should) remove the word "still". And change
"representative of the client project" to "the client project's
representative." Nit-picking, I know.
Also, please review section 6.4 of the Apache Bylaws. It states that the
members of the PMC are appointed by the ASF Board (or a designated member).
IANAL, so I'm not sure how to interpret that clause vis-a-vis the PMC
charter.
> ... direction of the newly-formed Apache Software Foundation ...
Is the "newly-formed" adjective still appropriate?
> The PMC must have at least one officer from the Apache Board,
> who will be the Chairperson and report to the Apache Board.
That is from the ASF Bylaws, section 6.3. Is the ASF Board really going to
put a board member on each PMC as Chairman? The current board is posted
here: http://www.apache.org/foundation/board/. I'll point out that Nicola
is neither a board member, nor an ASF member.
Again, I'm just trying to understand this with respect to the ASF Bylaws,
since I expect to be going through this again shortly with James. Perhaps
Sam Ruby or Greg Stein can help clear up my confusion, since they are
presently reading this list.
> (I would [commit] it, but I am behind a corporate firewall).
Is SSH unable to penetrate your corporate firewall?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Kick-starting the Charter process
Posted by "Noel J. Bergman" <no...@devtech.com>.
[Preface: just a few nits, and a couple of questions regarding the ASF
Bylaws vs the PMC charter]
> " It is also possible for a project depending on Avalon to nominate
> a representative. The representative of the client project still
> needs to be unanimously approved by all PMC members, and a two-thirds
> majority vote of committers. "
I think that you can (and should) remove the word "still". And change
"representative of the client project" to "the client project's
representative." Nit-picking, I know.
Also, please review section 6.4 of the Apache Bylaws. It states that the
members of the PMC are appointed by the ASF Board (or a designated member).
IANAL, so I'm not sure how to interpret that clause vis-a-vis the PMC
charter.
> ... direction of the newly-formed Apache Software Foundation ...
Is the "newly-formed" adjective still appropriate?
> The PMC must have at least one officer from the Apache Board,
> who will be the Chairperson and report to the Apache Board.
That is from the ASF Bylaws, section 6.3. Is the ASF Board really going to
put a board member on each PMC as Chairman? The current board is posted
here: http://www.apache.org/foundation/board/. I'll point out that Nicola
is neither a board member, nor an ASF member.
Again, I'm just trying to understand this with respect to the ASF Bylaws,
since I expect to be going through this again shortly with James. Perhaps
Sam Ruby or Greg Stein can help clear up my confusion, since they are
presently reading this list.
> (I would [commit] it, but I am behind a corporate firewall).
Is SSH unable to penetrate your corporate firewall?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Kick-starting the Charter process
Posted by "Noel J. Bergman" <no...@devtech.com>.
[Preface: just a few nits, and a couple of questions regarding the ASF
Bylaws vs the PMC charter]
> " It is also possible for a project depending on Avalon to nominate
> a representative. The representative of the client project still
> needs to be unanimously approved by all PMC members, and a two-thirds
> majority vote of committers. "
I think that you can (and should) remove the word "still". And change
"representative of the client project" to "the client project's
representative." Nit-picking, I know.
Also, please review section 6.4 of the Apache Bylaws. It states that the
members of the PMC are appointed by the ASF Board (or a designated member).
IANAL, so I'm not sure how to interpret that clause vis-a-vis the PMC
charter.
> ... direction of the newly-formed Apache Software Foundation ...
Is the "newly-formed" adjective still appropriate?
> The PMC must have at least one officer from the Apache Board,
> who will be the Chairperson and report to the Apache Board.
That is from the ASF Bylaws, section 6.3. Is the ASF Board really going to
put a board member on each PMC as Chairman? The current board is posted
here: http://www.apache.org/foundation/board/. I'll point out that Nicola
is neither a board member, nor an ASF member.
Again, I'm just trying to understand this with respect to the ASF Bylaws,
since I expect to be going through this again shortly with James. Perhaps
Sam Ruby or Greg Stein can help clear up my confusion, since they are
presently reading this list.
> (I would [commit] it, but I am behind a corporate firewall).
Is SSH unable to penetrate your corporate firewall?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>