We actually already have a team that's working on the issues (such as me and Steve K.) We might be a little slow sometimes, but please trust me that it's getting better than before now. :)
I think currently everyone are so busy with Rails 4 release (we do want to send some patches in as well) as they're right around the corner, so the respond time might be a little slow. After the RC goes out, I'm planning to do a big going-through the issues queue. If you would like to help us for now, feel free to go through those issues, ping the appropriate person to respond to it, or ask if it can be close. Rails Core team always appreciate your contribution, and I'm pretty sure they won't hesitate to give you out the permission to manage tickets when it's time. Thank you so much for stepping up for this. - Prem On Tuesday, September 11, 2012 at 11:28 AM, Godfrey Chan wrote: > As Richard pointed out in the other thread, we have a lot of open issues, and > it'd be nice if we could do something about that. Evan tried to get people to > review GH issues at Railsconf, and I believe there were some success there. > Any interest in formalizing this effort and make it sustainable? > > There are a few things about these issues that is pretty mechanical and > almost anyone could do it (I'll be the first to volunteer): > > 1. As new issues are coming in - > - Tag them appropriately (activerecord, activesupport, etc) - I think someone > is already doing this and they might or might not need more help doing this > - Ask for logs and other clarifications from reporter if necessary > - Do preliminary (re)searches in the source, find out who is most likely to > be the "owner" of the affected code and /cc (or perhaps even assign the issue > with the tag "needs triage" or something) them for feedback > - Close inappropriate issues (inflector patches, feature requests, questions > etc) and direct the reporter to the right channels (stack overflow, rails > guides, mailing lists, etc) > > 2. For older tickets - > - Review if they are still relevant > - Ping the reporters or the code owner for updates, and close the issues as > appropriate > > While some of these (mostly the communications part) can be done by just > anyone, I believe certain parts of the flow (tagging and closing tickets) > requires repo-collab access, so some formalized recruiting and management > effort would be necessary to make this effective. If granting full > collaborator access is a problem, perhaps it is something that we could try > working out with Github? > > Anyways, I'm happy to help here, and I'm sure there would be a few others on > the list who wouldn't mind committing a few hours per week doing this. So let > me know how I could best spend my time helping out here. > > Godfrey > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com > (mailto:rubyonrails-core@googlegroups.com). > To unsubscribe from this group, send email to > rubyonrails-core+unsubscr...@googlegroups.com > (mailto:rubyonrails-core+unsubscr...@googlegroups.com). > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.