PMC Structure
Contents
ABSTRACT
This document is intended to establish a proper structure for the Project Management Committee to help ADempiere evolve in an organized fashion.
MOTIVATION
Pursuing the mandate of the PMC Head Concept, the PMC Head is proposing here a structure for the PMC.
MAINTENANCE OF THE DOCUMENT
The official maintainer of this document is the PMC Head (at this moment Carlos Ruiz).
This proposal is being released as an initial draft to spark a discussion and obtain an agreed final document.
Please discuss changes on this document (unless it's just style improvements) on forums or discussion tab here.
GROUPS
Project Management Committee will be divided in the following groups – this structure is not static, we can add more groups, subgroups, managers, etc, according to the project needs.
Release Management Group
Role of this team will be advise, help, and work on the release strategy.
An initial draft of release strategy to work on (to be discussed and defined in detail by community and this group) is:
- ADempiere moves to a time based release strategy
- Every four months a new release is taken from /release repository (goal of three releases per year)
- Status of the release will be determined by the Quality Assurance work done on the release, the goal is to have stable releases, this goal will be accomplished when we finish the set up of automated tests.
- Every year we release a LTS version, this version will be maintained (big bugs fixed) at least by two years (at this moment this is just a wish, this will be possible depending on resources)
- Bugs will be fixed on /release and every branch maintainer must take care of propagate it to branches (including experimental trunk), and LTS maintainers must take care of review if the bug needs to be fixed in their LTS version
- New functionalities must be added firstly on a branch (or experimental trunk)
- There must be a process to chose functionalities from branches to include in /release, this process will be based on:
- Roadmap (if any, depending on the resources)
- Wishlist (consisting of most voted missing functionalities on community)
- New functionalities – sponsored or not
- Completeness of functionalities (a functionality to enter in /release must accomplish all the Strict and Bearable rules defined in Release Commit Rules. It's encouraged to implement a checklist on the specification documentation
To achieve properly a time based release is important to have a modular architecture, so, opinion from this group must be asked when talking about modularization.
This group will be responsible also to define the strategy about what to do periodically with things in experimental trunk that won't reach release repository because its incompleteness. (Probably we'll need to recreate experimental trunk from time to time to keep it in sync with /release, the best strategy needs to be studied further by this group)
This group will be responsible also to implement the longly unattended proposal (my proposal since day zero) to make contributors sign a Contributor Agreement - the document will be discussed and proposed to the whole community, and after that this group will be responsible to check the diligence of this process. This is intended to protect IP beyond the protection that GPL gives us.
This group will be responsible also to define and maintain the procedures to:
- release a version
- chose functionalities to be included
- manage the roadmap (sponsored) and wishlist (voted)
The group can be composed by several persons helping with inherent tasks, it's proposed this group to have a leader: Release Officer
Architecture
Role of this team is to help in defining the options with most benefit for ADempiere project - taking care that initial definitions must not be too specific that discourage innovation from other parties.
An initial draft of architecture to work on (to be discussed and defined in detail by community and this group) is:
Adempiere will tend to a light extensible architecture trying to move to a light kernel with modules developed as extensions. This will imply moving the core, the kernel probably must become something like a message middleware between modules. This is a long-term goal.
Architecture team must act like a "Research and Development" R&D team for Adempiere.
This group is in charge also of the definition of the format and requirements of technical documentation, procedures to develop, conventions, code style, and everything related to development and committing.
The group can be composed by several persons helping with inherent tasks, it's proposed this group to have a leader: System Architect
Functional
This group must be composed by specialists, and it's the group that mostly will tend to have subdivisions growing and changing in time.
Probably we'll have initially a few groups and it will be divided in sub-groups and sub-sub-groups meanwhile we keep capturing more volunteers.
Probably this group will evolve also to be subdivided by industry-specific sectors, and in the case of localizations probably this group will evolve also to have subgroups on groups of countries.
This group must also be in charge of reviewing the accuracy of the documentation provided by the documentation group.
The group can be composed by several persons helping with inherent tasks, it's proposed this group to have a leader: Functional Leader. Eventually each subgroup can have a leader also.
I would propose to discuss about subdivisions based on the people volunteering.
Development (and technical documentation)
There are three kind of developers in ADempiere:
- Branch committer - committers with permission to work on a specific branch or folder (i.e. localization maintainers, non-official extension maintainers). Each branch will define its own rules.
- Trunk committer – due to the experimental nature of this branch it follows some agreed rules like a community owned branch (this is, there is no specific owner for this branch to set the rules, so rules must be set up by community). Actually rules and best practices have been expressed and documented (and some agreed) in these pages:
- Release committer - committers with acces to the release repository. At this moment all committers with permission for experimental trunk have access to release repository (this can change in future, a release committer can lose his/her credentials if repeatedly break the commit rules). To commit in /release repository just need to follow the rules expressed in the page:
The main goal of release committers on release branch is to make peer review on contributions from community, via patches, contributions, or via merge-commits on other branches or even in other projects.
Release committers will be also in charge to validate the completeness of the functional specifications and advice and guide contributors to complete the development.
Developers will be in charge also of writing technical documentation.
It's also encouraged that companies provide partial (or full) time developers for ADempiere – and companies could ask PMC Head to manage them allowing PMC Head to assign them specific tasks. Having committed sponsored resources can help to have a specific roadmap and dates.
This group can have (if there are volunteers) the following specific roles (additionally from being developers):
- Patch Manager: a role to administer the different patches contributed in branches, trackers, or any medium of contribution. Checking the status of patches and avoiding they are totally forgotten or unattended.
- Module Maintainer or Official Extension Maintainer: if we increase modularity then developers can apply to become specific module maintainers
- Localization Maintainer: its encouraged that each country have a maintainer.
- LTS Maintainer: we also need maintainers to integrate bug fixing (and solve them in some cases) for long term supported versions.
QA
The role of this team is to foster the creation and documentation of test code, test data, test scenarios, and test automation.
This group is also in charge to define and conduct tests and quality assurance - promoting the usage of the test tools currently available (fitnesse, junit), and check other potential tools that will help to automate tests (like webtest, selenium)
This group is also in charge of defining the label (status) of a release (i.e. alpha, beta, release candidate, production ready)
This group can be composed of several people, it's proposed this group to have a leader: QA Leader.
It's also encouraged to have a specific role (it can be a different person than QA Leader) on the project for Issue Manager. This role must be in charge of checking and administering trackers (specially bugs and feature requests)
Usability
This group is in charge to define usability guidelines for ADempiere User Interface, and review contributions from the point of view of usability, for example position of fields, tabs, bloating of windows, shortcuts, keyboard usability, etc.
Translations (and native english interface) will be considered also part of the scope of this group.
This group can be composed of several people, it's proposed this group to have a leader: Usability Leader.
There can be also Translation Maintainers, preferably there must be two maintainers per language.
Security
This group is in charge to define security guidelines for ADempiere User Interface, and review contributions from the point of view of security, for example avoid exposing sensitive data, prevent bad usage of non-technical skilled users.
Its expected this group research and execute also security tests.
This group can be composed of several people, it's proposed this group to have a leader: Security Leader.
It's proposed to setup a private list at security@adempiere.com – managed by Security Leader, just known people with at least 1 year of history on ADempiere can subscribe to such list. This list is intended to receive reports on security vulnerabilities.
The process of working on security vulnerabilities will be defined by this group, an initial draft to work on can be taken from http://producingoss.com/en/publicity.html#security
Functional Documentation
This group is in charge of defining guidelines to write functional documentation, writing and maintaining it.
Its encouraged to define several roles here for:
- FAQ Manager: to create and maintain a FAQ – reviewing forums, mail-lists, IRC logs, and all communication channels, and organizing topics frequently visited.
- Wiki Officer: this role (leader of a subgroup of wiki editors) will be in charge to organize, clean and maintain wiki. Create and maintain functional documentation. It needs to work closely with the functional team.
Applying for a group or role
All groups are open for anybody wanting to participate - just let PMC Head know your intention to participate and we can have a chat about.
Most probable is that some groups will be filled easily, and others will keep empty meanwhile new contributors arrive - I as PMC Head will try to fulfill the roles on the empty groups meanwhile more people come to participate.
Required availability
To apply to one of the roles proposed on this document you need to have some commitment to achieve the functions of the role (and initially as pioneer help to set up and define better the role).
What is mostly expected from these roles:
- Release Officer
- System Architect
- Functional Leader
- Subgroup Functional Leader
- Security Leader
- Usability Leader
- Module Maintainer
- Localization Maintainer
- LTS Maintainer
is to be available to support and answer community questions on their areas, help with specifications review.
PMC Head must be able to contact them via e-mail (and/or an instant messaging tool if possible for quick questions) – answers are not expected to be immediate or very quick – but some degree of accessibility and answer is necessary in order to keep things rolling at a good pace.
Forum communication will be the preferred way to contact key people, IRC second, e-mail third, and finally instant messaging. I'm careful about not abusing people on instant messaging - even I think a lot before sending a direct e-mail instead of using forums, but I guess sporadically we would need to do a quick contact to each other. Normally I start any skype chat with an "Are you available for a X minutes chat?" message - and I'm totally OK when people don't answer the question (they're not) - or answer negatively.
Date: January 25 of 2010
Author: Carlos Ruiz – acting as PMC Head
