I'll reject stalled feature tickets

(Japaneser later; $BF|K\8l$O8e$G(B)

To all who are interested in feature proposal for 2.0.0,

What’s the progress on your proposal? As 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
    was 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. It avails nothing to
wait. Good luck!

2.0.0 $B$X$N5!G=Ds0F$K6=L#$N$"$kJ}!9$X(B

$BDs0F$N?JD=$O$$$+$,$G$7$g$&$+!#(B[ruby-dev:44691] $B$K<($7$?(B
2.0.0 $B%j%j!<%9%W%i%s$NDL$j!“Ds0F$r3N<B$K:NBr$5$;$k$?$a$K$O!”(B
$B:#G/$N(B 8 $B7n$^$G$K5DO@$r$^$H$a$F$/$@$5$$!#(B($B$"$HLsH>G/$A$g$$(B)

$B5DO@$NB%?J$H%A%1%C%H4IM}$N8zN(2=$r?^$C$F!"?JE8$,8+$i$l$J$$(B
feature $B%A%1%C%H$r(B close $B$7$F$$$3$&$H;W$$$^$9!#(B
$BG<F@$G$-$J$1$l$P(B reopen $B$^$?$O?7%A%1%C%H$r:n@.$7$F9=$$$^$;$s(B
$B$,!"$=$N:]0J2<$rDI2C$7$F$/$@$5$$!#(B

  • $B2~D{HG$NDs0FFbMF(B ($B2a5n$N5DO@$NCf$GDs0F$,JQ$o$C$?>l9g(B)
  • $B$3$l$^$G$N5DO@$N$^$H$a(B ($B$"$l$P(B)
  • $B5DO@$r?JE8$5$;$k%M%?$r2?$+(B

$B%P%0Js9p$H0c$C$F5!G=$NMWK>$O!“Ds0F<T$,(B matz $B$N>5G’$rF@$kEXNO(B
$B$r$7$J$1$l$P$J$j$^$;$s!#BT$C$F$k$@$1$G$OOC$O?J$_$^$;$s$N$G!”(B
$B$,$s$P$C$F$/$@$5$$!#(B

2012/2/7 Yusuke E. [email protected]:

Unlike a bug report, a feature proposer has to take the
effort to get approval from matz. It avails nothing to
wait. Good 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.

Hello,

2012/2/7 Trans [email protected]:

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.

Jon explained my intention well.

Instead of rejecting these, how about bumping them to higher versions.

I believe it will make no one happy. Leaving the tickets open will
give OP a (false) comfort, “my proposal might be accepted in future.”
But in fact, the possibility is extremely low unless OP or anyone makes
a move.

Even so, do you really want to leave them open? If many people agree
with Trans, I’ll create a new tracker, e.g., “difficult feature
tracker”,
and move such tickets to it. But again, I truly believe that it will
make no one happy.

I’m sorry for those who have suggested many interesting proposals, such
as you and Roger. I wish matz will have time (and motivation) to answer
all of them. But in practice, it’s beyond hope.

If you are interested in any rejected proposal, and willing to persuade
matz, please raise your voice, as you did in [ruby-core:42398].
I’ll be happy to reopen it.

Thank you for your long-continued contribution.

seem to have no progress.
wait. Good 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