Functional Specification Process

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

Functional Specification Process

This page explains how to contribute a development, or suggest a new development to be included in branches/globalqss/adempiere361 branch (same process can be applied to other branches if necessary).

Definition of Branch Maintainers: company or people maintaining the branch, for the specific case of branches/globalqss/adempiere361 branch, this is being maintained by GlobalQSS company, led by Carlos Ruiz.

This process can be summarized as:

  1. Document
  2. Community discussion
  3. Decision to include by Branch Maintainers

Document the proposed change

Firstly you need to document the proposed change following the 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 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 Functional/Technical Committee

The final document must be presented to community. A functional/technical Commitee can conduct internal or external discussion, intended to end in a voting process.

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).

Decision

Branch Maintainers reserve the right to veto the decision to include the functional specification (voted by Commitee), in such case the veto must be properly sustained.

What's next

If the proposer can provide the code to implement the proposal, Branch Maintainers will add a task to the backlog to peer review and integrate the code. A team defined by Branch Maintainers will prioritize the backlog.

Proposal in backlog

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

Any development effort must be peer reviewed and pass QA from Branch Maintainers to be integrated into release.

Development process

Check the Proposal Development Process page