Page History

Superceded (in part) by Committer's Zone policy of lazy consenus.  

FINERACT Is Currently A Top-Level Project In The Apache Software Foundation.

Find below our processes, which of course are subject to change

FINERACT is currently in incubation.  Many processes are not yet defined.  We will need to agree on initial processes and on how to change processes as our community needs evolve.

Bootstrapping the processes

1. All process documents are first written in confluence and marked as drafts.  A committer proposes the draft process for discussion on the dev mailing list.Once a proposer believes the discussion has concluded, the proposer puts the draft to a vote.
2. If within 72h there are no vetoes objections from committers, the process is accepted.  The draft notation is removed.
3. If there are vetoesobjections, the proposer and the originators of the vetoes objections discuss and adjust the proposal.  Return to step 1.

Changing the process

Once the a process exists, it may need to be evolved.  This is how

1. For small changes, the contributor who wishes to propose a change to the process writes a comment on the confluence page describing the desired diff.
2. For large changes, the contributor who wishes to propose a change to the process creates a child of the existing page with the new content and marks it at the top as a draft or change proposal.
3. The proposer then submits the proposed change to the dev mailing list for consideration.
4. Once the proposer believes the discussion has concluded, the proposer puts the draft to a vote.
5. If within 72h there are at least 3 votes from committers and no vetoes from committers, the change is accepted.  Vetoes require an explanation.  The change is made to the main document, and the draft is removed.
6. adjusts the documentation (if necessary) to reflect the consensus as he or she understands it. 
   later addition:  we have adopted lazy consensus see details on Committer's Zone
7. The proposer removes drafts and comments the documentation with any major findings still missing there.
8. The proposer notifies the rest of the community of any significant changes via the dev mailing list.  Insignificant changes require no notification – the proposer should apply his or her own discretionIf the change was not accepted, the proposer may either make adjustments based on the veto explanations and return to step 1, or drop the proposal.  Dropped proposals should be marked as dropped to avoid confusion.