Roles & Responsibilities

The MMBase community exists of roughly three groups.

These are the users, sponsors, and developers.

Most of this document focuses on developers, whose exact roles and responsibilities are based on merit. Everybody can help no matter what their role, but those who have been long term or valuable contributors to the project may obtain rights to vote on source changes and commit directly to the source repository. These subgroups (the Committers and the MMC members) are detailed below along with the more broader community groups.

Users

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. When a user starts to contribute code or documentation patches, they become a developer.

Users may include administrators, end-users (editors), web-designers, and other interested parties. Users can post their questions and finsings on the MMBase user mailinglist (users@mmbase.org).

Sponsors

Sponsors are those organisations that support the MMBase community through contributions other than development, such as providing hardware, promotion through marketing, or by making monetary donations.

Sponsors can operate on their own, or through the MMBase Foundation, which supports the MMBase community by taking care of facilities needed for the continuing development of MMBase. Such facilities include maintaining the website, organizing events and courses, marketing, and writing documentation.

The foundation does not have influence on the development of MMBase, but can provide input, report bugs, and communicate desires as any other MMBase user, and may provide advise on the development of components by third parties.

Developers

Developers are the people who write code or documentation patches or contribute positively to MMBase in other ways. A developer's contribution is always recognized. In source code, all developers who contribute to a source file may have their name added to the list of authors for that file (in the java documentation of the +>developers@mmbase.org).

Developers may go inactive for a variety of reasons. A Developer that has been inactive for 6 months or more may lose his or her status as a Developer (be removed from the site). The MMC needs to confirm the inactivity fo the developer, but need not call a vote (this is mostly an administrative task).

Developers may also lose there status due to bad behavior such as harassament or flaming. Developers who lose their status this way are removed from the site and banned from the developers' mailinglist. Due to the latter measure, a unanimous, non-negative call need succeed (see voting, below).

CVS rules

A developer has no submitting rights in the MMBase CVS repository. If a developer wants to get something into CVS, he or she has to ask a committer to submit the changes. The committer is responsible for the new code, and for adding the developer's name to the java documentation.

Coding rules

All Java language source code in the repository must be written in conformance to the code conventions that have been set of the MMBase project. These code conventions are an extension of the "Code Conventions for the Java Programming Language" as published by Sun.

The Sun rules can be found at: http://java.sun.com/docs/codeconv/

The more specific MMBase conventions are available from the MMBase website.

The committor that accepts the code is responsible for checking whether the coding rules are followed.

Committers

Developers who give frequent and valuable contributions to MMBase projects can have their status promoted to that of a "Committer" 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.

Note: except where noted below, all rules for a Developer also apply to a Committor.

Becoming a committer

In order for a Developer to become a Committer, another Committer can nominate that Developer or the Developer can ask for it. Once a Developer is nominated, the commiters vote for allowing the committer access. This is a unanimous non-negative call (see voting).

If the calls succeeds, the Developer is converted into a Committer and given write access to the source code repository.

Loosing committer status

Committers may go inactive for a variety of reasons. A Committer that has been inactive for 3 months or more may lose his or her status as a Committer.

Activity as a committer is measured in participation in projects and voting, and in the submission of bugfixes.

Committers may also lose there status if they break the committer rules. A committor receives a warning from the MMC when he breaks a rule (i.e. a CVS rule, a Hack or Project rule, or casting a VETO without motivation). After three warnings, the MMC may take up contact with the committer to ask him to resign. If the committer is not willing, a unanimous, non-negative call need succeed, on the developer list (see voting, below), in which the committer cannot participate.

The MMC is entitled to temporarily disallow CVS access to that committor for the duration of the call.

CVS rules:

Three types of changes can be committed to the source code repository (CVS):

• Changes in or additions to the code related to an approved MMBase project, of which the committer is a member (generally no voting needed, see voting and projects)
• Confirmed bug fixes (no voting needed)
• Code that was written outside of an approved project and is not a bug-fix (a hack), and that has been approved by the community through a majority call with a 3-vote margin (see voting).

MMBase Management Committee (MMC)

