They''re flooding the trac. Can Scriptaculous get a trac of its own or can we direct non-patch enhancements to the spinoffs list and close them? This is getting rediculous. -- Kevin Clark http://glu.ttono.us
On 6/3/06, Kevin Clark <kevin.clark@gmail.com> wrote:> They''re flooding the trac. Can Scriptaculous get a trac of its own or > can we direct non-patch enhancements to the spinoffs list and close > them? This is getting rediculous.I also think this is getting completely out of hand. In addition to moving prototype and scriptaculous to their own tracs, I''d like to propose something else: No More Enhancement Tickets. Tickets in trac should either be: 1) Bug Report 2) Patch. This will cut down the volume of submissions, and hopefully let us focus on the good stuff that''s coming in every day. Thoughts? -- Cheers Koz
+1 for no more enhancement tickets. If they want someone to do it, mail one of the lists or do it themselves. Plugins over patches in general. Bugs should still be filed. Kev http://glu.ttono.us
On 6/2/06, Kevin Clark <kevin.clark@gmail.com> wrote:> +1 for no more enhancement tickets. If they want someone to do it, > mail one of the lists or do it themselves. Plugins over patches in > general. Bugs should still be filed.Why turn down the volunteered creativity and enthusiasm of people interested in these libraries? They could become interested enough to make big code contributions. I think open source projects should be very welcoming and closing the brain storming down would be an unfortunate move. Only if there is another official chanel for enhancement ideas it would be ok to stop the enhancement tickets. Peter
On 3-jun-2006, at 5:17, Michael Koziarski wrote:> No More Enhancement Tickets. > > Tickets in trac should either be: > > 1) Bug Report > 2) Patch. > > This will cut down the volume of submissions, and hopefully let us > focus on the good stuff that''s coming in every day. > > Thoughts?-1 because with this you are manifesting that Rails IS perfect and anyone who thinks the way it works should be upgraded has to either make workarounds or create exceptionally breakable plugins that override code. -- Julian ''Julik'' Tarkhanov please send all personal mail to me at julik.nl
> -1 because with this you are manifesting that Rails IS perfect and > anyone who thinks the way it works should be upgraded has to either > make workarounds or create exceptionally breakable plugins that > override code.I disagree. The problem is that the trac has been the place to ask for everything under the sun . No one is going to get to your enhancement request unless you do it yourself or get someone else to feel the pain. Sure, discuss it on one of the lists and maybe someone will pick it up, but enhancement tickets are rarely taken on unless a developer has the same need. The point isn''t that Rails is perfect, the point is that what could be improved shouldn''t be discussed on Trac. If plugins are easily breakable, maybe they need a redesign? Kev
On 3-jun-2006, at 19:47, Kevin Clark wrote:>> -1 because with this you are manifesting that Rails IS perfect and >> anyone who thinks the way it works should be upgraded has to either >> make workarounds or create exceptionally breakable plugins that >> override code. > > I disagree. The problem is that the trac has been the place to ask for > everything under the sun . No one is going to get to your enhancement > request unless you do it yourselfI am speaking about enhancment tickets that have patches and test coverage. Maybe you mean just generic "enhancement requests" (i.e. `I want this and that` - without any code)?> Sure, discuss it on one of the lists and maybe someone will pick > it up, but enhancement tickets are rarely taken on unless a developer > has the same need.Which doesn''t seem too nice to me. If the ticket is 20 lines, is understandable and has test coverage - what is the problem?> The point isn''t that Rails is perfect, the point is that what could be > improved shouldn''t be discussed on Trac. > > If plugins are easily breakable, maybe they need a redesign?Have you ever implemented a plugin that needed to change a tiny, but substantial feature of the Rails code? You wouldn''t be asking this if you did. Going back to my own tickets, for instance: http://dev.rubyonrails.org/ticket/4947 Can you show me a way to do this kind of thing non-intrusively? I.E. without introducing the "every-single-darn-bolt-and-nut-is-a- pluggable-component" madness with DI and the like. I agree that tickets with code should be closed as "wontfix" faster if the core doesn''t like them at all. There is an enormous backlog of both experimental and non-experimental patches. -- Julian ''Julik'' Tarkhanov please send all personal mail to me at julik.nl
Yup, I''m not against doing away with proper patches. I''m against things like "It''d be nice if scriptaculous had a helper to make a web 2.0 application for me". Patches certainly still have a place, and essential functionality where the code fills a common need definitely belongs in core. That being said, most feature requests can be solved with a plugin, and many of them should be resolved in that fashon. That being said, I think it makes sense to only allow patches and defects. Enhancements (which aren''t patches) is just a wish list that gets out of hand. Kev -- Kevin Clark http://glu.ttono.us
On Sat, Jun 03, 2006 at 08:34:13PM +0200, Julian ''Julik'' Tarkhanov wrote:> > On 3-jun-2006, at 19:47, Kevin Clark wrote: > > >>-1 because with this you are manifesting that Rails IS perfect and > >>anyone who thinks the way it works should be upgraded has to either > >>make workarounds or create exceptionally breakable plugins that > >>override code. > > > >I disagree. The problem is that the trac has been the place to ask for > >everything under the sun . No one is going to get to your enhancement > >request unless you do it yourself > > I am speaking about enhancment tickets that have patches and test > coverage. Maybe you mean just generic "enhancement requests" (i.e. `I > want this and that` - without any code)? > > >Sure, discuss it on one of the lists and maybe someone will pick > >it up, but enhancement tickets are rarely taken on unless a developer > >has the same need. > > Which doesn''t seem too nice to me. If the ticket is 20 lines, is > understandable and has test coverage - what is the problem?This discussion of removing enhancements tickets never had anything to do with patches. A distinction is indeed being made between a ticket that says "I want this" with no associated patch and a ticket that has a patch. We have been discussing doing away with the former. marcel -- Marcel Molina Jr. <marcel@vernix.org>
On 3-jun-2006, at 20:45, Kevin Clark wrote:> Yup, I''m not against doing away with proper patches. I''m against > things like "It''d be nice if scriptaculous had a helper to make a web > 2.0 application for me".Then I misunderstood the message completely. I am 200% on to wipe the "magic lantern" patches. -- Julian ''Julik'' Tarkhanov please send all personal mail to me at julik.nl
If you''re overwhelmed with feature requests from a particular area, the solution is not to force people to stop requesting. The solution is to use Trac more effectively. Use filters, for christ sake! And it may be good idea that some available Trac reports (http://dev.rubyonrails.org/report) filter OUT spinoffs like script.aculo.us by default - you can try request that from core developers - that would be the end of your troubles. A separate report for viewing script.aculo.us requests (and other things filtered out) could be set up. When my mailbox get spammed, I don''t ask spammers to stop sending me mortgage offers. I set up filters (or use a provider that has ones set up already). This is computer age On 3-jun-2006, at 5:17, Michael Koziarski wrote:> > No More Enhancement Tickets. > > > > Tickets in trac should either be: > > > > 1) Bug Report > > 2) Patch. > > > > This will cut down the volume of submissions, and hopefully let us > > focus on the good stuff that''s coming in every day. > > > > Thoughts?_______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
> If you''re overwhelmed with feature requests from a particular area, the > solution is not to force people to stop requesting. The solution is to use > Trac more effectively. Use filters, for christ sake! And it may be good idea > that some available Trac reports ( > http://dev.rubyonrails.org/report) filter OUT spinoffs like > script.aculo.us by default - you can try request that from core developers - > that would be the end of your troubles. A separate report for viewing > script.aculo.us requests (and other things filtered out) could be set up.Filters don''t actually solve anything. If all 12 people with commit rights are filtering out an entire subset of the ticketing system, then what purpose is there in having people submit them in the first place. I don''t think it''s fair to give the impression that these requests will be actioned and then have them sitting ignored indefinitely.> When my mailbox get spammed, I don''t ask spammers to stop sending me > mortgage offers. I set up filters (or use a provider that has ones set up > already). This is computer ageI think it''s fair to say that we''re all aware that this is the computer age. -- Cheers Koz
> > Yup, I''m not against doing away with proper patches. I''m against > > things like "It''d be nice if scriptaculous had a helper to make a web > > 2.0 application for me". > > Then I misunderstood the message completely. I am 200% on to wipe the > "magic lantern" patches.In hindsight, I communicated poorly, I can see how people would interpret my email like that. I''m *definitely* not suggesting that we get rid of patches which implement new functionality. Quite the opposite, I simply think all enhancement requests should be in the form of a patch. Trac isn''t the place for discussing new features, this list is. We should try and keep trac to a list of bug reports, and pending patches, rather than a large wishlist of items which won''t be actioned. -- Cheers Koz
> I''m *definitely* not suggesting that we get rid of patches which > implement new functionality. Quite the opposite, I simply think all > enhancement requests should be in the form of a patch. Trac isn''t > the place for discussing new features, this list is. We should try > and keep trac to a list of bug reports, and pending patches, rather > than a large wishlist of items which won''t be actioned.Right, it isn''t getting rid of magic lantern patches so much as magic lantern requests without a patch.
On 4-jun-2006, at 4:22, Michael Koziarski wrote:>> > Yup, I''m not against doing away with proper patches. I''m against >> > things like "It''d be nice if scriptaculous had a helper to make >> a web >> > 2.0 application for me". >> >> Then I misunderstood the message completely. I am 200% on to wipe the >> "magic lantern" patches. > > In hindsight, I communicated poorly, I can see how people would > interpret my email like that.We both did. Of course I meant "magic lantern" _tickets_(I just got totally immersed in #5275 and #4947 because my stuff started breaking horrendously). But I''m with you on this one. -- Julian ''Julik'' Tarkhanov please send all personal mail to me at julik.nl
On 6/4/06, Michael Koziarski <michael@koziarski.com> wrote:> > > If you''re overwhelmed with feature requests from a particular area, the > > solution is not to force people to stop requesting. The solution is to > use > > Trac more effectively. > > Filters don''t actually solve anything. If all 12 people with commit > rights are filtering out an entire subset of the ticketing system, > then what purpose is there in having people submit them in the first > place. I don''t think it''s fair to give the impression that these > requests will be actioned and then have them sitting ignored > indefinitely.Well, that is why I said that, if you filter them out, you need to create separate reports for those. I never proposed for them to be cast aside and forgotten, but if you don''t deal with this then the effect will be the other way around: they will make regular tickets sit ignored almost indefinitely because it will be hard to get to them. I think it''s fair to say that we''re all aware that this is the computer age. Precisely so. So why change a community, when you can change a (computer) system? _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
> Precisely so. So why change a community, when you can change a (computer) > system?We don''t want to change the community, we want to change how the community requests new features. Those sorts of requests shouldn''t be going through trac.
On 4-jun-2006, at 19:17, Kevin Clark wrote:>> Precisely so. So why change a community, when you can change a >> (computer) >> system? > > We don''t want to change the community, we want to change how the > community requests new features. Those sorts of requests shouldn''t be > going through trac.There might be some area on the site such as "Rails magic lantern", where anyone can post his feature request - either as just a request or as a bounty. If someone decides to tackle, he will be able to couple a request to the concrete trac ticket. Pity I ain''t got much time lately. -- Julian ''Julik'' Tarkhanov please send all personal mail to me at julik.nl
> Well, that is why I said that, if you filter them out, you need to create > separate reports for those. I never proposed for them to be cast aside and > forgotten, but if you don''t deal with this then the effect will be the other > way around: they will make regular tickets sit ignored almost indefinitely > because it will be hard to get to them.Either way, if they''re sitting in some report, which no one reads, why give the false impression that someone''s going to action them. What does having them sitting in trac really achieve? -- Cheers Koz
If you haven''t seen it, I wrote an article in place of my weekly guides asking my readers what they think about removing enhancements and linking them to this thread. I''ve already got 7 comments this morning, so it might be worth checking out. http://glu.ttono.us/articles/2006/06/05/weigh-in-patches-plugins-and-proposed-enhancements#comments Kev
> Right, it isn''t getting rid of magic lantern patches so much as magic > lantern requests without a patch.OK this just makes me think in terms of economics. Requests for enhancements which require no action on the requestor''s part are guaranteed to trigger "tragedy of the commons" effects. That is, if people can get things for free, the resource will be wasted, irrespective of how useful it is. If people have the ability to request enhancements without first being required to go to some effort, it is highly likely that sooner or later they will request enhancements that already exist. The effort is nil, the resource is free, and there might be a payoff. Basically, this is the reason spam exists. +1 on getting rid of magic lantern requests without patches. -- Giles Bowkett http://www.gilesgoatboy.org
On 6/8/06, Giles Bowkett <gilesb@gmail.com> wrote:> > Requests for enhancements which require no action on the requestor''s > part are guaranteed to trigger "tragedy of the commons" effects. That > is, if people can get things for free, the resource will be wasted, > irrespective of how useful it is. > > <snip> > +1 on getting rid of magic lantern requests without patches.+1 on Giles'' post... very nicely put and absolutely true -- Mislav _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core