Paul Butcher wrote:
I would like to see two things happen:
1) Make the process by which patches are accepted or rejected
transparent.
2) Clean up the patches currently in the databases so that their status
is clear, and then keep on top of new patches as they come in. There may
be more patches than can be efficiently applied by the core team, but
they don't arrive so quickly that they can't at least be responded to
indicating where they stand w.r.t the transparent process.
I'd love to see a team of trusted Trac gardeners to help prioritise
incoming patches and deal with noise. There's no reason that the core
committers have to be the only people who can do this.
Chris
See my blog post on the topic:
http://www.bencurtis.com/archives/2006/08/rails-is-growing-up/
In that post, I describe some improvements that could be made to the Rails development process. Disappointingly, that post got absolutely zero response from the core team, even though I specifically asked for feedback on it.
That said, I wasn't at RailsConf Europe and didn't see David's presentation, so maybe he responded to it there. 
Hi,
> 1) Make the process by which patches are accepted
> or rejected transparent.
>
> 2) Clean up the patches currently in the databases so
> that their status is clear, and then keep on top of new
> patches as they come in. There may be more patches
> than can be efficiently applied by the core team, but
> they don't arrive so quickly that they can't at least be
> responded to indicating where they stand w.r.t the
> transparent process.
I'd love to see a team of trusted Trac gardeners to help
prioritise incoming patches and deal with noise. There's
no reason that the core committers have to be the only
people who can do this.
I was also thinking that Rails Bugday could be organized,
that is, creating a special channel Irc Freenode channel
for one day, where patches authors who want instant
feedback, core team, people willing to test patches, are
gathered to fix the maximum of bugs (or a previously selection
of bugs ?). Other open projects like Gentoo, Gnome, Zope...
organize that type of event. I don't know exactly how they are
organized to be the most efficient in that day since I haven't any experience
in Bugday. But maybe in the Rails community, there are people
who have already take part in bugdays and can organize Rails
Bugdays. It depends also on the availability of the core team.
Just a thought,
-- Jean-François.
One common reason patches get closed is for lack of a unit test to prove it is fixed.
That said, a group of gardeners who can either create the patches or at least comminucate the need through trac would be beneficial.
David Morton
Maia Mailguard http://www.maiamailguard.com
mortonda@dgrmm.net
