Helma Logo
main list history
previous version  overview  next version

Version 2 by hannes on 10. October 2006, 16:51

The Helma Project is, at the time of this writing, not a legally established entity. We are a free-formed group of people sharing a common set of visions and goals. This document describes these goals and the rules and structure by which we hope to achieve them. <b>This document has draft status.</b>

=== 1. Helma Project Goals ===

The fundamental goals of the Helma project are:

* to be a well-respected and acknoledged open source software project.
* to provide an efficient and transparent environment for software development.
* to create software tools that are easy and intuitive to learn and use.

The aim of the organisational structure described in this document is to make sure that:

* development efforts and software releases are aligned with our above goals.
* decisions about development directions and project releases are made in a transparent way.
* responsabilities for various areas are clearly assigned to and accepted by the project members.

=== 2. Modules and Maintainers ===

The Helma project is divided into modules. Modules are guided by maintainers in cooperation with outside contributors and the module's user base.

At any given time, a Helma module must have at least one maintainer. Larger or more active modules may require more than one maintainer. The number of maintainers for a module will depend on the supply of people willing to accept the role, the breadth of the module's scope, and the disposition of the existing maintainer(s) to share the work. The only requirement as far as this document is concerned is that any Helma module must have at least one person committed to helping the module grow.

==== 2.1 Maintainer duties and responsabilities

How a maintainer job is carried out will differ widely among people and modules. It is beyond the scope of this document to prescribe what amount of hacking, researching, code reviewing, communicating etc. a maintainer should do. But one thing that is important is that maintainers do not dig into their own work in a way that people outside the module (or even other people within the same module) lose track of where the module is going and what the maintainer is currently working on. A maintainer should keep some balance between his or her internal work and communicating the work with others inside and outside the module.

Ideally, a maintainer should create a sense of community around the module, and to encourage outside people to become active on the work on the module in one way or another. The proposition should be to offer people different levels of interaction with the module, from plain, passive users to active contributors or co-maintainers.

We do not want to impose too many administrational obstacles when trying to recruite new maintainers for a module. If the existing maintainership of a module decides it wants to grow, it should be able to recruite the most appropriate and inclined person from the module's environment. Similarly, stepping down from the maintainer job should be a low-key and amicable event between the one leaving and those remaining. Only in exceptional cases should the Helma committee intervene in maintainership questions.

The main requirement here is that defunct maintainerships eventually should be reflected in the module's official maintainer list. In other words, there shouldn't be any honorary or nominal maitainers, at least not for extended periods of time.

==== 2.2 Spawning of new modules

There are several ways a new Helma module may come into life. The two most important ones are contributions from outside developers, and spin-offs from existing modules.

Helma will offer a sandbox that will allow Helma insiders and newbies alike to share and propose new things and ideas. The sandbox will provide wiki space and code repositories with little or no administration overhead. If a sandbox project gains traction and is deemed worthy of being part of official Helma code, it can either spawn a new Helma module, or be absorbed into an existing one.

New modules can also be created as spin-offs from existing ones. This is especially important as existing modules should not be diluted by stretching the module's scope too far. If some new part evolves from a module that is not strictly contained within the original module definition, a new module should be spawned, or the new part should be "parked" in the sandbox.

=== 3. The Helma Committee ===

The Helma Committee (just called "committee" for short) is the main decision making body of the Helma project. The mission of the Helma committee is to decide on the roadmap for future releases of Helma software, establish new modules and discontinue old ones, appoint module's main/initial maintainers, and make sure that development is consistent with the goals of the module and the entire Helma project.

In detail, the mission of the Helma committee includes but is not limited to the following tasks:

* Setting up the roadmap for future Helma software releases
* Installing new modules and appointing initial module maintainers
* Abandoning modules that have become obsolete or stale

==== 3.1 Voting

Decisions in the committee are made by simple majority, except for the following tasks:

* Installing and abandoning modules
* Appointing and dismissing committee members
* Changing the Helma project rules

These tasks require an absolute majority if the commitee consists of seven or less persons, or a two-third majority if the committee consists of more than seven persons.

==== 3.2 Membership

The members of the Helma committee are selected by majority vote as described above from the pool of active maintainers of any Helma module. This means that an active maintainer role is a requirement for membership in the Helma Committe. The intention here is to make sure the committee consists of people with active, daily interest in Helma. As an exception to this rule, a person may remain committee member after he or she steps down from the role of module maintainer.

Committee members can resign either by their own decision, or by committee majority vote as described above.

It is possible for people or institutions playing a passive role in Helma development (e.g. endorsement or project funding) to participate in the Committee mailing list and meetings as guests, but without voting right.

The primary medium for discussion and voting within the Helma Committee will be a dedicated mailing list.  Additionally, yearly or semi-yearly meetings will be held in meatspace. These meetings will be held in the place that allows the most committee members to attend. Those who cannot attend may take part through VoIP or other similar means.

==== 3.3 Committee bootstrapping

The initial Helma committee will be composed during a bootstrapping phase in which the core Helma modules are established. The initial Helma committee will consist of those module maintainers who have the trust by others and the will to carry out this task.

     removed
     added