Committers

This Wiki is read-only for reference purposes to avoid broken links.

In order to protect the trunk and trying to guarantee a better quality assurance (through peer review), as discussed in this thread the Commit Committee has changed to a layer of mentor/mentored committers:

MOTIVATIONS

First of all is important to note that motivation of this proposals for change initially sparked because of: "Commit committee can't cope with the review of all commits."

This issue have an important quality impact on the product we're trying to maintain.

So, the discussion from yesterday help us to explore other questions:

• How can we guarantee (I mean GUARANTEE) a peer review before commit?
• How can we grow the developer/committer community?
• How can we grow CC without losing quality?
• Where is the knowledge concentrated?
• How can we spread it?

The mentor-mentored levels are not about power, is about mentoring.

We're proposing here that every committer has the same rights, just that some developers (even very experienced) have a mentor when starting commits on the project to support them.

The mentorship can be many things depending on the needs of the mentored, i.e.: - Best practices on coding (i.e. indentation, etc) - ERP knowledge - Modifications on Adempiere since Compiere (i.e. for experienced Compiere developers starting to commit in Adempiere) - Architectural things - Evaluating collateral effects on commits - etc.

In this organization the idea is to have peer review for everybody, and "newbies" have a mentor to guide them.

Please take carefully the word "newbie". It doesn't mean newbie to coding, or newbie to Compiere.

It can mean: "newbie" on the commit policies, "newbie" on the construction of migration scripts, or "newbie" in Adempiere.

MEETINGS

Committers agreed to continue the Commit Committee meetings - now called Committers Meetings. Time: 15:00 GMT Day: Every Tuesday

NEEDED SKILLS

MENTOR LEVEL

1. . your code is good
2. . you understand the AD
3. . you know how to construct a migration script
4. . you need to look beyond the specific problem . This is analysis, design, and look if a proposal or code broke other parts of the system
5. . ERP knowledge
6. . Agreement to mentor/coach at least two (number to be reviewed according to workload) mentored committers
7. . Strong communication with community and functional reviewers via forums

MENTORED LEVEL

1. . Show good bug fixings (initially through patches)
2. . Try to review contributions from external developers and guide them on how to make it right (according to his own workload)
3. . In some cases we can have specialized mentored committer specific for some programs -> like Tim for 2pack

INCLUSION OF NEW MEMBERS

Please ask to be in if you think you have shown the skills to be in any level.

Because the most important skills are technical we think the team must be proposed and elected by technical people.

The idea is that anybody with the needed skills to be in can ask, or anybody else can propose him.

The votation will be done by current committers.

RULES FOR COMMIT AND ROLES FROM DIFFERENT LEVELS

• IN TRUNK just committers listed here have commit permissions.

• In branches the branch owner define the set of permissions.

• Branches will be allowed for experimental, or personal work. But the branch maintainer is responsible to keep it in sync, and construct the needed patches to be included in trunk. Pending to set up clear policies about branches.

• Any commit in trunk from external (non-committers) will be reverted without need of further explanation.

PROCEDURE TO COMMIT

We will have 2 levels of committers and external developers

The procedure depends where you are.

Although this organization is to guarantee AT LEAST one peer review, EVERYBODY is invited to review commits!!! More eyeballs are better.

EXTERNAL

• External developers must put a good patch and looks for some committer (level 1 or 2) to review
• Even bug fixing needs such mechanism

MENTORED

• If you're a mentored committer, then your mentor can guide you and review your patch

Mentored committers has total commit permissions and can commit on his own.

The idea is that his mentor guide and communicate with him. Very possibly (but not as an obligation) mentor is going to review the commit from his mentored-team.

Every mentor has a preferred way to communicate, so I think this is a personal preference that must be set by every mentor with his mentored-team. We encourage this communication to happen preferably in forums.

MENTOR

• If you're mentor committer then you must ask other committer (mentor or mentored) for peer review

TEAM

MENTORS

• Heng Sin Low *
• Teo Sarca *
• Karsten Thiemann *
• Trifon Trifonov **
• Victor Pérez *
• CarlosRuiz **
• Alejandro Falcone
• Colin Rooney

MENTORED

• Redhuan (Heng Sin)
• Bahman (Teo Sarca)
• Fer_luck (CarlosRuiz)
• Johannes (pending acceptance) (Karsten)
• Stefan Kuthan (voted + by Karsten,HengSin,Trifon,CarlosRuiz) (Trifon)
• Mark Ostermann (CarlosRuiz)
• Armen Rizal (Trifon)
• Tim (for 2pack) (Victor Perez)
• Robert Klein
• Paul-phib
• Ashley
• Tony tspc
• Bojana