geronimo-scm mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Geronimo Wiki] Update of "ProjectGuidelines" by coar
Date Tue, 20 Jun 2006 12:03:50 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Geronimo Wiki" for change notification.

The following page has been changed by coar:
http://wiki.apache.org/geronimo/ProjectGuidelines

New page:
= Apache Geronimo Bylaws =
== Charter ==
This is the ASF Board resolution that created the Apache Geronimo project on 26 May 2004:
{{{
         WHEREAS, the Board of Directors deems it to be in the best
         interests of the Foundation and consistent with the
         Foundation's purpose to establish a Project Management
         Committee charged with the creation and maintenance of
         a certified implementation of the J2EE specification
         and related software and materials for distribution
         at no charge to the public.

         NOW, THEREFORE, BE IT RESOLVED, that a Project Management
         Committee (PMC), to be known as the "Apache Geronimo PMC", be
         and hereby is established pursuant to the Bylaws of the
         Foundation; and be it further

         RESOLVED, that the Apache Geronimo PMC be and hereby is
         responsible for the creation and maintenance of an open-source
         implementation of the J2EE specification as well as related
         software and other materials determined appropriate by
         the Apache Geronimo PMC licensed to the Foundation; and be
         it further

         RESOLVED, that the Apache Geronimo PMC is responsible for
         outreach and cooperation with other open-source projects whose
         purpose is deemed compatible with the work of the Apache
         Geronimo PMC; and be it further

         RESOLVED, that the office of "Vice President, Apache Geronimo"
         be and hereby is created, the person holding such office to
         serve at the direction of the Board of Directors as the chair
         of the Apache Geronimo PMC, and to have primary responsibility
         for management of the projects within the scope and
         responsibility of the Apache Geronimo PMC; and be it further

         RESOLVED, that the persons listed immediately below be and
         hereby are appointed to serve as the initial members of the
         Apache Geronimo PMC and also constitute the list of initial
         committers :

           Jan Bartel
           David Blevins
           Jeremy Boynes
           Alan Cabrera
           Hiram Chirino
           Gianny Damour
           Ceki Gülcü
           Jules Gosnell
           Jim Jagielski
           David Jencks
           Jacek Laskowski
           Geir Magnusson Jr.
           Richard Monson-Haefel
           Aaron Mulder
           Bruce Snyder
           Davanum Srinivas
           James Strachan
           Dain Sundstrom
           Greg Wilkins

         NOW, THEREFORE, BE IT FURTHER RESOLVED, that Geir Magnusson be
         and hereby is appointed to the office of Vice President, Apache
         Geronimo, to serve in accordance with and subject to the
         direction of the Board of Directors and the Bylaws of the
         Foundation until death, resignation, retirement, removal or
         disqualification, or until a successor is appointed; and be it
         further

         RESOLVED, that the initial Apache Geronimo PMC be and hereby
         is tasked with the creation of a set of bylaws intended to
         encourage open development and increased participation in the
         Apache Geronimo Project.
}}}
By Unaninmous vote, the Apache Geronimo PMC was approved.

== Project Structure ==

participants, contributors, committers, pmc

== PMC Composition ==

all committers..?

== PMC Responsibilities ==

approve releases
vote on new committers
oversee the project, subject to the chair

Folks,

Am trying to come up with bullet items (which can be expanded later)
on what the board expects from a PMC and its members. Does anyone know
if there is a document that already has this kind of list? Can folks
please help refine/expand this list.

(May be each line item should start with "Thou Shalt"  :) 

#1: Timely and accurate reports based on the rotation schedule in the
foundation svn module
#2: Create and maintain a charter that governs the PMC/project(s)
#3: Take decisions affecting progress and health of the projects(s),
ensure smooth functioning and create a conducive work atmosphere for
everyone in the community.
#4: Focus efforts more on community building rather than on code.
#5: Ensure all community members (not just PMC members) participate in
decision-making processes (ex: limit IRC usage, ban private lists for
dev related decisions)
#6: Work with Infrastructure to meet day-to-day requirements of
community members.
#7: Interact with other PMC's/Projects to learn best practices, reuse
code, increase synergy, avoid duplication of effort.
#8: Work with the board for refining policies and practices to better
serve the needs of the community.
#9: Work hard to add new individuals to the community, provide
mentoring and enable them to join the PMC.
10: Keep strict watch on legal issues w.r.t copyrights, patents and
licenses. Work proactively with our legal resources to avoid problems
to folks who use our projects.


