During RailsConf Europe, DHH identified the start of a problem within
the Rails community - a problem he described as “Vendoritis”. I’m wary
of summarising what he said for fear of misrepresenting his views, but
he made a number of very good points about how best to participate in
the Rails community, and the rights and responsibilities that come with
participation.
DHH was primarily talking about a problem with communication from the
Rails community “at large” to the core team. I agree with most of what
he says, but would like to draw his attention to a problem that I
perceive with communication in the other direction.
DHH correctly says that people earn membership of the community by
participating. True, but it cuts both ways. Specifically, one of the
ways in which people can participate is by submitting bug reports and
patches, and many people have done exactly that. Many of these bug
reports and patches do not, however, garner any kind of response.
Although I understand some of the reasons why, I believe that it needs
to change.
DHH correctly made the point that the core team has limited bandwidth
with which to process bug reports and patches. The solution he proposes
of using plugins to develop new functionality goes a long way, but is
not the complete solution. Plugins are an appropriate mechanism to
handle adding new functionality to the framework. They are not an
appropriate mechanism to handle bug fixes in code which is already part
of the core framework.
Right now, I don’t know what process is used to select patches to be
applied to the core. All I know is that some patches are selected and
others aren’t. How the decision is made is a complete mystery to me.
From what I can tell from my conversations at RailsConf Europe it is
also a mystery to most members of the wider Rails community.
I have been lucky enough to have two of the patches that I’ve submitted
applied (#3274: rake freeze_gems fails on Windows and #5996:
ActionWebService WSDL generation ignores HTTP_X_FORWARDED_HOST). Two
other patches I’ve submitted (#3733: Off by one error in documentation
for :offset and #4999: rake test:uncommitted doesn’t work on Windows)
have not been applied. I have no idea why.
#3274 and #4999 have a great deal in common. Both fix problems with rake
tasks which don’t function correctly on Windows. Both have the same root
cause (assuming that “/” is the directory separator) and both are very
simple fixes. Why did one of these catch the attention of the core team,
and the other didn’t?
There are two key points:
Firstly, although this kind of thing isn’t as “sexy” as headline
features like SimplyRestful/Helpful/Whatever (which I think are great,
by the way!), it is just as important. Fixing bugs is boring and prosaic
and absolutely essential to the long-term future of Rails.
Secondly, if someone takes the time to create a patch, it is simple
courtesy to respond. That doesn’t mean that it has to be applied of
course. But as a bare minimum we should give them some indication of the
process by which patches are evaluated. Further, we should let them know
where their patch is in this process and, if there is a problem with it
which means that it cannot be applied, what the problem is and what they
need to do about it.
Two more examples (not submitted by me, this time):
Firstly #3652: Options for sendmail to set location and sender address.
ActionMailer makes a bunch of unreasonable assumptions about sendmail.
This patch removes those assumptions. I haven’t inspected the patch in
detail - I don’t know whether it’s ready to be applied, but I do know
that it fixes a real problem and that the history of the ticket is very
“odd”. It’s been closed, with no explanation, twice. The original
submitter has reopened it on both occasions. If there’s something wrong
with the patch, then fine - but tell the submitter what’s wrong with it
so that he can address the problem.
Secondly #4005: Migrations: rename_column does not preserve column
options and #4686: rename column removed default value. These tickets
both refer to the same bug. #4686 was closed as invalid, again with no
explanation. There’s no question that the bug exists - I’ve been bitten
by it myself. Maybe there’s a good reason why we shouldn’t fix it. Maybe
the fix proposed by the submitter isn’t up to the job. But if we don’t
tell them why it’s unacceptable, or if we don’t explain why the bug
shouldn’t be fixed, how do we make sensible progress?
Call to action:
I would like to see two things happen:
-
Make the process by which patches are accepted or rejected
transparent. -
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.
Enough from me,
paul.butcher->msgCount++
