ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject cvs commit: ws-admin Charter.txt
Date Tue, 26 Aug 2003 07:03:36 GMT
dims        2003/08/26 00:03:36

  Added:       .        Charter.txt
  Wiki Text
  Revision  Changes    Path
  1.1                  ws-admin/Charter.txt
  Index: Charter.txt
  = Web Services Project Charter =
  === 1 Introduction ===
  1.1 is a collaborative software development project
  dedicated to providing robust, full-featured, commercial-quality, and
  freely available Web Services support on a wide variety of platforms.  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 Web Services software and related
  1.2 This charter briefly describes the mission, history, organization, and
  processes of the project.
  === MISSION ===
  2.1 exists to promote the use of Web Services. We view 
  Web Services as a compelling paradigm that acts as a glue in a distributed
  environment. We intend to build freely available Web Services
  components in order to engender such improvements.
  2.2 defines a set of components that form the basis of 
  a Web Services Stack. Where appropriate, these components plug into each other using
  standard APIs (formal, de facto, or proposed). The components must be
  high performance, reliable, and easy to use.  Where inter-related, The components must be
  part of an underlying architectural orchestration that will allow them
  to work together without major negotiations or breakage. 
  2.3 We believe that the best way to define this Web Services
  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.
  2.4 In order to achieve a coherent architecture between
  components and other components and applications, standards (formal or
  de facto) will be used as much as possible for both protocols and
  APIs. Where appropriate, experiences and lessons learned will be fed 
  back to standards bodies in an effort to assist in the development of 
  those standards.  We will also encourage the innovation of new
  protocols, APIs, and components in order to seed new concepts not
  yet defined by standards.
  === 3 HISTORY ===
  This project was established under the direction of the Apache Software Foundation in January
2003 to facilitate joint
  open-source development.
  === 4 TERMS ===
  4.1 The ASF Board.  The management board of the Apache Software 
  4.2 The Project.  The Apache Web services Project, referred to in this
  document as "" or "" or "the project" or
"the project".
  4.3 Subproject. is comprised of a number of subprojects;
  a subproject is responsible for a component or application whose scope
  is well defined.
  4.4 Contributor.  Anyone who makes a contribution to the development
  of the project or a subproject.
  4.5 Committer.  Each subproject has a set of committers.  Committers
  are contributors who have read/write access to the source code
  5.1 The project is managed by a small, core group of
  contributors known as the Project Management Committee [PMC], with representation from all
  5.2 The activities of the PMC are coordinated by the Chairperson,
  who is an officer of corporation and reports to the Apache
  Board.  The Chairperson will, on the request of the Apache Board, 
  provide reports to the Board on issues related  to the running of 
  the project. 
  5.3 The PMC has the following responsibilities:
  a) Accepting new subproject proposals, formally submitting these proposals for committer
vote, and creating the subproject (see SUBPROJECTS below). This is done in collaboration with
the Incubator (see
  b) Facilitating code or other donations by individuals or companies in collaboration with
the Incubator.
  c) Resolving license issues and other legal issues in conjunction with the ASF board.
  d) Ensuring that administrative and infrastructure work is completed.
  e) Facilitating relationships among projects and subprojects.
  f) Facilitating relationships between and the external world.
  g) Overseeing to ensure that the mission defined in this document
is being fulfilled.
  h) Resolving conflicts within the project.
  i) Reporting to the ASF board (through the Chair) on the progress of the project.
  5.4 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. 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
  5.5 In cases where the sub-project is unable to directly provide a 
  representative on the PMC, another member of the PMC will be required 
  to represent that sub-project on the PMC.  This will be strongly
  discouraged.  It is preferable that all sub-projects have direct 
  representation on the PMC.
  5.6 Once the PMC selection process has completed, the PMC will provide 
  a recommendation to the Apache Board for the position of Chairperson 
  of the PMC. 
  5.7 This recommendation will be made on the basis of an election held 
  within the PMC.  The election will be performed using a simple
  majority vote of PMC members.
  5.8 Upon agreement by the Apache Board, the recommended Chairperson will, 
  if they are not already, be appointed an officer of the corporation.  
  See for more information.
  5.9 In the unlikely event that a member of the PMC becomes disruptive to
  the process, ceases to make codebase contributions for an extended 
  period, or ceases to take part in PMC votes for an extended period of
  time, said member may be removed by unanimous vote of remaining PMC members.
  5.10 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 active committers, in which
  case a two-thirds majority must approve the change.
  === 6 SUBPROJECTS ===
  6.1 is comprised of subprojects; a subproject is
  responsible for component or application whose scope is well defined.  
  Each subproject has its own set of developers, and is responsible 
  for approving its own committers.
  6.2 A new subproject proposal is submitted to the PMC, and then accepted
  by a majority active committer vote.
  6.3 A subproject may be removed by unanimous vote of the PMC, subject to the
  approval of the ASF board.  A contributor may challenge the removal of a 
  subproject at any time and ask for a vote of all active committers, in
  which case a two-thirds majority must approve the change.
  === 7 CONTRIBUTORS ===
  7.1 Like all Apache projects, the Web Services project is a meritocracy -- the more
  work you do, the more you are allowed to do. Contributions will include participating in

  mailing lists, reporting bugs, providing patches and proposing changes to a product.
  7.2 Developers who make regular and substantial contributions may become
  committers as described below.
  === 8 COMMITTERS ===
  8.1 Each subproject has a set of committers. Committers are contributors who
  have read/write access to the source code repository. New committers
  are added when a contributor is nominated by a committer and approved by
  at least three of the active 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.
  8.2 For the purposes of voting, committers will be classed as "active" or
  "inactive". Only active committers will be included in the totals used to 
  determine the success or failure of a particular vote.
  8.3 Committers remain active as long as they are contributing code or
  posting to the subproject mailing lists.  If a committers has neither
  contributed code nor posted to the subproject mailing lists in 3
  months, the PMC representatives for that subproject will e-mail the 
  committer, the subproject development list, and the PMC mailing list 
  notifying the committer that they are going to be moved to inactive 
  status.  If there is no response in 72 hours, the committer will become 
  8.4 An inactive status will not prevent a committer committing new code
  changes or posting to the mailing lists.  Either of these activities will
  automatically re-activate the committer for the purposes of voting.
  9.1 The project site must provide the following:
  a) Bug Database -- This is a system for tracking bugs and feature
  b) 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
  c) Website -- An website will contain information about
  the project, including documentation, downloads of
  releases, and this charter. Each subproject will have its own website
  with subproject information.
  d) 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.
  e) General Mailing List -- This mailing list is open to the public. It is
  intended for discussions that cross subprojects.
  f) 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.
  === 10 LICENSING ===
  10.1 All contributions to the project adhere to the 
  "ASF Source Code License." All further contributions must be made under the
  same terms. All contributed files must contain the full text of the ASF 
  Source Code License.
  11.1 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
  12.1 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.
  12.2 It is recommended that each subproject have a smoke-test system 
  that works at least as a basic integration test.
  13.1 The project should work closely with other Apache
  projects, such as XML, Jakarta and the Apache Server, to avoid redundancy
  and achieve a coherent architecture among and these

View raw message