Committers who frequently participate with valuable contributions and know sufficient about the core of MMBase may have their status promoted to that of a "MMBase Management Committee Member". This committee is the official managing body of the MMBase project and is responsible for setting overall project direction. In order to become a Member, someone the MMC must nominate the Committer. The individual may then be approved though a unanimous non-negative vote.

Note: except where noted below, all rules for a Committor also apply to a MMC member.

CVS rules

A MMC member has the same rights to CVS as other Committors. A MMC member also has a responsibility for the consistency of the CVS.

MMC members are entitled to rollback changes if committed code puts the CVS in a broken state, or whenever the CVS rules were not followed (i.e. a Hack that did not receive a majority vote was committed).

Other Responsibilities

The MMC is responsible for the release of a stable MMBase distribution.

Any developer or user can participate in creating the release, but at least one MMC members should monitor the process.

Developers may create their own distributions, but the MMC carries no responsibilities for these releases.

Project Rules

A MMBase project is an project that is approved by the MMC. When the project is finished it will be part of MMBase.

An MMBase project meets the following criteria:

• The goal of the project is to add or improve MMBase functionality
• A project leader is responsible for managing the project, committing the new code and/or delivering documentation. (This doesn't mean the project leader has to commit or write documentation himself! This can be delegated to a team member.)

• The project has been approved by the MMC. This is done by proposing the project to the MMC. All developers propose and participate in a project, but only a committer can be a project leader. The MMC votes to approve the project (this is a majority vote with a 3-vote margin), and detemrines the project leader. It is possible for a developer to be given committors status for the duration of a project, so that he can act as the project leader, or to allow him cvs access. In this case, a voting call is made as normal, but the committor status is revoked at the end of the project lifecycle (the duration need be stated explicitly when the call is made).
• The project has to be documented on the MMBase site. The project leader is responsible for keeping the documentation up-to-date. (For instance the project leader adjusts the status of the project.)
• The MMC may decide when to give the project CVS access. A project that has no CVS accass (yet) may not submit code - only write documentation and make proposals. A project with limited CVS access may only majke changes with approvement of the MMC. A project wiyth full CVS access may add or change code as required for the project.

Project leader & members

A project consists of one project leader and any number of project members.

The project leader need to be a committer. Developers van join a project as members.

The project leader starts the project after the MMC has opened it, and is the only one who can make decisions. Project members can propose a decision to the project leader who can grant the decision adding the decision to their project at MMBase.org.

If you don't agree with a made decision contact the project member who proposed the decision and try to find out who is right. If the decision has to change contact the project leader.

If a conflict ensues, the decision may be decided by the project leader or a vote need be called. Votes due to conflicts in decisions need be documented on the project page at the MMBase site, as part of the decision.

Project documentation

A project leader has to inform the MMBase community about the project. This is done by keeping the project information at MMBase.org up to date. When a person starts a project he has to inform the MMBase community by writing an article that can be added to the site and can be posted to the mailing lists.

Project documentation on the site includes:

• The name of the project leader and team members,
• The status, start date and date of the latest change,
• The deliverables (including the code and documentation),
• A short description of the project (including the goal).
• If applicable, a longer description detailing the project's approach and theories, any steps or phases in the project, it's progress, and any changes made to goal or approach during development.

Code documentation

When starting a project, the project leader describes the goal of the project, and the way this will be achieved. This includes a detailed description of the functionality that the new code adds to MMBase. This is the start of the documentation of the code. At the end of the project, the documentation is finished and includes the following:

• The author, project leader and project members
• The date the documentation is finished
• A list of all the code that is related to the project (including new code, changed code, related existing MMBase code and other software that interacts with the new code)
• A description of the new functionality
• A description of how the new code works
• An example of the functionality, preferably including a working example
• An installation guide
• A description of how the new code interacts with other MMBase code and other software
• Full api documentation.

The goal of the documentation is to enable all MMBase users (with the right skills) to use the new functionality.

Hack Rules

A Hack is new MMBase functionality that someone wants to be added to the MMBase source in the CVS. Before the Hack will be added it has to follow the follow the following criteria.

A MMBase Hack meets the following criteria:

• The goal of the Hack is to add or improve MMBase functionality
• The Hack has to be approved by MMBase MMC and Committers. This is done by proposing the Hack to the MMBase developer list and calling for a majority vote. Hacks can be proposed by developers, but only committers can vote.
• The Hack has to be documented on the MMBase site.
• The MMC may decide that an approved Hack is too involved, and may decide to make it a project instead, which means the hack needs to follow the project rules.

A Hack needs to contain the following documentation:

• The names of the persons who helped by making the hack.
• The status, start date and date of the latest change.
• A short design of how the code works.
• A description of the new functionality of the new hack.
• An installation guide (if needed).
• At least one working example.
• A list of all the code that is related to the project (including new code, changed code, related existing MMBase code and other software that interacts with the new code)
• And least but not last, all have to contain apidoc information.

The goal of the documentation is to enable all MMBase users (with the right skills) to use the new functionality.

Bugfix Rules

A bugfix is a piece of code that fixes an error or misbehavior that occurs in the existing code.

If a bugfix changes the functionality of the code (other than solving errors), it is not a bugfix but a Hack.

It is not necessery to vote for a bugfix,but fixes need to be tested and confirmed.

All fixes need be documented when submitted in the MMBase CVS (in the CVS log). The documentation requires explanantion of the fix, the committers name, and reference to the MMBase bugtracker if applicable.

All errors need be documented in the MMBase bugtracker (even as they are solved). This allows users to trace bugs in older products.

Note: adding javadocs, while not technically a bug fix, follows the rules of bugfixing (except you don't add them in the bugtracker).

Voting

When decisions have to be made about MMBase, be it code changes, assigning projects or responsibilities, or on membership as a Committor or on the MMC, a process of voting takes place.

MMC

Voting takes place within the MMC when it deals with opening a project, assigning or revoking CVS access to a project, the includion of expellation fo an MMC member, or when making choices regarding tasks performed by the MMC.

Most calls for voting within the MMC are majority calls with a margin of 3 votes.

Exceptions:

In case of admittance of a new member, this must be an unanimous non-negative call, with a margin of 3 votes. The candidate member is not allowed to vote.(This rule may be dropped in favor of election through the MMbase Community)

In case of expulsion of a member, this must be an unanimous positive call. The member concerned is not allowed to vote. (This rule may be dropped in favor of election through the MMbase Community)

All MMC calls are held during the MMC meetings or during the MMChat, or on the MMC mailinglist. Calls during meetings are resolved immediately. Calls on the list are resolved in the same manner as community calls (see below).

A MMC vote and its decision needs to be made public after voting, even if the vote failed.

Project

Voting takes place within a project when it deals with closing a project (either finishing it or putting it on hold), or with code changes that fall within the scope of that project and that do not affect other projects or the MMBase core.

Changes that affects other projects need the permission (by default, a majority vote) from the other project. Changes that affects non-project code need to be voted on by the community (the committers).

The project leader asks the other project's permission, or calls the vote on the developers list as if it was a vote for committers (see below).

By default, votes within a project are majority votes with no margin, conducted during meetings, though the project leader may agree on a different voting system, or call a decision in case of conflict (see project leaders and decisions, above).

Regardless, project calls should NOT be run on the developer mailinglist.

The results of a vote (succesful or not) may be published on the MMBase website project page (as a decision, or as a change in the project status), as decided by the project leader.

Note: if a project has been granted CVS access by the MMC, and code changes or additions fall within the scope of the project and do not affect other code, no calls need be made to the community. The projectleader is responsible for any changes made.

Community

Voting takes place amongst committers, on the developerlist, when it deals with changes in the code that are not bugfixes or part of a project. Project leaders and MMC members may call for votes to be cast regarding issues that deal outside their jurisdiction.

Calls for voting within the community are majority calls with a margin of 3 votes.

All calls are held on the MMBase developers mailinglist. Only committors are allowed to vote.

Note: a committor need not call a vote for submitting a bugfix, but a bugfix should be registered in the MMBase bugtracker so people can find sources of problems in older versions of MMBase.

Voting Process

Calls in the community are held on the developer malinglist.

These calls (as well as calls made on the MMC list) are resolved as follows:

The person who calls the vote sends an email to the list, indicating that it is a call for a vote by including CALL:<subject> in the subject header, with <subject> being a short description of the call.

The body of the message should contain the following set up:

CALL FOR:
<description of the call(required) >
 
LINKS:
<any link to sources, examples, documentation>
 
START OF CALL: <date voting starts>
END OF CALL: <date voting ends>
 
[_] +1 (YEA)
[_] +0 (ABSTAIN )
[_] -1 (NAY), because :
[_] VETO, because:


Committors have till the given end-of-call date to react. The person who makes the call cannot vote.

The end-of-vote date is by default three working days after the start-of-vote day (so a call on friday ends five days later, on wednesday). The duration of the call may be extended (but not shortened) by the person who made the call, or by a member of the MMC, to enable a sufficient number of committors to respond.

When reacting on a call, committors send a reply, quoting only the line that indicates their vote. The following votes can be made :

Possible votes:

• YEA (+1) : This counts as one positive vote. Any call needs at least one positive vote. Vote YEA if you believe the change will improve MMBase.
• ABSTAIN (+0) : This vote does not count towards the total. It does not cancel a positive vote but may affect outcome if the margin is not made. Vote ABSTAIN if you cannot decide whether the change is an improvement.
• NAY (-1): This counts as one negative vote.A negative vote cancels one positive vote, and may affect the outcome if the margin is not made. Vote NAY only if you believe the change will not improve MMBase, but if you are willing to resign to a majority vote. You need to explain why you vote NAY, and whether any change in the proposal will affect your vote. If you do not explain, your vote becomes an ABSTAIN.
• VETO : this is a veto, and means you will not accept the change. You need to explain why you VETO, and whether any change in the proposal will affect that vote. If you do not explain, your vote becomes an ABSTAIN. If the explanation is sound and there is no posibility of changing the proposal, the call fails, regardless of the number of positive votes.

  A VETO means you find the call unacceptable, to a degree that you end the call regardless of other people's opinions. A VETO states that other people have no need to vote any more. The call is over. The problem you found is simply too serious.

  As such, when you are not sure, you should not VETO. If you think that your vote might become a VETO (but you're not sure yet), give a negative vote with a warning that it may become a VETO, OR petition the MMC or the person making the call to hold the call until you have made up your mind. Casting a VETO which you later withdraw means you give other people no chance to vote

  Casting a VETO without sufficient motivation is a violation of the committor rules, and will be cause for a warning. A committor who abuses his rights and gets three warnings may loose his committor status (see Loosing Committor Status).

  A VETO should not be used if the intention of a call is unclear, for that, petition for a hold (see below). If the person making the call repeatedly refuses to explain or document his change, or refuses to provide sources, if needed, and if a request to hold the call is not honored, you may resort to a VETO, but only as a last resort. Whimsically using a VETO to stop a call because you do not at first understand the ramifications is, as written above, a violation of the rules.

• PETITION: If there is a lack of explanation or resources, or if you need a period of debate to help you determine your vote, you can petition either the personn making the call or the MMC to hold the call until full explanation is given. Holding a call means it will not be resolved until it has been satisfactory discussed. This gives you the chance to make a informed choice without the three day limit time pressure. You can still vote when a call is put on hold.

  Petitioning is not included as an option in the default Call form, but you can petition at any time you feel inadequately informed.

The eventual result of a call is determined by the type of call.

Most votes are majority calls, but the MMC may use more restrictive calls for important issues.

The counting of the votes is performed by one of the MMC members (designated by the MMC).

Types of Calls

• Majority call : A majority call is determined by tallying the positive votes and subtracting the negative votes and comparing the result with the margin of the call.

  Unless specified otherwise, majority calls have a margin of three votes. This means that for the vote to succeed, the positive votes need to outrank the negative votes by three votes.

  If this margin is not made, or if someone casts a VETO, the vote fails. If the vote fails because the margin was not made and not everyone had voted in time, the call may be extended.

• Unanimous non-negative call: All votes need be positive (YEA) or abstained.

  The call always has a margin of 3 positive votes.

  The call fails is someone casts a negative vote or a veto, or if the margin is not made.

• Unanimous positive call: All votes need be positive (YEA).

  The call fails if someone abstains, or casts a negative vote or a veto.

  This call requires that everyone votes, and is only used by the MMC when expulsion of a member is called for.