Weigh In: Patches, Plugins and Proposed Enhancements
Posted by kev Mon, 05 Jun 2006 06:43:00 GMT
This week’s guide is going to be a little different.
On the rails-core mailing list, in what started as a discussion the issue of the growing number of Scriptaculous/Prototype tickets and especially enhancement requests, we’ve begun talking about the removal of the “enhancement” category on trac tickets.
The problem is that generally half or more of the tickets that come through the Rails bug tracking system are enhancement requests. With 13 people able to commit and a handful of others actively dealing with tickets being reported, enhancement requests will in general never be acted on. This means there are new tickets every day ruining that delicate signal vs noise ratio.
For a while the standard line for enhancements has been “make it a plugin and see where it goes”. This may not always be the proper response but when dealing with the deluge it is at the very least the easiest and a plugin is usually the simplest way to see feature X in Rails.
So here’s the guide part: we could use an alternate viewpoint. The rails-core list is significantly biased: people who care to speak up there are comfortable writing patches and plugins. I expect a good portion of you watching my feed and visiting my blog haven’t written patches for Rails and haven’t written your own plugin. Do you think keeping the enhancement category is worthwhile?
The real question here isn’t whether Rails should accept new features. Patches for new enhancements would be considered but enhancement tickets sans a patch would not.
I’d like to make this an open dialog. Please, speak your mind. And careful with that submit button. Apparently my comments are a bit wonky and it tends to result in double posting. I’ll try to fix it as soon as I can.
Next week we’ll return to our regularly scheduled practical guides.
I occasionally check out the ticket list, and it’s always gigantic. It is a pretty amazing feat for the committers to achieve what they do in the first place.
There are plenty of things that are wrong with Rails and need fixing. Just as a couple examples, there are some weird PostgreSQL issues at times. I’ve never even been able to successfully run the AR unit tests against Postgres, so I don’t feel confident in fixing those things myself. Transactions also aren’t supported in fixtures, which is a surprise (and I generally like the principle of least surprise).
Those are just a couple things in Rails that should work but don’t. These should definitely be taken care of before enhancements are made. Enhancements to a broken system are bad – check out the Broken Windows chapter of PragProg. If the committers don’t have time to get to these enhancements anyway, they shouldn’t be included at all. As you said, it just ruins the SvN.
I do think it might be worthwhile to have one or two committers dedicated to enhancements, while the rest fix up bugs. You might want to search the community for developers who have a track record of releasing good enhancement-style plugins.
Finally, if the Trac doesn’t even accept enhancement requests, more people will write plugins instead of hoping they make it into the core, which will only be good for the community as a whole. Many of the requests don’t even belong in the core so would get rejected anyway – might as well get those people writing plugins from the getgo.
What makes rails wonderful, especially to newbies, is that out of the box it does (almost) everything you can think of, and it does it simply. It is a complete stack that is integrated from top to bottom. When I start a rails project, I don’t have to choose from the smorgasbord for each layer and hope that everything works well together.
But if rails continues down the path that it is going, it will be no different than any other platform. When I start a new project, I currently have about 10 plugins that I install, almost half of which are just enhancements (like 12_hour_time, annotate_models, etc). None of these are absolute requirements, but at what point will rails no longer be suitable for most people out-of-the-box? (Java programmers come to know this as JAR-hell.)
Besides lack of features in the core, the other problem with not accepting enhancements is that code is less likely to be scrutinized by the community when it’s delivered as a plugin.
I think that removing the enhancement category from Trac would be a mistake. Even if the core team cannot work on those enhancements, at least there is an “official” wish list for others who are looking to contribute. In order to lower the signal-to-noise ratio maybe the enhancements could be tracked separately?
I’m a Rails developer but don’t feel that I have the knowledge or time to write patches (yet). I haven’t created a single ticket on the Trac system.
I gave up on monitoring the ‘ticket changes’ part of the Trac timeline RSS because of the enhancement noise.
I support removing the “magic lantern” enhancement tickets from the Trac system.
I say let blogs (and mailing lists) be the new form of enhancement discussion. Anything genuinely decent will spark interest and makes it way back if it’s deserving. Anything that’s not of interest will quickly fade away.
I actually like having the enhancements there; it’s a nice, central place to have a wishlist. I’m not familiar enough with the Rails codebase to be making any core changes, but I do like to flip through the enhancements (which are usually smaller more manageable tasks) and do what I can. If you guys decide to remove it, tell me and I’ll put a trac over on my site for people to put enhancements on so at least the plugin writers will know where to look. :)
How about a bounty system for enhancements? Let people put their money where their want is.
Enhancement requests, in contrast to patches, don’t really help much. They are, as others have said, a wishlist. The Rails core Trac doesn’t really seem like an appropriate place, and they just add more work for those trying to keep the list of open tickets down.
A separate way to track the desires of developers who are unable to implement their own needs would be good. I like the idea that blogs will become a good venue for discussion, but it may not be good enough for some people. Many developers will not have enough traffic hitting their blogs to generate very much interest, so will feel ‘left out’. However, I truly feel that if it’s something that a developer needs, they are software developers and they should at least make some effort to try to implement it. Rails is open source for a reason :)
Phillip has a good idea. We should just have a wishlist page on the wiki, and then if someone implements one of the items, delete the entry and make an announcement on the plugins page (or whichever is appropriate).
It is good to have that wishlist so that other developers can work on it if they want to.
Re: Brandon’s “plugin hell” – I agree that it may get to be a pain like that. Really though, merging all this stuff into Rails core will be even worse. Any time the code base gets larger it becomes harder to maintain. Right now the plugin authors are able to fix things up as quickly as you need. If they make it into core, fixes will be a lot slower.
If some things should be in core, they’l make it in. Also if we do eventually have plugin hell, someone will no doubt come up with a creative way of managing it better. It’s not really a problem yet though, and I doubt it ever will be.
I think it’s a good idea – enhancement has to be filed as such when it has a patch pinned to it.
It would be nice to have a “request a feature” system in addition to Trac though.
We were suffering from the same problem at work and it was making our issue tracking system unusable and here’s roughly how we solved the problem:
Folks on the outside can only enter bugs into trac and have another forum (wiki/email list/forums) to propose and discuss new features.
Folks on the inside (core) are the only ones who can create enhancement tickets (either from a patch they receive or for a feature they deem worthy to implement).
I think 37signals addresses this well in Getting Real when they say read feature requests and then delete them because you’ll hear about it over and over again if it’s important. Because of that I don’t think issue/bug tracking systems are really ideal to handle feature requests once a project gets popular enough.
What about flagging the tickets as ‘Patch/Plugin Wanted’. Some sort of designation that the enhancement request is understandable and would probably be accepted but is not going to be addressed by core developers.
It might also encourage people who want to contribute to Rails to actually do so. If someone’s able to browse through tickets that the core deems important enough to keep open (even if they’re too busy to implement it), they might find that motivating.
(Yes, it would be basically the same as ‘wontfix’, but it’s all in how you present it to those who may help.)
On a somewhat related note, has anyone considered backing out some of Rails’ Scriptaculous/Prototype functionality? Rails seems to give the impression that, eventually, the goal is to replace JavaScript with Ruby, or at least severely minimize the amount of JavaScript you’ll have to use. Whether or not that’s ACTUALLY the goal, if you give people a little they’ll want more. (Why can’t you make a change_cursor helper? or a sortable_rearrangeable_multiselect_data_grid helper??)
It seems to me that Ajax-based helpers (remote forms, remote functions, anything else with “remote”) belong as a part of the Rails core, since their job it to facilitate interaction with the Rails app (and have to be somewhat aware of their environment.. urls and such). But visual_effect? alert? sortable_element? Do we really want these? Do these types of helpers expose us to an ‘object-model tax’?
From what I’ve read:
1) “Enhancement” tickets in Trac don’t get acted on. 2) People still want a way of tracking enhancements.
So, if the people who work on tickets don’t have time to worry about (code-less) enhancements, then break it out into a separate system… it’s not doing anyone any good where it is.
Maybe, if no one ever has time to look at it, that separate system becomes a bucket of things that goes nowhere, until one day someone has the initiative to start making headway on that repository. Or, maybe it becomes a place where the masses who can write plugins/patches take those suggestions and make plugins for them… or make patches and submit them as enhancement tickets with code attached.
Although it’s not clear what the new system would become, it seems logical to break it out.
I vote for moving the enhancements from Trac to the Wiki or another centralized repository. I want Rails to progress towards its core principles. Also, having the extra features as plugins will allow authors to make frequent enhancements and updates.
First: Get a, codewise, stable version of rails. As rails 1.1 killed more than a few 1.0 plugins, and many 3rd party plugins are not that actively maintained frequent changes to the codebase spells out trouble..
Actually the lack of a clear vision for rails 2.0 and beyond makes it hard to choose for rails, as it might well be that stuff that works now won’t work in the next version. “Freeze rails” is the response you get when you point this out, but it is not a very good solution, i guess people will want/need the newer version eventually for a variety of reason (stabilty, features, whatever)
Removing “enhancements” might well kill rails. The rails approach to webaplications is a truly unique one, however, it is already starting to be copied. Rails must take care not to alienate from its (potential) userbase. And preventing feature requests is a step in the wrong direction. Besides, as said before, another strong argument in favour of rails is the richness of the features it offers.
Maybe trac is not the right place for enhancement request. Maybe a separate page (not a wiki, too open ended) where users can make requests/implement those request together with an incredible tutorial on how to patch rails (in a non-intrusive way) might work better. You could even choose to combine it with a reward system. However, in that case maintenance should be rewarded too, which will be the hard part to award). But no matter how to implement it, these enhancements need to be centralised and closely associated with rails-core. I think generating more user input, both suggestions and actual code, is what rails need not to be surpassed by another “rails vision” framework.