You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@portals.apache.org by ra...@apache.org on 2004/10/24 16:50:54 UTC
svn commit: rev 55438 - portals/site/xdocs
Author: raphael
Date: Sun Oct 24 07:50:53 2004
New Revision: 55438
Added:
portals/site/xdocs/communication.xml
portals/site/xdocs/decisions.xml
portals/site/xdocs/guidelines.xml
portals/site/xdocs/management.xml
portals/site/xdocs/newproject.xml
portals/site/xdocs/roles.xml
portals/site/xdocs/whoweare.xml
Log:
Create Project Guidelines based on Jakarta's, updated with the Portals Project emeritus policy
Added: portals/site/xdocs/communication.xml
==============================================================================
--- (empty file)
+++ portals/site/xdocs/communication.xml Sun Oct 24 07:50:53 2004
@@ -0,0 +1,82 @@
+<?xml version="1.0"?>
+<!--
+Copyright 1999-2004 The Apache Software Foundation
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+<document>
+
+ <properties>
+ <author email="general.AT.portals.DOT.apache.DOT.org">Apache Portals Project</author>
+ <title>Communication</title>
+ </properties>
+
+<body>
+
+ <section name="Communication">
+ <p>
+ The Project obtains its strength from the communication of its
+ members. In order for members to easily communicate with each other,
+ the Project has a variety of mailing lists. These lists, with the
+ exception of the announcement lists, are not moderated and anybody
+ is more than welcome to join them. However, you must be subscribed
+ to post to a list.
+ </p>
+
+ <p>
+ To reduce the bandwidth demands on everyone, mail should not contain
+ attachments. It is recommended that you place interesting material
+ (such as patches) either within the body of the message or
+ provide a URL for retrieval.
+ </p>
+
+ <p>
+ To join the mailing lists, see our <a href="./mail-lists.html">
+ Mailing List</a> page.
+ </p>
+
+ <p>
+ The Project's list fall into the following categories:
+ </p>
+ </section>
+ <section name="Announcement Lists">
+ <p>
+ Announcement lists are very low traffic designed to communicate
+ important information, such as final releases of a subproject's
+ code, to a wide audience.
+ </p>
+ </section>
+ <section name="User Lists">
+ <p>
+ User lists are for users of a product to converse about such things
+ as configuration and operating of the products of the Project.
+ </p>
+ </section>
+ <section name="Developer Lists">
+ <p>
+ Developer lists are for the developers of the project. On these
+ lists suggestions and comments for code changes are discussed and
+ action items are raised and voted on. For the developer community,
+ these lists are the very center of the project where all the
+ "action" is.
+ </p>
+ </section>
+ <section name="Commit Lists">
+ <p>
+ The commit lists are where all cvs code commit messages are
+ sent. All committers are required to subscribe to this list so that
+ they can stay aware of changes to the repository.
+ </p>
+ </section>
+
+</body>
+</document>
\ No newline at end of file
Added: portals/site/xdocs/decisions.xml
==============================================================================
--- (empty file)
+++ portals/site/xdocs/decisions.xml Sun Oct 24 07:50:53 2004
@@ -0,0 +1,174 @@
+<?xml version="1.0"?>
+<!--
+Copyright 1999-2004 The Apache Software Foundation
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+<document>
+
+ <properties>
+ <author email="general.AT.portals.DOT.apache.DOT.org">Apache Portals Project</author>
+ <title>The Portals Project</title>
+ </properties>
+
+<body>
+
+ <section name="Decision Making">
+ <p>
+ All <a href="./roles.html">Contributors</a> are encouraged
+ to participate in decisions, but the decision itself is made by
+ those that have <a href="./roles.html">Committer</a>
+ status in the Project. In other words, the Project is a
+ "<em>Minimum Threshold Meritocracy</em>".
+ </p>
+
+ <p>
+ Any subscriber to the list may vote on any issue or
+ action item. However, the only binding votes are those cast by a
+ Committer. If the vote is about a change to the source code or
+ documentation and the primary uthor is a Contributor and not a
+ Committer, the primary author of whatis being changed may also
+ cast a binding vote on that issue.
+ </p>
+
+ <p>
+ The act of voting carries certain obligations. Voting members are
+ not only stating their opinion, they are also agreeing to help do
+ the work.
+ </p>
+
+ <p>Each vote can be made in one of three flavors:</p>
+
+ <table>
+ <tr>
+ <td><strong>+1</strong></td>
+ <td>
+ "Yes," "Agree," or "the action should be
+ performed." On some issues this is only binding if the voter
+ has tested the action on their own system(s).
+ </td>
+ </tr>
+
+ <tr>
+ <td><strong>+/-0</strong></td>
+ <td>
+ "Abstain," "no opinion". An abstention may
+ have detrimental effects if too many people abstain.
+ </td>
+ </tr>
+
+ <tr>
+ <td><strong>-1</strong></td>
+ <td>
+ "No." On issues where consensus is required, this vote
+ counts as a <strong>veto</strong>. All vetos must contain an
+ explanation of why the veto is appropriate. Vetos with no
+ explanation are void. No veto can be overruled. If you disagree
+ with the veto, you should lobby the person who cast the veto.
+ Voters intending to veto an action item should make their opinions
+ known to the group immediately so that the problem can be remedied
+ as early as possible.
+ </td>
+ </tr>
+
+ </table>
+
+ <p>
+ An action requiring consensus approval must receive at least
+ <strong>3 binding +1</strong> votes and <strong>no binding
+ vetos</strong>. An action requiring majority approval must receive
+ at least <strong>3 binding +1</strong> votes and more
+ <strong>+1</strong> votes than <strong>-1</strong> votes. All other
+ action items are considered to have lazy approval until somebody
+ votes <strong>-1</strong>, after which point they are decided by
+ either consensus or majority vote, depending on the type of action
+ item.
+ </p>
+
+ <h2>Action Items</h2>
+
+ <p>
+ All decisions revolve around "<em>Action
+ Items.</em>" Action Items consist of the following:
+ </p>
+
+ <ul>
+ <li>Long Term Plans</li>
+ <li>Short Term Plans</li>
+ <li>Release Plan</li>
+ <li>Release Testing</li>
+ <li>Showstoppers</li>
+ <li>Product Changes</li>
+ </ul>
+
+ <h3>Long Term Plans</h3>
+
+ <p>
+ Long term plans are simply announcements that group members are
+ working on particular issues related to the Project. These are not
+ voted on, but Committers who do not agree with a particular plan, or
+ think that an alternative plan would be better, are obligated to
+ inform the group of their feelings.
+ </p>
+
+ <h3>Short Term Plan</h3>
+
+ <p>
+ Short term plans are announcements that a volunteer is working on a
+ particular set of documentation or code files with the implication
+ that other volunteers should avoid them or try to coordinate their
+ changes.
+ </p>
+
+ <h3>Release Plan</h3>
+
+ <p>
+ A release plan is used to keep all volunteers aware of when a
+ release is desired, who will be the release manager, when the
+ repository will be frozen to create a release, and other assorted
+ information to keep volunteers from tripping over each other. Lazy
+ majority decides each issue in a release plan.
+ </p>
+
+ <h3>Release Testing</h3>
+
+ <p>
+ After a new release is built, it must be tested before being
+ released to the public. Majority approval is required before the
+ release can be made. Once a release is approved by the Committers,
+ the Project Management Committee can authorize its distribution on
+ behalf of the Foundation.
+ </p>
+
+ <h3>Showstoppers</h3>
+
+ <p>
+ Showstoppers are issues that require a fix be in place before the
+ next public release. They are listed in the status file in order to
+ focus special attention on these problems. An issue becomes a
+ showstopper when it is listed as such in the status file and remains
+ so by lazy consensus.
+ </p>
+
+ <h3>Product Changes</h3>
+
+ <p>
+ Changes to the products of the Project, including code and
+ documentation, will appear as action items in the status file. All
+ product changes to the currently active repository are subject to
+ lazy consensus.
+ </p>
+
+ </section>
+
+</body>
+</document>
\ No newline at end of file
Added: portals/site/xdocs/guidelines.xml
==============================================================================
--- (empty file)
+++ portals/site/xdocs/guidelines.xml Sun Oct 24 07:50:53 2004
@@ -0,0 +1,76 @@
+<?xml version="1.0"?>
+<!--
+Copyright 1999-2004 The Apache Software Foundation
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+<document>
+
+ <properties>
+ <author email="general.AT.portals.DOT.apache.DOT.org">Apache Portals Project</author>
+ <title>Project Guidelines</title>
+ </properties>
+
+<body>
+
+ <section name="Project Guidelines">
+ <p>
+ This document defines the guidelines of the Portals Project. It
+ includes definitions of the various categories of membership, who is
+ able to vote, how conflicts are resolved by voting, and the procedures
+ to follow for proposing and making changes to the codebase of the
+ Project.
+ </p>
+
+ <ul>
+ <li>
+ <a href="./roles.html">Roles and Responsibilities</a>
+ <br />
+ Defines the recognized roles in the project.
+ </li>
+
+ <li>
+ <a href="./communication.html">Communication</a>
+ <br />
+ Defines how users and developers communicate.
+ </li>
+
+ <li>
+ <a href="./decisions.html">Decision Making</a>
+ <br />
+ Defines how action items are proposed and voted on.
+ </li>
+
+ <li>
+ <a href="./management.html">Project Management</a>
+ <br />
+ Defines the roles and responsibilities of the
+ Project Management Committee (PMC).
+ </li>
+
+ <li>
+ <a href="./newproject.html">New Subproject Proposals</a>
+ <br />
+ Defines the methodology for proposing new top level
+ Jakarta Subprojects.
+ </li>
+ </ul>
+
+ <p>
+ This is a living document. Changes can be made by the Project
+ Management Committee. Suggestions for changes should be discussed
+ on the general@portals <a href="./mail-lists.html#general">mailing list</a>
+ </p>
+
+ </section>
+</body>
+</document>
\ No newline at end of file
Added: portals/site/xdocs/management.xml
==============================================================================
--- (empty file)
+++ portals/site/xdocs/management.xml Sun Oct 24 07:50:53 2004
@@ -0,0 +1,92 @@
+<?xml version="1.0"?>
+<!--
+Copyright 1999-2004 The Apache Software Foundation
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+<document prefix="../site/" url="./management.xml">
+
+ <properties>
+ <author email="general.AT.portals.DOT.apache.DOT.org">Apache Portals Project</author>
+ <title>Project Management Committee Bylaws</title>
+ </properties>
+
+<body>
+
+ <section name="Project Management Committee Bylaws">
+<p>
+The Project Management Committee (PMC) was formed by the ASF Board
+in October 2003, and is responsible to the ASF Board for oversight of the project.
+The list of current members can be found in our
+<a href="./whoweare.html"> Project Credits</a>.
+</p>
+
+<p>
+<b>Roles</b><br/> The PMC is responsible for the strategic direction
+and success of the Portals Project. This governing body is expected to
+ensure the project's welfare and guide its overall direction. The PMC
+may not necessarily participate in the day-to-day coding but is
+involved in the overall development plans, the alleviation of any
+bottlenecks, the resolution of conflicts, and the overall technical
+success of the project.
+</p>
+
+<p>
+The PMC is answerable to the ASF Board with its Chairman serving as
+primary liaison.
+</p>
+
+<p>
+<b>Board reports</b><br/>
+Quarterly, the PMC is responsible for sending a report to the ASF Board.
+</p>
+
+<p>
+<b>Membership</b><br/> PMC members may resign at any time. The Chairman
+may resign as Chairman at any time without resigning membership to the
+PMC. The Chairman or any member may be removed from the PMC by a 3/4
+vote of the PMC.
+</p>
+
+<p>
+Committers are nominated for the PMC by an existing PMC member and a vote then follows.
+</p>
+
+<p><b>Voting</b><br />
+Binary PMC voting is a majority-approval variant, with a minimum of 3 +1s
+required and at least 3/4 of the votes being +1. This voting style is used
+for anything with a yes/no, two-option choice; such as PMC member voting
+or changes to this document.
+</p>
+
+<p>
+Non-binary voting currently relies on community agreement; such as voting
+on the recommendation of a chairman to the board.
+</p>
+
+<p>A week is deemed a fair length for a vote. </p>
+
+<p>Subprojects of Portals use other voting variants, described on the
+<a href="decisions.html">Decisions</a> page. </p>
+
+<p>
+<b>Creation of subprojects</b><br/>
+The Apache Incubator is the primary source of new subprojects for Portals,
+though the PMC may choose to waive this if the Incubator PMC is agreeable.
+A common example of this is when an existing subproject contains a component
+which wishes to become a full subproject. In such cases, there is unlikely
+to be a need for incubation.
+</p>
+ </section>
+
+</body>
+</document>
Added: portals/site/xdocs/newproject.xml
==============================================================================
--- (empty file)
+++ portals/site/xdocs/newproject.xml Sun Oct 24 07:50:53 2004
@@ -0,0 +1,273 @@
+<?xml version="1.0"?>
+<!--
+Copyright 1999-2004 The Apache Software Foundation
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+<document>
+
+ <properties>
+ <author email="general.AT.portals.DOT.apache.DOT.org">Apache Portals Project</author>
+ <title>New Project Proposals</title>
+ </properties>
+
+<body>
+
+<section name="Subproject Proposals">
+
+<p>
+Not every software product is suited for life at Portals. Before proposing
+a new subproject, it is important to read this document carefully and determine
+whether your product is a good fit.
+</p>
+
+</section>
+
+<section name="Before Reading...">
+
+<p>
+<a href="http://www.apache.org/">The Apache Software Foundation</a> has established a
+project for the acceptance of new codebases and for the incubation, named
+<a href="http://incubator.apache.org/">Apache Incubator Project</a> on October, 2002.
+</p>
+<p>
+If you, who are thinking of donating code and starting a project, have some contributions
+to make for an existing <a href="http://portals.apache.org/">Portals</a> sub-project,
+work with that community via the <a href="./mail-lists.html">mailing lists</a>.
+</p>
+
+</section>
+
+<section name="Criteria">
+
+<p>
+Here are some best practices that we will expect to find in a successful
+proposal. This is not a checklist, but guidelines to help communicate what
+is expected of a Portals subproject.
+</p>
+
+<p>
+<strong>Meritocracy.</strong> Before submitting a proposal, be sure to study
+the guidelines that <a href="guidelines.html">govern Portals subprojects</a>.
+These guidelines explain our system of Meritocracy, which is the core
+of the Portals Project. If the product developers do not wish to adopt
+this system, then they should <strong>not</strong> donate their code
+to the Project, and should look elsewhere for hosting.
+</p>
+
+<p>
+<strong>Community.</strong> Portals is a Project of the
+<a href="http://www.apache.org/">Apache Software Foundation</a>. A prime purpose of
+the ASF is to ensure that the Apache projects continue to exist beyond the
+participation of individual volunteers. Accordingly, a prime criteria required
+of any new subproject is that it already enjoys -- or has a high potential for
+attracting -- an active community of developers and users.
+</p>
+
+<p>
+Proposals for non-established products have been accepted, most often when
+the proposal was tendered by experienced open source developers, who understand
+what it means to build a community.
+</p>
+
+<p>
+A design document, developer and user documentation, example code, and a
+working implementation all help to increase the likelihood of acceptance.
+Well-documented products tend to build stronger communities than
+products that rely source code and JavaDocs alone.
+</p>
+
+<p>
+<strong>Core Developers.</strong> To considered, a product must have
+at least 3 active developers who are already involved with the codebase.
+This is an absolute minimum, and it is helpful for there to more than
+three developers. It is <strong>very</strong> helpful for at least one of the
+developers making the proposal to already be active in a Portals subproject or
+other open source initiative.
+</p>
+
+<p>
+At Portals, the core developers of a product (the
+<a href="roles.html">Committers</a>) manage the codebases and make the
+day-to-day development decisions. We are only interested in products
+that can guided by their own development communities. Portals provides
+the infrastructure, and some essential guidelines, but the Committers
+must take responsibility for developing and releasing their own product.
+</p>
+
+<p>
+<strong>Alignment with existing Apache subprojects.</strong> Products that
+are already used by existing subprojects make attractive candidates, since
+bringing such a codebase into the Apache fold tends to benefit both
+communities. Products with dependancies on existing Apache products are also
+attractive for the same reason.
+</p>
+
+<p>
+<strong>Scope.</strong> Portals products are generally related to the
+development of portlets, portals and portal-related frameworks, independant
+of the implementation language. Most of the current efforts evolve around
+the JSR-168 Java Portlet Specification and the OASIS WSRP4J standard. Proposals
+for products outside this venue will have greater difficulty in being accepted.
+</p>
+
+</section>
+
+<section name="Warning Signs">
+
+<p>
+These are anti-patterns that we have found detrimental to the success of
+a proposal. Some of these are lesson learned from the school of
+hard-knocks, others are taken from proposals which have been rejected in
+the past. All will raise a red flag, making it unlikely that a proposal
+will be accepted.
+</p>
+
+<p>
+<strong>Orphaned products.</strong> Products which have lost their
+corporate sponsor (for whatever reason) do <strong>not</strong> make good candidates.
+These products will lack a development community and won't
+have the support needed to succeed under the Portals umbrella.
+</p>
+
+<p>
+For example, we have seen proposals that contain paragraphs like this:
+</p>
+
+<source>
+FooProduct is currently a production quality product, and in
+fact is being used a live website. It was developed as a
+product by FooCompany, with the intention that we would sell
+it. However, due to various economic factors such as the
+decline in FooProduct's intended market and the
+recent difficulties in obtaining venture capital, we have
+decided that at this time it is not feasible for us to
+continue in that direction.
+</source>
+
+
+<p>
+The alleged quality of a product is not the prime criteria. To be
+accepted, we must believe that a product will attract volunteers to
+extend and maintain it over the long term. A product like this,
+arriving with no volunteer developers or open source community, does
+not further <a href="mission.html">Portals' mission</a>, and would
+not be accepted.
+</p>
+
+<p>
+We generally recommend that an orphaned product start with an
+independent host, and consider making a proposal after it has started
+to build a community.
+</p>
+
+<p>
+<strong>Inexperience with open source.</strong> We often receive
+proposals that start with "We will open our software if you
+choose to accept it." This is the wrong way to approach the proposal
+process. A closed source project does not have an open community, and
+so we have no way to tell if the developers can work in an open source
+environment. Products that have lived on their own and have started
+to develop their own community, have a much better chance of being
+accepted.
+</p>
+
+<p>
+If the product's developers have not worked with open source before,
+it is recommended that they spend some time contributing to an existing
+open source project before trying to manage one of their own. Since
+Portals subprojects are managed by their own Committers, it is
+important that a new product supported by people who understand
+how open source works.
+</p>
+
+<p>
+<strong>Homogenous developers.</strong> Apache communities attract
+developers with diverse backgrounds. Products with a tightly-knit
+team of developers may have difficulty shepherding new developers
+into the fold. It is vital that we believe the developers will
+discuss development issues openly with the community, and
+<strong>not</strong> make decisions behind closed doors. We are
+especially wary of products with developers who all share a
+common employer or geographic location.
+</p>
+
+<p>
+<strong>Reliance on salaried developers.</strong> Portals has strong ties
+to the business community. Many of our developers are encouraged by their
+employers to work open source projects as part of their regular job.
+We feel that this is a Good Thing, and corporations should be entitled to
+contribute to open source, same as anyone else. However, we are wary of
+products which rely strongly on developers who only work on open source
+products when they are paid to do so. A product at Portals must continue
+to exist beyond the participation of individual volunteers. We believe the
+best indicator of success is when developers volunteer their own time to
+work open source projects.
+</p>
+
+<p>
+<strong>No ties to other Apache products</strong>. Products
+<strong>without</strong> a tie to any existing Apache product, and that have
+strong dependencies on alternatives to Apache products, do not make good
+candidates. Many Apache products are related through common licenses,
+technologies, and through their volunteers. Products without licensing,
+technology, or volunteers in common will have trouble attracting a
+strong community.
+</p>
+
+<p>
+<strong>A fascination with the Apache brand.</strong> The
+<a href="http://www.apache.org/LICENSE">Apache Software License</a> is quite
+liberal and allows for the code to used in commercial products. This
+can induce people to donate a commercial codebase to the ASF, allow it
+developed as open source for a time, and then convert it back to
+commercial use. While this would legal under the Apache Software
+License, we are wary of proposals that seem to be more interested in
+exposure than community.
+</p>
+
+</section>
+
+<section name="Subproject Alternatives">
+
+<p>
+If your product is a server-side java product, be sure to also
+visit the <a href="http://jakarta.apache.org/">Apache Jakarta Project</a>
+to see if it would be a good fit there.
+
+If your product is XML related, be sure to also visit the
+<a href="http://xml.apache.org/">Apache XML Project</a> or
+<a href="http://cocoon.apache.org/">Apache Cocoon Project</a> to see if it
+would be a good fit there.
+
+If your product is Web Service related, be sure to also visit
+the <a href="http://ws.apache.org/">Apache WebService Project</a> to see
+if it would be a good fit there.
+</p>
+
+</section>
+
+<section name="Who Decides">
+
+<p>
+Final acceptance is based the rules defined in the <a
+href="management.html">Project Management Committee Bylaws</a> which
+state that "Creation of a new subproject requires approval by 3/4 vote
+of the PMC." The proposal for a new subproject must submitted to the
+<a href="mail-lists.html#general">Portals General mailing list</a>, where the PMC
+conducts business. All discussion regarding the proposal will occur
+the General list, including the final vote.
+</p>
+
+</section>
+</body>
+</document>
Added: portals/site/xdocs/roles.xml
==============================================================================
--- (empty file)
+++ portals/site/xdocs/roles.xml Sun Oct 24 07:50:53 2004
@@ -0,0 +1,266 @@
+<?xml version="1.0"?>
+<!--
+Copyright 1999-2004 The Apache Software Foundation
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+<document>
+
+ <properties>
+ <author email="general.AT.portals.DOT.apache.DOT.org">Apache Portals Project</author>
+ <title>Roles and Responsibilities</title>
+ </properties>
+
+<body>
+
+ <section name="Roles & Responsibilities">
+ <p>
+ The roles and responsibilities that people can assume in the project
+ are based on merit. Everybody can help no matter what their role.
+ Those who have been long term or valuable contributors to the project
+ obtain the right to vote and commit directly to the source repository.
+ </p>
+
+ <h2>Users</h2>
+
+ <p>
+ Users are the people who use the products of the Project. People in
+ this role aren't contributing code, but they are using the products,
+ reporting bugs, making feature requests, and such. This is by far
+ the most important category of people as, without users, there is no
+ reason for the Project.
+ </p>
+
+ <p>
+ When a user starts to contribute code or documentation patches, they
+ become a Contributor.
+ </p>
+
+ <h2>Contributors</h2>
+
+ <p>
+ Contributors are the people who write code or documentation patches or
+ contribute positively to the project in other ways. A volunteer's
+ contribution is always recognized. In source code, all volunteers
+ who contribute to a source file may add their name to the list of
+ authors for that file.
+ </p>
+
+ <h2>Committers</h2>
+
+ <p>
+ Contributors who give frequent and valuable contributions to a
+ subproject of the Project can have their status promoted to that of
+ a "<em>Committer</em>" for that subproject. A Committer
+ has write access to the source code repository and gains voting
+ rights allowing them to affect the future of the subproject.
+ </p>
+
+ <p>
+ In order for a Contributor to become a Committer, another Committer
+ can nominate that Contributor or the Contributor can ask for it.
+ </p>
+
+ <p>
+ Once a Contributor is nominated, all of the Committers for a subproject
+ will vote. If there are at least 3 positive votes and no negative
+ votes, the Contributor is converted into a Committer and given write
+ access to the source code repository for that subproject.
+ </p>
+ <p>
+ The first stage of the process is that the result of the vote thread should be
+ carbon copied to the pmc list by the existing committer who will be executing
+ the required process. An email should be sent to the prospected committer offering
+ them committership preferrable with the <code>from</code> header set to an
+ apache.org email address
+ and the <code>reply-to</code> header set to
+ <strong>pmc at portals.apache.org</strong> (so that the reply will be recorded on that list).
+ Note that non-pmc members will need to add a additional <code>reply-to</code> header so that they receive a copy.
+ </p>
+ <p>
+ This is an
+ example offer letter:
+ </p>
+
+<source><![CDATA[
+Dear Contributor,
+
+The Portals project would like to offer you commit privileges.
+We have been impressed with your contributions up till now, and
+believe that your involvement will improve the quality of the
+libraries we produce.
+
+It is important that you realize that these commit privileges give
+you access to the specific Portals project repository for which you
+are involved with. They do not provide commit access to any other
+Apache based project. Those projects will have to grant you commit
+privileges themselves.
+
+If you are interested in having commit privileges, please just let us
+know, and we will setup an account on apache.org. It would expedite
+the process if you could provide your preferred account name and
+possibly a public SSH key. This process could take a few days once
+we get this information.
+
+We all hope that you accept this invitation.
+
+The Portals Project Management Committee.
+]]></source>
+
+ <p>
+ Once a positive acknowledgement has been received, the new Committer should be sent an
+ acknowledgement. This acknowledgement is a good time to ask for their preferred
+ ASF user name.
+ Here is an example acknowledgement letter.
+ </p>
+
+ <source><![CDATA[
+Dear Committer,
+
+Thank you for accepting our invitation.
+
+If you have not already done so, please sure to submit the
+Contributor License Agreement to the Apache Software Foundation
+<http://www.apache.org/licenses/index.html#clas>.
+
+Once the Contributor License Agreement is submitted, please reply to me
+with the your preferred ASF login name.
+
+Please review the Newbie Committer FAQ
+<http://portals.apache.org/site/newbie.html> and the other materials
+on the website that describe your role as a Committer.
+
+We are honored that you have accepted our invitation and are
+sincerely grateful for your assistance. We look forward to working
+together.
+
+The Portals Project Management Committee.
+
+]]></source>
+
+ <p>
+ Once the preferred ASF login name has been received from the new committer,
+ an email should be sent to: <strong>root at apache.org</strong>
+ requesting that the account be created. A carbon copy must be sent to the
+ <strong>pmc at pmc.apache.org</strong>. It is recommended that your official
+ apache.org email address be used to send this information.
+ Failure to follow these instructions may result in the request being delayed or
+ ignored.
+ The following information
+ must be included in the email:
+ </p>
+
+ <ul>
+ <li>
+ The name and email address of the new user.
+ (ie: John Smith <john.smith.AT.foo.DOT.com>);
+ </li>
+ <li>
+ Suggested account userid. This is optional
+ (ie: jmsith);
+ </li>
+ <li>
+ The project that the user should be given access to
+ (ie: Portals Foo);
+ </li>
+ <li>
+ The results of the votes. In other words, the names and email
+ addresses of the committers who approved the addition;
+ </li>
+ </ul>
+ <p>
+ Here is a template:
+ </p>
+
+ <source>
+ {real name} is a new {project name} committer. Please setup his apache.org account.
+
+ Name: {desired apache login}
+ Email: {committers email address on the ASF lists}
+ Projects: {comma separated list of ASF projects to which access should be granted}
+
+ Vote: {url to vote thread on mailing list archive}
+ </source>
+
+ <p>
+ The actual account will not be set up until the Contributor License has been received and filed.
+ This may take a few days so please be patient.
+ </p>
+
+ <p>
+ Note 0: If a committer already has an account on the apache.org server
+ and the committer needs commit access to additional projects, then all
+ that needs to be done is to have the user notify
+ pmc@jakarta.apache.org with the results of the voting (as documented
+ above) and the user will be given access. In other words, the root
+ email address should only be used on the basis of new account
+ creation.
+ </p>
+
+ <p>
+ Note 1: All committers will be given access to the portals site module
+ on request. In other words, committers should be able to update the
+ main Portals website.
+ </p>
+
+ <h2>Emeritus Committers</h2>
+
+ <p>
+ At times, Committers may go inactive for a variety of reasons. The Portals
+ PMC has defined a specific status of Emeritus Committer to deal with these
+ inactive committers.
+ </p>
+ <p>The status of Emeritus Committer is defined by the following policies:</p>
+ <ul>
+ <li>Any current committer in a Portals subproject can ask to
+ become an Emeritus Committer of this subproject at any time</li>
+ <li>Any committer that has not participated in the sub-project
+ in the last year (ie not committed anything in the
+ sub-project repository and not posted anything in the
+ mailing-lists) will automatically be converted to Emeritus
+ Committer of this sub-project.</li>
+ <li>An Emeritus Committer is listed as such on the subproject
+ website but doesn't have any privilege on the sub-project, e.g.
+ no commit privileges, no voting rights, etc...</li>
+ <li>Any Emeritus Committer of a subproject can ask to become
+ full Committer on the sub-project development list. He or
+ she will automatically be accepted as Committer without vote.</li>
+ </ul>
+ <p>
+ A list of some of our current Committers and Emeritus Committers can be
+ found in our <a href="./whoweare.html">Project Credits</a>.
+ </p>
+
+ <h2>Project Management Committee (PMC)</h2>
+
+ <p>
+ Committers who frequently participate with valuable contributions may
+ have their status promoted to that of a "<em>Project Management
+ Committee Member</em>". This committee is the official managing
+ body of the Portals Project and is responsible for setting overall
+ project direction. In order to become a Member, someone on
+ the PMC must nominate the Committer. The individual may then be
+ approved with a 3/4 majority of the PMC.
+ </p>
+
+ <p>
+ To view the Project Management Committee bylaws, <a href="management.html">
+ click here</a>.</p>
+
+ <p>
+ A list of our current PMC Members can be found in our <a
+ href="./whoweare.html">Project Credits</a>.
+ </p>
+ </section>
+
+</body>
+</document>
\ No newline at end of file
Added: portals/site/xdocs/whoweare.xml
==============================================================================
--- (empty file)
+++ portals/site/xdocs/whoweare.xml Sun Oct 24 07:50:53 2004
@@ -0,0 +1,93 @@
+<?xml version="1.0"?>
+<!--
+Copyright 1999-2004 The Apache Software Foundation
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+<document>
+ <properties>
+ <author email="general.AT.portals.DOT.apache.DOT.org">Apache Portals Project</author>
+ <title>Who We Are</title>
+ </properties>
+ <body>
+ <section name="Who We Are">
+ <p>
+The Portals Project operates on a meritocracy: the more you do, the
+more responsibility you will obtain. This page lists all of the people
+who have gone the extra mile and are Committers or members of the
+Project Management Committee. If you would like to get involved, the
+first step is to join the <a href="./mail-lists.html">mailing
+lists</a>.
+</p>
+ <p>
+We ask that you please do not send us emails privately asking for support. We
+are non-paid volunteers who help out with the project and we do not
+necessarily have the time or energy to help people on an individual
+basis. Instead, we have setup <a href="./mail-lists.html">mailing
+lists</a> which often contain hundreds of individuals who will help answer
+detailed requests for help. The benefit of using mailing lists over private
+communication is that it is a shared resource where others can also learn from
+common mistakes and as a community we all grow together.
+</p>
+
+<p>
+The following are short bios regarding a few of the Portals Committers who took the time to post them here.
+If you are a Portals Committer, please consider posting your bio to the General <a href="./mail-lists.html">mailing list</a>, with a note to add it to this page.
+(Or if you have the karma, post it yourself =:0)
+</p>
+
+<p>
+A complete list of all the Apache Committers is <a href="http://www.apache.org/~jim/committers.html">also available</a>.
+(It's a long list, so please be patient.)
+</p>
+
+ </section>
+ <section name="Project Management Committee">
+ <p><b>Jeremy Ford</b> (jford at apache.org)<br/></p>
+ <p><b>Santiago Gala</b> (sgala at apache.org)<br/></p>
+ <p><b>Raphael Luta</b> (raphael at apache.org)<br/></p>
+ <p><b>Julie MacNaught</b> (jmacna at apache.org)<br/></p>
+ <p><b>Mark Orciuch</b> (morciuch at apache.org)<br/></p>
+ <p><b>Paul Spencer</b> (paulsp at apache.org)<br/></p>
+ <p><b>David Sean Taylor</b> (taylor at apache.org)<br/></p>
+ <p><b>Scott T. Weaver</b> (weaver at apache.org)<br/></p>
+ <p><b>Carsten Ziegler</b> (cziegler at apache.org)<br/></p>
+ </section>
+ <section name="Committers">
+ <p><b>Stefan Behl</b> (behl at apache.org)<br/></p>
+ <p><b>David Dewolf</b> (ddewolf at apache.org)<br/></p>
+ <p><b>Ate Douma</b> (ate at apache.org)<br/></p>
+ <p><b>Peter Fisher</b> (pfisher at apache.org)<br/></p>
+ <p><b>Jeremy Ford</b> (jford at apache.org)<br/></p>
+ <p><b>Santiago Gala</b> (sgala at apache.org)<br/></p>
+ <p><b>Paul Hammant</b> (hammant at apache.org)<br/></p>
+ <p><b>Stephan Hepper</b> (sthepper at apache.org)<br/></p>
+ <p><b>Stefan Hesmer</b> (shesmer at apache.org)<br/></p>
+ <p><b>Richard Jacob</b> (jacob at apache.org)<br/></p>
+ <p><b>David Le Strat</b> (dlestrat at apache.org)<br/></p>
+ <p><b>Nick Lothian</b> (nlothian at apache.org)<br/></p>
+ <p><b>Raphael Luta</b> (raphael at apache.org)<br/></p>
+ <p><b>Julie MacNaught</b> (jmacna at apache.org)<br/></p>
+ <p><b>Andrew C. Oliver</b> (acoliver at apache.org)<br/></p>
+ <p><b>Mark Orciuch</b> (morciuch at apache.org)<br/></p>
+ <p><b>Sam Ruby</b> (rubys at apache.org)<br/></p>
+ <p><b>Roger Ruttimann</b> (rogerrut at apache.org)<br/></p>
+ <p><b>Paul Spencer</b> (paulsp at apache.org)<br/></p>
+ <p><b>Davanum Srinivas</b> (dims at apache.org)<br/></p>
+ <p><b>Shinsuke Sugaya</b> (shinsuke at apache.org)<br/></p>
+ <p><b>David Sean Taylor</b> (taylor at apache.org)<br/></p>
+ <p><b>Scott T. Weaver</b> (weaver at apache.org)<br/></p>
+ <p><b>Jun Yang</b> (jyang at apache.org)<br/></p>
+ <p><b>Carsten Ziegler</b> (cziegler at apache.org)<br/></p>
+ </section>
+ </body>
+</document>