View source for FS Process

= Functional Specification Process (Proposal in Review) =

This process can be summarized as:
# Document
# Community discussion
# 1st round - PMC functional voting
# 2nd round - whole PMC voting

== Document the proposed change ==

Firstly you need to document the proposed change following the [[FS_Template|Functional Specification Template]] provided for this.  You can find samples of this document on the [[:Category:Functional_Specification]]

== Open community discussion ==

You must announce the opening of the discussion for the proposed change in the [http://sourceforge.net/projects/adempiere/forums/forum/611163 Functional-ERP] sourceforge forums.

This is a necessary step and you must provide one week for community discussion on the proposal, you can receive comments about the proposal on the forum thread or on the talk wiki page of the proposal.

It is important you follow the comments and try to provide answers when required, refining the document for better understanding when necessary.

At the end of the open community discussion week you are allowed to integrate the changes proposed by community to provide a final proposal (you can also dismiss changes proposed by community without the need to provide a reason for that - it's encouraged to document the dismissed important or valuable changes in the "Open Discussion Items" of the document)

== Presenting the final document to the PMC Functional Group ==

The final document must be presented to the PMC Functional Group, they can conduct internal or external discussion and PMC Functional members must vote for the inclusion of the proposal within one week.

For a proposal to be approved by PMC Functional Group it requires >75% of the votes.

PMC Functional Group is composed by experts on each subject, when no experts on the subject are available in PMC then an external assesment can be asked and votation can take place on the external body.

Negative votes must be sustained - explaining the cause of the negative vote (intended to allow the proposer to fix the problem and present the document again in future).

PMC Head and PMC Functional Group Leader will establish rules to achieve voice and vote rights on PMC Functional Group, and the number of seats available for each group or subgroup.

The minority that voted negatively can present to PMC Head a document exposing the motivations and asking PMC Head to veto the proposal.

== PMC voting ==

The proposals approved by PMC Functional Group will be passed to a new round of votes to the whole PMC including all leader groups, this is: PMC Head, Architectural, Release, Functional (again), QA, Usability, Security and Documentation leaders will vote, a proposal requires 6 of the 8 votes to pass to the next phase.

Negative votes must be sustained - explaining the cause of the negative vote.

PMC Head has veto power for a proposal - explaining the cause for the veto.

The minority that voted negatively can present to PMC Head a document exposing the motivations and asking PMC Head to veto the proposal.

== What's next ==

=== Sponsored Development ===

If the proposer can provide the code to implement the proposal PMC will add a task to the backlog to peer review and integrate the code (after QA passed).  A committee conformed by PMC Head, Functional Leader and Architecture Leader will prioritize the backlog.

=== Proposal in backlog ===

If the proposal doesn't have code PMC will add the specification to the backlog and it will try to find sponsorship from foundations, community and implementors to implement it.

Any development effort (internal or external to PMC) must be peer reviewed and pass QA to be integrated into release.

== Development process ==

Check the [[Development Process]] page