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.