> > To all who are interested in feature proposal for 2.0.0,
> >
> > What's the progress on your proposal? =A0As 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:
> >
> > =A0- a revised presentation of proposal (if the proposal
> > =A0 =A0was changed during discussion),
> > =A0- a short summary of the past discussion (if any), and
> > =A0- a new material developping a future discussion.
> >
> > Unlike a bug report, a feature proposer has to take the
> > effort to get approval from matz. =A0It avails nothing to
> > wait. =A0Good luck!
>=20
> 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.
>=20
> 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 whet=
her a request is a good or bad idea.

By rejecting stalled feature ticket's he's bringing more, not less, attenti=
on 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 longe=
r feels strongly about the feature request, simply do nothing and the outda=
ted 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