[ruby-core:42402] Re: I'll reject stalled feature tickets

> > To all who are interested in feature proposal for 2.0.0,
> >
> > What's the progress on your proposal? s I showed the
> > 2.0.0 release plan in [ruby-core:40301], please conclude
> > discussion about your proposal by this August, if you
> > want to ensure the success of your proposal. (a half year
> > and a bit)
> >
> > To facilitate discussion and to make it easy our ticket
> > management task, I'm going to close feature tickets that
> > seem to have no progress.
> > If you are not happy with my rejection, feel free to
> > reopen it or create a new ticket, but please add:
> >
> >  a revised presentation of proposal (if the proposal
> > as changed during discussion),
> >  a short summary of the past discussion (if any), and
> >  a new material developping a future discussion.
> >
> > Unlike a bug report, a feature proposer has to take the
> > effort to get approval from matz. t avails nothing to
> > wait. ood luck!
> 
> Why are you rejecting them based solely on the fact that they haven't
> had any discussion in a while? That doesn't mean much of anything. I
> certainly doesn't mean they aren't necessary good ideas. It only means
> for sure that no one has had the time to work on and implement. And
> even if they are implemented, they can often just sit there b/c no one
> in core team has taken time to evaluate.
> 
> Instead of rejecting these, how about bumping them to higher versions.
> And only reject proposals on the basis of their merits.


Yusuke's plan is perfect, and nowhere did he make a value judgement on whether a request is a good or bad idea.

By rejecting stalled feature ticket's he's bringing more, not less, attention to the requests; there's nothing like rejection to get your attention.

Rejection also gives the author the opportunity to re-evaluate whether the feature still adds value given recent trunk changes. If the author no longer feels strongly about the feature request, simply do nothing and the outdated request doesn't linger and clog the ticket backlog. If the author still feels the request adds value, they get a fresh opportunity to advocate for change and discuss until August.

It's a good plan to separate the wheat from the chaff and manage risk to 2.0.0's release date.

Jon

---
Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat.
http://thecodeshop.github.com | http://jonforums.github.com/
twitter: @jonforums