Process for Managing TWiki Change Proposals
Note to developers:
The process below has been a good success for TWiki-4.1 and will evolve over time based on community needs.
- Customer focused
- Easy and quick to get new features accepted
- Some way of control to make sure we stay focused on mission, quality and performance
- Scalable (not too much workload on a single person)
Three levels of feature acceptance/tracking:
- Themes for release (aka release focus)
- Feature proposal & acceptance
- Minor feature tracking & bug fixes
Themes for release:
- Are decided in release meetings
- Are documented in release topic in Codev
Feature proposal & acceptance:
Figure below shows the work flow. Click on work flow boxes to jump to the supporting topic.
- In line with TWikiMission, usability standard and performance goal
- Feature concerns are resolved
A proposal can be accepted 3 ways
A proposal can be rejected in 2 ways
- Rejected by vote at release meeting
- Rejected by Technical Board veto
The workflow for acceptance or rejection is
- 7-day feedback period:
- Features proposals with a committed developer are accepted by default after a 7 day grace period (SevenDayFeedbackPeriod), that is, no feedback/concerns means green light.
- The 7 day 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.
- Anyone with edit access to twiki.org can raise a concern by puts their name in the ConcernRaisedBy field. Feature is accepted on the seventh day if there were no concerns, or if all concerns are resolved in time.
- The community should regularly follow what new proposals are open on NewFeatureProposals which lists both the topics where the 7-day grace period applies and topics with concern raised.
- 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.
- 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 that identifies when a consensus is reached and changes the state of the CurrentState field.
- It is allowed to raise concern just with the argument that the proposal has an importance that a release meeting decision should be made.
- Anything not in line with mission should be raised as concern so it can be discussed in release meeting.
- Release Meeting Decision
- Release meetings are held normally as biweekly meetings. Invitations are sent to the TWiki-Dev mailing list. Meeting is held on IRC in the #twiki_release channel.
- Anyone that shows up at the release meeting has the right to vote.
- Any feature request or code commit on SVN that goes against the TWikiMission can be vetoed by the technical board team representative.
- If a community member cannot participate in the meeting it is allowed to vote on the proposal topic.
- Acceptance and further work-flow
- Accepted features are first put in CurrentState = AcceptedProposal. The ReasonForDecision field is set.
- If the feature was accepted at a release meeting, a link to the meeting minutes topic is added to the RelatedTopics field. (It is OK also to use this field for any other releated topics)
- 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
- As the normal rule only accepted features should be checked in.
- As an exception "no-brainer" proposals 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. Normally it is advised to wait at least for the 7-day period to expire.
- Rejected features are put in the state RejectedProposal
- The ReasonForDecision field is filled out.
- A link to the meeting minutes topic is added to RelatedTopics field.
- A rejected proposal can be altered and put back in
UnderInvestigation state for a new process. The 7-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 his name to the CommittedDeveloper field and todays date in DateOfCommitment. The 7-day clock then starts ticking from this date.
- The purpose of the TWikiTechnicalBoard veto is to protect the TWikiMission
- The purpose of the veto is also to protect the project against hi-jack attempts. (Example 10 people from Evil Empire Co show up at a release meeting with a crazy proposal and outvote the regulars)
- Technical board members will vote "yes" and "no" to proposals just like anyone else. A "no" is not a veto.
- A technical board member shall use the right of veto only rarely.
- A technical board member shall only use the veto when the argument is that it goes against the TWikiMission (example, proposal will break a significant amount of existing TWiki Applications making upgrading totally impossible for existing customers, or proposal will change plugin API so a large number of existing plugins will stop working when you upgrade TWiki). A veto shall never be given because "I do not like it".
- A veto is never a final decision. It is en encouragement to "go back to the drawing board" and improve/alter the proposal. Improved proposals can be brought back to release meetings as many times as the proposer wants.
- A veto can also be in the shape "not in this release, but in next release".
- A single technical board member cannot block a proposal. A veto requires that TWO technical board members raise the veto.
Feature tracking of minor enhancements and bug fixes
- Are tracked in Bugs web as usual
- 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, enhance TWiki considerably, or are not in line with the mission need to be tracked in Codev and 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.
Purpose of release meetings
- Process improvements
- Decide on themes (release focus)
- Discuss and decide on features with concerns
- New feature proposals for the work-in-progress TWiki release code are shown at topic TWikiFeatureProposals
- Report shows all pending feature proposals, including feature concerns
- This URL can be sent to key customers (such as TWiki admin at Yahoo and Google), with goal to get customers more involved
Roles (defined for release process)
Role of release manager (minor/major releases MAIN branch)
- See ReleaseManagementTaskTeam for current assignment
- Coordinates build of release
- Freeze the release (before the first release candidate is built)
- Delegate responsibility when unavailable
Role of customer advocate:
- Monitor feature proposals.
- Ensure that the proposal has a committed driver that will implement it if accepted.
- Note if concern has been raised.
- Follow the discussions and see if consensus is reached.
- If discussion stops without a result decide try to trigger the community to end the discussion
- If no consensus is reached bring forward features with proposals to release meeting
Customer advocate role is to represent the customer
(the users and the admins). The idea of the role is not to be a decision maker. The customer advocate has no veto (unless he is also a technical team member). The customer advocate is not supposed to have opinions on all technical details or even supposed to understand them all. The role of the customer advocate is to ensure that those that raised concern are heard and that all proposals get a fair and fast treatment.
The customer advocate role is shared between 3-4 people. The required qualifications:
- Reasonable experience with TWiki as a user. Ie. knowing the features of TWiki pretty well and having made some simple TWiki applications.
- Very basic knowledge about what the TWiki plugin API and handlers are about. But it is not a requirement that you have actually programmed plugins yourself. You just need to understand what it is when someone suggests to change or add a function in Func or add a new plugin handler.
- Have a personal interest in seeing TWiki develop to a better product.
- It is an advantage if you are NOT a full time hard core programmer. We are more looking for admin types taking care of a user base or a very experienced "I love TWiki" user type.
Role of Patch Release Manager
- *See ReleaseManagementTaskTeam for current assignment
- Authorise fixes (patches, or inter-release update packages)
- Creates the builds as required
- When very severe bugs are found shortly after a release
- When a level 1 or 2 security issue is found that requires a fast release
- When the number of bugs has pilled up to a level that justifies a release
- Create upgrade package that can be applied to any previous release within same major/minor tree
- Upgrade package containing all files changes since last minor/major release (last decimal 0 in release number)
- Ensuring that upgrade package can be applied to a production site with almost no downtime to fix things.
- Excluding files that may have been updated but changes are not necessary and would make the upgrade less easy. Example: A help text in the TWikiUsers topic.
Idea of doing the patch releases is
- To provide our customers a more quick access and easier access to fixes of severe bugs
- To give the hard core developers time to focus on the next major or minor release instead of concerning themselves with patch releases. They know someone else pick up the important bugfixes.
TWiki Community Member Role
- Anyone with access to twiki.org has this role. All you have to do is login and start writing. Or show up at the biweekly release meetings on irc.freenode.net channel #twiki_release.
- Anyone has the right to raise concern about any proposal.
- Anyone has the right to participate in release meetings and give their vote
See also: TWikiMission
-- Contributors: PeterThoeny
Older discussions are available at revision 5
of this page.
- 15 Feb 2009
I would like to review the release process for quick and democratic decisions on feature proposals. I like the "accepted by vote on release meeting", but it should be applicable to any feature proposal (also within a 14 day window), and at the same time fair to the community. That is, I'd like to define the vote more clearly. Here is an idea, to be discussed: May be require x% of active contributors to vote on a feature. Such as: "A vote on a feature can be done at a release meeting if 33% of active core contributors vote, either at the release meeting or online in the feature proposal topic ahead of release meeting. An active core contributor is defined as a person who made at least 3 check-ins within 2 month to the core or core extensions."
- 15 Feb 2009
I've changed the release management process topic to bring it up to date with the framework of the TWikiGovernance
task team model.
Thanks George for proactively fixing the process docs!