OPS4J
  Processes
 Browse Space
Added by Niclas Hedhman, last edited by Niclas Hedhman on Aug 24, 2006  (view change)

Labels

 
(None)

OPS4J is based on Principles, governed by Rules, operated with Procedures to achieve various Goals.

OPS4J is somewhat different than other Open Source projects as we are much more focused on commercial use of the parts, and that we want more people to participate.

Principles

  • Common Sense.
  • Participation is Open to everyone by default.
  • Participate, collaborate and succeed together.
  • Consensus preferred, majority vote among participants to resolve.
  • Discussion before design/implementation.
  • Compatibility is of highest priority.
  • Projects can fork, convergence is encouraged.

Rules

  • The Principles must be held high.
  • The Executive is final instance of all disputes, and its decision must be respected.
  • Changes to procedures must pass an absolute majority vote.
  • Stakeholders elects the Executive, not less than once every 2 years, not more often than once a year.
  • The Executiveinitiates such election. Nominees are presented, and each is voted upon by the stakeholders according to Majority Vote procedure.
  • Procedure must be followed.
  • Guidelines from the Executive and the Infrastructure must be respected.

Procedures

- What other procedures do we really have.

Code Ladder

  • Plenty of Experiment in Laboratory.
  • Gather another developer around your experiment, and move it into Projects.
  • Projects can graduate to a Product, after finalizing a set of criteria;
    • 5 Active developers.
    • its own mailing list, with at least 200 mails per month for two consequetive months.
    • source repository organized in accordance with Infrastructure guidelines.
  • Projects that becomes inactive is moved to Cemetery. Resurrection from Cemetery goes back into Laboratory.
  • Products must follow strict guidelines of product management, to ensure compatibility, quality and positive user experience.

Voting

Voting should be avoided. Only if no clear consensus is reached should formal voting take place. All participants of the scope for which the vote is called upon, are eligible to vote. The vote is initiated by a Proposer. The Proposer presents a Proposal on the mailing list which is relevant to the proposal. These are the formal requirements of the Vote format;

  1. The mail must be marked "[VOTE]" in the beginning of the Subject line.
  2. It must be in the format of "In Favor" / "Not in favor", where "In Favor" reflects a change from current status quo.
  3. It must state if it is a Majority Vote or an Absolute Majority Vote.
  4. It must state the Voting Period.
  5. It must refer to the discussion of the proposal in the mail archives.
Quorum

Quorum is established if either of

  • >=50% of Active (commits no older than 6 months) developers.
  • >=20% of all subscribers of the mailing list the vote is proposed on.

cast a vote.

Voting Period

The proposer will state the voting period in the proposal, but it must be no shorter than the voting period for the type of vote being held (see below), and no longer than 2 months. The Voting Period starts when the Proposal is sent to the mailing list. The mail archive will be used to determine the exact time, if dispute arises.

Casting Vote

Any participant who wants to partake, sends the vote to the mailing list. It must clearly indicate whether "In favor" or "Not in favor". Participants are allowed to change the vote up until the Voting Period has expired.

Majority Vote
  1. In Favor: >50%
  2. Voting Period: 2 weeks.
Absolute Majority Vote
  1. In Favor: >66%
  2. Voting Period: 4 weeks.
Results

After the Voting Period, the Proposer collates and counts the votes. The Proposer is responsible, but other participants should make sure it is done correctly, and aid the Proposer. The results are sent to the same mailing list with a subject line starting with [VOTE RESULTS] and contain a reference to the mail archive of the initiating Vote mail. It should show who voted "In favor" and who voted "Not in favor", so the participants can check the count of their own vote. Any discrepancies should be corrected in consensual manner. The project/product Vote page on Wiki should be updated with a reference to the Vote Result mail.

Appeals

After a vote, any participant can appeal to the Executive to over-turn the result. Appeals must refer to that the outcome of the vote will violate the Principles or Rules of ops4j.org and provide evidence thereof. The Executive will investigate, and meanwhile the vote is held in quaranteen. The Executive must produce a resolution within 4 weeks, or the vote is valid.

Goals

The goal of OPS is to free not only the use of OSS but even the establishment, thus exploring ways of creating a self-organizing bazaar in it's true meaning employing an approach we call the FlockOfBirds

Community

Commercial

OPS4J wants to provide means for companies to benefit from OSS without the risk/need to be directly involved in the highly volatile participation process.

OPS4J will try to establish a commercial "web of knowledge" that loosely connects individuals and companies that can provide not only services and products based on OPS4J technical platform but also

  • provide help to restructure the customers in-house development according to OSS and OPS4J principles,
  • provide help to feed non-core software investments back into OSS (not only OPS4J) for the benefit of the customer (low maintenace/risk, Stallmans freedoms) and the OSS community (commercial donations),
  • provide professional-grade support on OPS4J in the lists and via IRC etc. (goal is answer time within 30minutes)