== Committer Election ==

consistent quality submissions

== Committer Responsibilities ==

Commit access is a privilege and an expression of trust
and respect.  It includes the authority to make changes
to the codebase.  In a balanced environment, authority
is accompanied by equivalent responsibility; in the case
of Apache, the responsibilities include both following
the open development model and encouraging others to do
likewise.  Given the attention that Apache projects
have attracted from commercial organisations, these are
more serious than ever before.  The openness that is
so central to the way Apache development works is
precious and we must all be vigilant in protecting it.
Being made a committer means being entrusted as a guardian
of that openness.

Key things to watch out for include lack of peer respect
and exclusionary practices.  Ignoring vetoes is an example
of the former which has cropped up before at Apache; it
can be as blatant as either leaving changes in though
they've been vetoed, or re-applying them after they've been
backed out.  It can also be subtle, such as letting a
veto stand and the discussion die down, and then later
quietly re-applying the vetoed change when no-one notices.

There are some troubling signs that the openness of development
on the Apache Geronimo project may be less than it should
be, and I want to make sure that all committers are aware
that such is *not* 'business as usual' but a problem to be
addressed.

'Working around' the open development model or 'gaming the
system' are damaging to the model and to the project.  If
you encounter something that seems to be getting done in
a less than open manner, please remember you're a guardian
of the openness and talk to people to try to correct it.

Inadvertent exclusions happen, such as (for example) fictitious
Dion and Josef talking over lunch and then going back and
committing a significant change without getting input from
the community.  Stuff happens, and it's generally no big deal.
It's when it becomes a trend that it becomes a big deal.

Deliberately violating the trust represented by commit
access is something that won't be tolerated; substantiated
instances will result in the loss of the commit privilege.

Thank you very much for your dedication to and support of
the Geronimo project and the Apache development model.  Your
efforts and contributions are the largest part of what makes
it special -- and makes it work.

== Participant/Contributor Responsibilities ==

== Releases and Release Management ==

only pmc votes are binding (why?)
cannot be vetoed
release manager has absolute power
rm must be on pmc

== Code of Conduct ==

It's not necessarily as clear-cut as that.  Any change
that's going into something provided as part of an
Apache release needs to go through the approval model.
Hack away in the sandboxes freely, but rolling anything
from a sandbox into a intend-to-ship line needs to go
through the model -- RTC, in this case.

Merging in changes from another branch can be a bit grey,
as well.  Why weren't they in the target branch?  Did they
have anything to do with why the source branch was
abandoned (in this case)?  (Those are rhetorical questions.)

It's a judgement call on the part of the committers.
Since RTC is intended to emphasise quality over development
speed and convenience, the question that needs to be
asked and answered is along the lines of, 'Is this a
functional change, and is there *any* danger of it
introducing bugs that would be caught by reviewing it
first?'

Committers have to be honest with themselves and the
project, and answer the question objectively rather
than taking an easy way out.  'Fifty-plus files is
'way too much to review, so let's just assume that
since it was in the other branch it's okey to bring
in here without checking' is a *wrong* answer.
'There are fifty-plus files involved, but the changes
were all exercised and tested in the source branch, and
they're being merged into code in the destination branch
that is the same as in the source branch, so I feel
confident merging it won't tickle any bugs from the
integration, and I don't think we need to review' is a
valid answer allowing unreviewed merging.

Cases like this are up to the committers to decide.
Based on that definition, if no-one honestly thinks the
merge could introduce bugs, then commit away.  Remember,
though, that even in CTR someone can discover an
unanticipated problem and issue a veto..


1. Releases can't be vetoed; they use a consensual vote,
    not the '3 +1s and 0 -1s' mechanism.
2. Since a release bears the Apache name, releasing software
    is an official act of the Foundation, and as a consequence
    only members of the PMC have binding votes.  All others
    are advisory.


The message is: Apache Geronimo is a
collaborative effort.  Committers are peers.  Cliques
are inappropriate, as are significant changes made
unilaterally and without community input.

Mime
View raw message