MMBase guidelines |
|
Roles & ResponsibilitiesThe 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. UsersUsers 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). SponsorsSponsors 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. DevelopersDevelopers 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 rulesA 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 rulesAll 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. CommittersDevelopers 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 committerIn 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 statusCommitters 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):
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 rulesA 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 ResponsibilitiesThe 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 RulesA 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:
Project leader & membersA 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 documentationA 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:
Code documentationWhen 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 goal of the documentation is to enable all MMBase users (with the right skills) to use the new functionality. Hack RulesA 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:
A Hack needs to contain the following documentation:
The goal of the documentation is to enable all MMBase users (with the right skills) to use the new functionality. Bugfix RulesA 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). VotingWhen 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. MMCVoting 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. ProjectVoting 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. CommunityVoting 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 ProcessCalls 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 The body of the message should contain the following set up:
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:
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
|