Author: niclas
Date: Sun Mar 27 03:08:07 2016
New Revision: 1736716
URL: http://svn.apache.org/viewvc?rev=1736716&view=rev
Log:
Updating community pages, as they are somewhat outdated.
Modified:
zest/site/src/community/participate.html
zest/site/src/community/playing_field.html
Modified: zest/site/src/community/participate.html
URL:
http://svn.apache.org/viewvc/zest/site/src/community/participate.html?rev=1736716&r1=1736715&r2=1736716&view=diff
==============================================================================
--- zest/site/src/community/participate.html (original)
+++ zest/site/src/community/participate.html Sun Mar 27 03:08:07 2016
@@ -39,47 +39,26 @@ layout: default
<h2>Principles of Participation <small>(not enforced yet)</small></h2>
<p>
- We borrow a lot of our principles in community building from
OPS4J, which also provides us with the infrastructure
- needs we have for the time being. OPS4J is unique that it allows
everyone to participate and modify the codebase
- without being voted into the community, like Apache and other
communities. We want the spirit of this, but we are a bit
- nervous that Apache Zest⢠will be too successful and too many
people want to modify the core pieces and some will spoil more
- than progress.
+ We borrow a lot of our principles in community building from
OPS4J, as OPS4J was the initial home of Apache Zest, called
+ Qi4j back then. OPS4J is unique that it allows everyone to
participate and modify the codebase
+ without being voted into the community. We want to retain the
spirit of this openness and low-barrier of entry, but need
+ some structure to organize ourselves.
</p>
<p>
- We have therefor concluded that we will, at least initially,
confine the Apache Zest⢠Core to entrusted members of the
- community only, whereas everyone is free to participate in the
many other sub-projects, such as extensions, libraries
- and integration solutions. By the introduction of Git, it is now
much easier for people to work on any part of the
- system, even if they have no official commit rights and allow
people to review the work, then commit it and the right
- person gets the credit.
+ There is a social agreement among the community members that we
should try to communicate our intent as much as possible,
+ but not be held back from doing things, just to get approval for
the changes. Reverting changes are easy in GIT, so a
+ Commit-Then-Review policy is in effect. Individual changes can be
vetoed, and the veto comes with a motivation to be valid,
+ and for additional features or bug fixes, the veto needs to
provide an alternative solution within two weeks. The veto stands
+ either until the person who cast the veto withdraws it, or for two
weeks and no alternative solution has been presented. We
+ think this strikes a good balance between progress and avoidance
of catastrophic changes.
</p>
- <h2>Core Dev Team</h2>
+ <h2>I want to help, what do I do?</h2>
<p>
- The Core team are the Stewards and Guardians of the overall
project. They ensure that all pieces of Apache Zest⢠are in good
- standing and assist in all matters of the project. Only the Core
Team will modify the official Apache Zest⢠Core repository.
+ First of all, subscribe to [email protected] and introduce
yourself. Secondly, take a look at the outstanding JIRA issues
+ and see if there is anything that you are capable of working on.
Communicate that with the community. If there is no issues,
+ that you can manage, consider creating your own JIRAs, such as
working on the Getting Started guide or more test cases.
</p>
-
- <h2>Platform Team</h2>
- <p>
- The Platform team are the work horses of the project, and are
adding a lot of value to our libraries and extensions.
- These two repositories are where the bulk of the valuable code
will eventually reside. The Platform Team consists of
- people who are showing dedication to the project.
- </p>
-
- <h2>Community</h2>
- <p>
- All remaining areas are open to anyone who ask (politely). Send an
email to the [email protected] mailing list
- together with an introduction of yourself.
- </p>
-
- <h2>Additionally</h2>
- <p>
- GitHub's community features should not be understated. You are
encouraged to clone our repostories, work on your own
- features and do pull requests for Core and Platform teams to pick
up. It is wise to send a message to
- the [email protected] mailing list before issuing a pull
request along with an explanation of what the patch is
- for and the rationale behind it.
- </p>
-
</div>
<div class="span2"></div>
</div>
Modified: zest/site/src/community/playing_field.html
URL:
http://svn.apache.org/viewvc/zest/site/src/community/playing_field.html?rev=1736716&r1=1736715&r2=1736716&view=diff
==============================================================================
--- zest/site/src/community/playing_field.html (original)
+++ zest/site/src/community/playing_field.html Sun Mar 27 03:08:07 2016
@@ -22,7 +22,7 @@ layout: default
spaces are between operators and so forth. We are following the
OPS4J coding standards, as they have IDEA, Eclipse and
Checkstyle templates prepared or in the works. These are slowly
evolving, and it is likely we will evolve with them.
The coding standards can be found in
- <a
href="https://scm.ops4j.org/repos/ops4j/projects/community/resources/";>https://scm.ops4j.org/repos/ops4j/projects/community/resources/</a>.
+ <a
href="https://github.com/apache/zest-java/tree/develop/etc";>https://github.com/apache/zest-java/tree/develop/etc</a>.
</p>
<h2>Design and Implementation work</h2>
@@ -33,18 +33,31 @@ layout: default
the IM log) any new development, ideas and progress that occur
during those sessions. The decisions for any multiple
choices should be made on the [email protected] mailing list
only.
</p>
-
- <h2>Committers</h2>
+ <h2>Community Structure</h2>
+ <h3>Committers</h3>
<p>
The term "committer" is often used in open development efforts,
and in Apache Zest⢠it refers to the individuals who has commit
- rights to a particular part of the codebase. Some areas in Apache
Zest⢠codebase are open to everyone, others are based on
- meritocracy where individuals who has been contributing to the
subproject are invited by the existing committers.
- People who has not contributed to a subproject over the last 12
months are no longer considered committers, although
- the commit rights will not be revoked. Note that "rights" in this
context is a social contract, as no ACL is in place
- to stop a Community member to mess up the Apache Zest⢠Core. It
is mostly a matter of loss of reputation at stake, since
- it is easy to revert these and if found to be malicious the member
will have all commit rights revoked.
+ rights to the codebase. Committers are invited by other
committers, typically after some contribution via JIRA (Pull Requests
+ are not yet fully supported by the Apache infrastructure, but may
change in the future. )
</p>
+ <h3>Project Management Committee</h3>
+ <p>
+ Apache has a concept called <i>Project Management Committee</i>
(or PMC for short), which is the stewards of the codebase/project.
+ It is up to each PMC to define the rules for the project, who gets
invited, the workflow for changes and evrything else
+ that is not required from the Foundation itself, such as
Licensing, Releases, Branding and source control management.
+ </p>
+ <p>
+ At Apache Zest, we want to see all active committers to be part of
the PMC. To have a voice of the future of the project.
+ Committers that are inactive are encouraged to resign from the
PMC, but will retain the committer status and invited back
+ to the PMC again, once activity picks up. This will not be
enforced, but purely on voluntary basis.
+ </p>
+ <h3>PMC Chair & VP of Apache Zest</h3>
+ The PMC Chair is an appointment by the Board, and acts as the link
between the project and the Board, primarily for so called
+ <i>oversight</i>, i.e. that the Board has knowledge of any
community issues in a project. The PMC Chair is an <i>Officer</i>
+ of the Foundation, but in reality the Chair is a glorified
secretary, responsible for providing a short report once every
+ quarter and answer any questions that the Board may have.
+
<h2>Votes on releases</h2>
<p>
All committers agree that all releases should be voted upon before
the release is made. Releases should happen early
