Feature Proposal: The feature proposal process is more complex than required
Motivation
In
SupportDollarPercent I was chastised for making a change that, while not within the
letter of the feature proposal process, was (I felt) well within the
spirit. Specifically, I flipped an uncontentious feature proposal to "ConsensusReached" state, explaining that it looked like a no brainer.
ReleaseProcess says:
A proposal can be accepted 3 ways
* Accepted by default after 14 days (TheFourteenDaysRule)
* Accepted by consensus in the proposal topic
* Accepted by vote at release meeting
It also says:
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 that identifies when a consensus is reached
Since we have neither Release Meetings, nor formally identified Customer Advocates, it would seem reasonable that I should be able to identify myself as an advocate of customers (as should anyone else who represents a large customer base). If we cannot, the the "accepted by consensus" state can never happen, and the 14 day process is the
only way for a proposal to get accepted. IMHO that's reasonable, but we should either respect the feature process as it's written, or simplify it to clearly identify how it works.
Note that the
RejectedByCommunityVote decision has no documented process by which it can be reached.
Description and Documentation
On the assumption that we are not going to start having release meetings, nor are we going to identify customer advocates, I propose that we rewrite the feature proposal process as follows:
- Remove redundant CurrentState ReadyForReleaseMeeting
- Remove redundant ReasonForDecision states ConsensusReached, AcceptedByReleaseMeeting, and RejectedByReleaseMeeting
- (ReleaseProcess) Remove 2 of the 3 ways to leave only the 14 day process
- (ReleaseProcess) Remove references to Customer Advocates, Release Meetings
- (ReleaseProcess) Document how a community vote can be run, and how it can result in a decision on a proposal. If appropriate, add a!AcceptedByCommunityVote decision.
--
Contributors: CrawfordCurrie - 01 Mar 2010
Discussion
This is an obvious cleanup.
Let me recap. So the only way for a feature proposal to be accepted is via
AcceptedBy14DayRule. If there is a
ConcernRaisedBy somebody, the 14 days rule is suspended.
From that point on the proposal stays in
UnderInvestigation. Let's call this state "Blocked", a state property that is not listed in
CurrentState, but manifests itself as a combination
of the two others.
The only way out of Blocked is
- (a) concerns are addressed and revoked or
- (b) a proposal is rejected by a community vote or
- (c) a proposal is parked/abandoned, thus kept for reference.
From what I've seen in the past is that there are a lot of proposals that stay in Blocked state and neither of the three (a-b) events happen. This happens when
concerns have been addressed or been commented on but the person who added herself to
ConcernRaisedBy seems to have abandoned the discussion.
This rather unfortunate chain of events does happen rather frequently with good ideas and potential contributions getting lost. People do get lost in the
the Development Web, which turns out to be quite amorphous sometimes.
Can we somehow address this, now that we are about to simplify and cleanup the change proposal process? Does anybody share my observations?
--
MichaelDaum - 01 Mar 2010
Micha - I feel we should move your much more complex issue into a different proposal? That way we can discuss this 'simpler' issue, and resolve it, without having to resolve both at the same time - however, to answer your question: I worry about not quite sufficiently good proposals being pushed through with the excuse that the concern raiser might be away.
Crawford's proposed cleanup essentially formalizes the idea of slowing down feature proposals, to give everyone 14 days to comment before proceeding - which I support,
except that at the same time, I appreciated the approach taken my Crawford and
MichaelT with the
QUERY
and
HERE doc
proposals - where they committed code to trunk
before it was accepted. (and then removed if rejected / concerns are raised)
perhaps we can add language to give permissions to pre-de-stablise our trunk?
--
SvenDowideit - 01 Mar 2010
Agreed.
--
MichaelDaum - 01 Mar 2010
I do not understand the problem to be honest.
I - as a member of the community - come by Development web regularly and I always look at the Feature Proposals topic and I always look if there are new items in the 14-day queue.
I do not come by every day. I may be busy. I may be traveling. But within a 14 day period I visit this page at least twice. And most often several times per week.
It is the principle that if you look at least once every 14-days you have a chance to evaluate all proposed features.
The problem you created Crawford was that you changed the the status of the proposal so it ended up in the accepted proposals only after a few days. This means that many community member will never see it. I only saw it because I happened by chance to look at
WebChanges.
Even if you get 3 or 4 "+1" reactions the first day, it may still be that another community member has a good point that comes after a week. And that requires that he gets a chance to discover the proposal is there.
It is perfectly OK to work on the assumption that a proposal is accepted - as long as you are prepared to revert - in case the proposal is turned down.
All you have to do is leave the proposal in the
UnderInvestigation state. After the 14-days we put it in accepted.
The idea of the 14-day rule is to give people the 14-days to think and react. And if noone does - it is accepted. This forces us to be alert and take action. But it also gives us a reasonable time to see the proposal and react.
The idea of the
ConsensusReached state is that when someone raises concern and stops the 14-day auto-accept clock we continue discussing. And if the discussion ends up with noone being against, then we declare consensus. There is no point in spending time on a vote if noone voice opinion against.
If we cannot get to consensus we vote.
We used to vote at release meetings. But after we forked the votes have been in writing in the feature proposal and that has honestly worked much better than release meetings where people are voting either unprepared or could not be present due to timezones etc.
Yes, the process needs an update. And I can take that task. But please give us the 14-days to see and react before changing a proposal to accepted.
And keep on checking in proposals that you believe will be accepted or get immediate support. The 14-day rule should not be a delaying factor of nobrainer proposals.
--
KennethLavrsen - 01 Mar 2010
Note: in practice Kenneth's last comment here "keep on checking in proposals that you believe will be accepted or get immediate support" means you can
check in, but woe betide you if you don't observe the feature proposal process (i.e. 14 days even if it's checked in). See discussion at the end of
RemoveRedirectCGIQueryHandler.
--
CrawfordCurrie - 02 Apr 2010
This proposal has been stuck in under investigation for nearly 6 years. A victim of the process it's trying to fix?
I think that we've somewhat reached a stable process. We are having release meetings, but have not been pressed into voting on each proposal, so the 14 day process is somewhat working ... but only if everyone actually makes an effort to
read. The issue with merging into master aka trunk has hopefully disappeared, now that we are using and have a very easy method of branching and merging individual feature branches. Merging partial / experimental work into trunk pretty much demonstrated the chaos and disaster that it created as we struggled to get 1.2 / 2.0 released.
I'm setting this to an discarded proposal. It's hopefully history. If more changes to the process are needed, just reactivate it and set another date.
--
Main.GeorgeClark - 13 Feb 2016 - 21:17