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: 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. Enough from me, paul.butcher->msgCount++ -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On Sep 18, 2006, at 4:37 AM, Chris Mear wrote:> > 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. :) -- Building an e-commerce site with Rails? http://www.agilewebdevelopment.com/rails-ecommerce --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
Hi, 2006/9/18, Chris Mear <chris@odegy.com>:> > 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. -- À la renverse. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 18, 2006, at 6:37 AM, Chris Mear wrote:> > 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.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-0/IDydmJJnNeoWH0uzbU5w@public.gmane.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFDu8HUy30ODPkzl0RAq6YAKCLAFKc77UJylZDD3D2Yd41xE3iSACgjE9r z8ncX1kGjBTWybZSFq+5eyU=5OJL -----END PGP SIGNATURE----- --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---