Release Process

There are two levels of feature acceptance/tracking:

• Feature proposal & acceptance
• Minor feature tracking & bug fixes

Feature proposal & acceptance:

New proposals

Proposals are tracked with a FeatureProposal. A proposal must have the following defined to be covered by this process.

• The topic must be created in this web
• The topic must have the form ChangeProposalForm
• The topic must have a name in the field CommittedDeveloper and it is either yourself or someone that has agreed to help you getting the proposal implemented.
• The topic must have the field DateOfCommitment defined. It must be the day that the committed developer puts his name in the CommittedDeveloper field. You cannot put a date in the past assuming people have read the proposal.
• CurrentState field always starts at UnderInvestigation.
• Indicate which release your proposal is for in the PlannedFor field. If you are not sure pick the first coming release.

Acceptance/Rejection Process

A proposal can be accepted 3 ways

• Accepted by default after 14 days (TheFourteenDaysRule) without anyone having raised concern against the proposal.
• Accepted by consensus in the proposal topic. Consensus cannot be declared until the 14-days have passed. Consensus is typically declared after all that raised concern are satisfied with the answers they got or the proposal has been changed so all agree it is good.
• Accepted by community vote. This is used when someone has raised concern and no agreement can be made.

A proposal can be rejected

• Rejected by consensus in the proposal topic
• Rejected by community vote
• Pulled back by proposer

A proposal can be postposed to a later release

• By the ReleaseTaskTeam.
  • Because the next release is a patch release where only bug fixes are allowed as general rule
  • Because we have passed an agreed code freeze or string freeze close to a release
• By discussion on the topic
• By community decision in connection with an update of the project Roadmap

The workflow for acceptance or rejection is

14-day rule

• Feature proposals with a committed developer are accepted by default after 2 week/14 days (TheFourteenDaysRule) grace period (that is, no negative feedback/concerns means green light).
  • The 2 week/14 days grace period starts from the minute a developer commits to implementing the feature. I.e. when the CommittedDeveloper and DateOfCommitment are set with valid name and date. The clock stops the minute anyone with edit access to Foswiki.org puts their name in the ConcernRaisedBy field.
  • The community should regularly follow what new proposals are open on NewFeatureProposals which lists both the topics where the 14-day rule applies and topics with concern raised.
  • Proposals must be in the CommittedDeveloper and DateOfCommitment state for the full 14-days before consensus can be declared, even if many community members give positive feedback. This rule ensures that community member can go away on travel for a week and come back and still have a chance to raise concern if a proposal has a problem.

Concern

• Anyone can voice a concern on a feature proposal. This is done by adding your name to the ConcernRaisedBy and describing your concern in the topic discussion.

Consensus

• If the concerns are addressed and everybody agrees at the end, we have a ConsensusReached acceptance and no release meeting decision is needed. As a general rule it is the Customer Advocates who identify when a consensus is reached and change the state of the CurrentState field. Consensus cannot be declared until the 14-day grace period has expired.

Community Vote Decision

• Community vote is used when concern has been raised and consensus cannot be reached and other community members indicate that they would like the proposal passed.
• Community vote is open to anyone with access to foswiki.org.
• Community vote is done on the proposal topic by adding a simple table at the top of the proposal topic just below the proposal text. The table is a simple table of name and decision

Name	Yes/No
KennethLavrsen	Yes

• The vote must be a simple yes/no vote. If there are additional proposals these need to be raised as new feature proposals and voted separately. Ask the Customer Advocate for assistance if you have a doubt about this.
• The vote is announced on the foswiki-discuss@lists.foswiki.org mailing list
• The community must be given 7 days to give their vote.
• The proposal cannot be altered during the 7-day period.
• Votes like "Yes, but only if..." are invalid. It is yes or no. If you have doubt vote 'no'
• You must vote yourself. You cannot vote for others. And you cannot vote anonymously.
• If the proposal is rejected the proposer is allowed to alter the proposal and bring it through a new decision cycle.

Acceptance and further work-flow

• Accepted features are first put in CurrentState = AcceptedProposal. The ReasonForDecision field is set.
• If the feature was accepted at community vote the votes are left in the proposal topic so all can see how it was passed and who voted.
• The developer now takes the proposal topic to the state UnderConstruction and when it is fully implemented to the state MergedToCore. If the proposal does not affect core code or any of the default distribution extensions the end state is ImplementedAsExtension.
• Accepted features need to be tracked as a Bugs items. Please use the BugTracking field with the format [[Tasks.Item####]].
• As the normal rule only accepted features should be checked in.
  • As an exception "no-brainer" proposals and proposals that immediately get positive feedback can be checked in before a decision is made but you must then be prepared to revert the checkin if the community decides against the proposal later. The 14-day rule is there to ensure the community has a chance to evaluate proposals. It is not meant to be a delaying factor for obvious no-brainer proposals.

Rejection

• Rejected features are put in the state RejectedProposal
• The ReasonForDecision field is filled out.
• The CustomerAdvocate adds a small text at the bottom giving a brief explanation how and why the proposal was rejected.
• A rejected proposal can be altered and put back in UnderInvestigation state for a new process. The 14-day rule does not apply in this case. A rejection is seen as concern having been raised already.
• A rejected proposal may instead be implemented as a non-default extension. For tracking the developer can change the state to ImplementedAsExtension. By keeping the ReasonForDecision field unchanged we can still see that it is a proposal that was rejected for core or default plugin implementation.

Parked Features

• If a proposal does not have a committed developer or concern has been raised and it is obvious that the community has lost interest in the proposal for a long period the customer advocate will put the proposal in ParkedProposal state. This is to ensure that the community focus is on proposals that have a chance to actually happen. The proposer is then welcome to re-activate it back and pick up the discussion again.
• If a proposal has had a committed developer and the developer no longer wish to persue it, then the proposal gets parked. If the proposal had already been accepted anyone can pick it up and implement it.
• If a proposal is parked and never had a commited developer assigned and and therefore never treated as a proposal that follows this process, a developer can put it in UnderInvestigation, add their name to the CommittedDeveloper field and today's date in DateOfCommitment. The 14-day clock then starts ticking from this date.

Feature tracking of minor enhancements and bug fixes

• Are tracked in Tasks web
• No process needed to get item accepted
• Bug fixes and minor enhancements can be checked in once work is completed (but please provide test case)
• All new features that impact the spec or enhance the product considerably need to follow the "Feature proposal & acceptance process").
• Code refactorings that do not affect API or functionality does not need to go through a feature proposal. Just track it with a bug item.

Release meetings

• Note that the term "release meeting" is no longer a formal part of this process. It turned out to be too difficult with developers in all parts of the world. Instead we now arrange community votes that you can be part of no matter where you are.

Building a Release

See BuildingARelease