Charter of the Open Object Rexx Project

This Charter defines the purpose, mission, and organization of the Open Object Rexx open source development project.

This charter was approved by the RexxLA Board on Monday 17th April 2005

Purpose

Open Object Rexx (ooRexx) is a platform-independent application and scripting development tool, originally developed and marketed by IBM® as "Object REXX". In 2004, IBM contributed the source code of Object REXX for Microsoft® Windows®, IBM® AIX®, Linux®, and SUN Solaris® to The Rexx Language Association (RexxLA) to be made available under the Common Public License (CPL) V1.0. The RexxLA Open Object Rexx Project (Project) was established to provide the source code to Open Object Rexx on an Internet-accessible code repository, freely available to all.

Mission

  1. To create, maintain, enhance, and support Open Object Rexx language processors and documentation.
  2. To respond promptly with corrective service to legitimately reported defects.
  3. To maintain the conformance of Open Object Rexx to the applicable open standards and licenses and to encourage conforming extensions of the language.
  4. To promote Open Object Rexx as a development tool for programmers and to encourage the adoption of Open Object Rexx in open source and proprietary software and operating systems.

Organization

The ooRexx project is governed by the RexxLA Board of Directors (Board) which appoints the Development Team and guides the Project mission. The Development Team consists of volunteers who are representatives of the Rexx community willing and able to commit time and energy to fulfilling the Project mission.

Membership

The ooRexx Project is a meritocracy - the more one does to advance the mission, the more one will be allowed to do. The merit stages within the ooRexx project are as follows:

  • A User is anyone who uses ooRexx. User participation in the Project may be active (responds to mailing list questions, reports bugs/feature requests) or passive (simply uses ooRexx).
  • A Developer is an active User who contributes patches or enhancements to the code or documentation, but does NOT have write access to the code repository.
  • A Committer is a Developer who has write access to the code repository, and voting rights on Project issues.

Promotion

Developers who submit frequent and valuable contributions to the Project may be promoted to Committer. Committers have write access to the Project code repository and voting rights allowing them to directly affect the state of the Project. In order for a Developer to become a Committer, another Committer must nominate the Developer. (A Developer may ask to be nominated.) If there are at least three positive votes and no negative votes, the Developer is recommended to the Board. If the Board approves the promotion, write access to the Project code repository is granted and the Developer is added to the Development Team Mailing List. Becoming a Committer is a privilege that is earned by showing discipline and good judgement. It is a responsibility that should be neither given nor taken lightly.

Demotion

Committers may become unproductive for various reasons. The orderly functioning of the Project relies on active Committers who participate constructively in discussions, complete assigned tasks, and vote, in a timely manner. An unproductive Committer may be demoted by the Board upon the recommendation of a majority of the other Committers. The Project Manager is authorized by the Board to immediately revoke the status of any Committer if necessary to maintain the orderly functioning of the Project. The Project Manager shall submit a justification of an immediate revocation within 48 hours of a request for same from the Board.

Voting

Each member of the Development Team is granted one vote which must be one of the following responses: +1 (Yes), -1 (No), 0 (Abstain). Committers are required to track, discuss, and vote on relevant issues affecting the Project. The voting process is conducted on the Development Team Mailing List and will specify the resolution in question and a deadline at which the voting concludes. For a resolution to pass, valid votes must be received from a majority of the members of the Development Team, and the sum of all valid votes must be positive (>0). All "No" votes must provide, before the voting deadline, an explanation for the "No" vote, otherwise that vote will be invalid. Upon the expiry of the deadline, all unreceived votes will be invalid. The voting process concludes at the deadline or once no further votes can change the outcome.

For example, a resolution with a 48 hour deadline is submitted to all five members of the Development Team:

  • three "Yes" votes arrive within 24 hours: voting concludes and the resolution passes.
  • after 48 hours, only two valid votes are received: voting concludes and the resolution fails.
  • after 48 hours, the sum of all valid votes is zero (0): voting concludes and the resolution fails.

Roles and Responsibilities

RexxLA Board

The Rexx Language Association is a non-profit corporation under the laws of the State of North Carolina, USA. The RexxLA Board of Directors sanctions and governs the Open Object Rexx project. RexxLA is responsible for any commercial relationships, marketing programs, and fiscal planning and management issues related to the Project. The Board is ultimately responsible for all matters regarding the Project Mission and Organization, including determining the membership of the Development Team.

Development Team

The day-to-day operation of the project is effected by the Development Team. The Development Team is responsible to the Board and the Open Object Rexx community to carry out the necessary actions to achieve the Project mission. Each member of the Development Team has one or more roles and responsibilities based on expertise and time commitment. The Development Team comprises all Committers and other members appointed by the Board.

Certain members of the Development Team have specific responsibilities:

Project Manager
  • Assesses progress and assigns tasks to other members of the Development Team
  • Performs project planning and management, including determination of ooRexx code releases
  • Maintains relationships with the RexxLA Board, other Open Source projects, and the media
Architect
  • Provides direction for the Open Object Rexx language, including determination of ooRexx behaviour
Project Administrator
  • Manages the Project web site and code repository
  • Maintains the Project archives, including Team membership, discussions, and votes conducted
Test Manager
  • Tests ooRexx on multiple platforms using a formal test suite and typical user software
  • Validates ooRexx conformance with appropriate open standards and licenses

Contributions to the ooRexx Project

The Open Object Rexx source code is distributed under the Common Public License V1.0. All contributions of source code or documentation, no matter the size, must adhere strictly to the CPL v1.0.

There is to be no contamination of the ooRexx code or documentation base.

Contributions may be

  • original work of the contributor, or
  • portions of other projects, or
  • original work of the contributor included in another project

provided that the distribution license of the contributed source code is compatible with CPL v1.0. To be compatible, the license of the contributed source code must be less restrictive, or equivalently restrictive as the CPL v1.0.

It is the responsibility of the contributor to ensure that the source distribution license is compatible with CPL v1.0

Note that license compatibility extends to all libraries used by the contributed code. Code which requires ooRexx to include additional libraries that are not compatible with CPL v1.0 cannot be accepted.

Contributers (and Committers) should read the Procedures for Contributions for details of how to submit contributions.

Evolution and Modification of the ooRexx Charter

The RexxLA Board may, from time to time, make modifications to this Charter. A proposed modification will be submitted to the Board and the Developer Mailing List for review and comment. All proposed changes to the Project Charter will be posted on the Open Object Rexx Project website for community discussion. After a sufficient time for comments, the President of RexxLA will call for a vote by the Board on the proposed Charter modification. A majority vote in favor of the proposal is necessary for the modification to be adopted.