Project Management Committee archive

From ADempiere
Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.

This document is outdated - a new concept for the PMC Head was voted - and a new structure for the PMC is being worked


This is to document and outline the proposed role and responsibilities of the ADempiere Project Management Committee. If adopted, the PMC will replace the present Commit Committee and should also oversee the admin role before this by the Council.


The Project Management Committee (PMC) is comprised of experienced technical and functional resources within the bazaar. They work together to protect the stability and dynamic growth of the project. The PMC takes a largely tactical role in making sure the processes of development and contributions runs smoothly. Their foremost responsibility is to protect the stability of the trunk.

The PMC will include functional experts, implementors and also key developers of the project.


  • Protect the stability of the trunk
  • Provide guidance and direction for functional and technical development
  • Serve as liaison with end users from the community to promote further enhancements and testing
  • Help the project operate effectively by providing leadership, removing obstacles, solving problems, and resolving conflicts
  • Ensure that additional functionality is discussed and reviewed appropriately from both a functional and technical standpoint


  • Manage the Roadmap
  • Coordinate the Release schedule
  • Manage the committer layer mentoring process
  • Schedule and conduct a regular triage session on IRC as a channel for people to escalate and also to discuss their patch or feature request
  • Define architecture for new developments
  • Establish the development processes and infrastructure needed for the development team to be effective
  • Produce “how to get involved” guidelines to help new potential contributors get started
  • Facilitating code or other donations by individuals or companies
  • Working with Committers to ensure in-bound contributions are made in accordance with the ADempiere IP Policy.
  • Establish rules and guidelines for QA
  • Manage guidelines for trunk access control
  • Maintain branch rules
  • encourage and breed more skilled developers
  • Manage release policies for:
    • New features under development
    • high risk bug fixes
    • high risk enhancements
    • experimental stuff
  • oversee merging proven stuff from branch into trunk
  • Implement rules on the commit of new code into trunk. Some of the measurements might include:
    • Unit testing
    • Peer review
    • Detail test case or scenario
    • Contribution is Fully Documented
  • reverting when something goes wrong

Member Guidelines

  • In the unlikely event that a member of the PMC becomes disruptive to the process or ceases to contribute for an extended period, the member may be removed by unanimous vote of remaining PMC members. PMC members may resign at any time by delivering notice of their resignation to the PMC Lead.
  • The work of the PMC is shared by the PMC members. All PMC members are expected to contribute actively.
  • Active participation in the user newsgroups and the appropriate developer mailing lists is a responsibility of all PMC members, and is critical to the success of the Project. PMC members are required to monitor the main Project mailing list, and the developer mailing lists


CC Meeting Discussion

PMC Head Nomination

Collaboration Policy

Open meeting on Adempiere's extension policy, 5th Nov. 2008

See Also

Committee Proposal

This is a draft proposal to improve the speed and quality of the decision-making of the ADempiere community. It is based on the concept of using functional representatives to make decisions on behalf of the greater community. I propose the following steps:

1. Establish small groups to represent major functional areas (suggested list below)

    • The groups will be empowered to represent related functionality, suggest improvements, and can recommend functionality to move to the trunk
    • They should plan to meet regularly to discuss issues and build a good working relationship

2. Gather 3-5 members for each group

    • The members should be volunteers, willing and interested in investing their time and energy to fulfill their responsibility.
    • After volunteering, the members can be voted on by the community. Thus community puts trust in their representatives, and can continue to influence their decision making via the forums.

3. Each group selects 1 member to represent them on a Project Management Committee (PMC).

    • The representatives will take major issues to the PMC, and help to keep the overall initiatives coordinated.
    • The PMC will be responsible to maintain a published roadmap, release schedules, and to manage Best Practices, Committers List, and review contributions to be integrated.
    • The PMC should plan to meet regularly to discuss issues and build a good working relationship

4. The PMC will select a chairman, who will become the project lead.

    • Per Colin's post, I'd like to see this principle applied: "In short I think we need a manager rather than a techie!"

5. Review group membership after six months and adjust as necessary.

Suggested Groups

The following are proposed groups to represent project interests. I've taken the liberty of adding some names that I think would be representative of the kinds of people that should be on the group (don't be offended if I didn't include you, these are just examples! If you qualify and are willing, please add your name!). But membership will carry responsibility, so people should volunteer themselves by adding their own names to the lists. I don't see any problem with one person being on multiple groups if they are willing to make the investment. The volunteers can then be formally voted in by the community.

Financials SubGroup (Mike Judd, Steven Sackett, Carlos Ruiz, Armen Rizal)

This group will monitor changes to be sure good accounting principles are followed, and will make recommendations for moving the financial structure ahead to match new standards, etc.

  • < put your name here as volunteer 1! >
  • < name of volunteer 2 >
  • < etc >

Technical Infrastructure SubGroup (Heng Sin Low, Carlos Ruiz, Paul Bowden, Teo Sarca, Trifon Trifonov, Karsten Thiemann)

This group will monitor the stability of the technical infrastructure of the application, such as Swing, ZK, JBoss, Application Dictionary, system utilities, coding standards, System Parameters, etc. Can make recommendations for future platform improvements. This team could also monitor and manage the committers list.

Manufacturing SubGroup (Victor Perez, Teo Sarca)

This group will monitor and advance the interests of the manufacturing module.

General Usability SubGroup (Redhuan, Colin Rooney, Joel Stangeland, Mario Calderon)

This group will pay attention and review changes to general functionality, addressing issues such as how the cash journal should work, how to generalize the standard print format header, stuff like that. Backward compatibility will be a primary responsibility. Ideally, this group would institute and manage QA guidelines and automated testing.

  • Joel Stangeland