On 2/8/06, Bob Silva <[EMAIL PROTECTED]> wrote: > When I first browsed through the bugs list, I felt a sense of sorrow for the > core team members. Not sure how you manage that list unless you have > specialized interfaces which the public doesn't see. > > If there's anything we can do to assist in managing/filtering the bugs list, > let us know. I am willing to spend time either creating patches or > researching/adding remarks on tickets to reduce the time you would need to > investigate it. > > You also see a lot of stuff like below where a decision wasn't made or the > patch not applied and is no longer relevant to today's code base: > > http://dev.rubyonrails.org/ticket/1059 > > Personally, I prefer the small team of committers as it keeps the project > focused on what it is, instead of trying to become all things to all people > (like some other language I used to use). I think creating a level above > core that filters the "ready to apply" patches/bugs would be a good start to > helping out though. Of course, this model requires a certain level of trust > which I'm not sure how to "build". > > Bob Silva > http://www.railtie.net/
Actually, that extra layer already exists. There is already the ability for anonymous users to add keywords to tickets. All we have to do, as the community, is agree on the meaning of keywords that we want to apply to tickets. i.e: r2g: ready to go micro: a really small fix typo, docs, etc As the core team members start to realize that things are being tagged by the community, they'll start searching on the tags. If you want to contribute by tagging up a bunch of patches, I would think it would be appreciated. -- Kyle Maxwell Chief Technologist E Factor Media // FN Interactive [EMAIL PROTECTED] 1-866-263-3261
_______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core