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:

1. Remove redundant CurrentState ReadyForReleaseMeeting
2. Remove redundant ReasonForDecision states ConsensusReached, AcceptedByReleaseMeeting, and RejectedByReleaseMeeting
3. (ReleaseProcess) Remove 2 of the 3 ways to leave only the 14 day process
4. (ReleaseProcess) Remove references to Customer Advocates, Release Meetings
5. (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