> What exactly is it that you think is so wrong? Maybe if you can explain what > the actual specific problem is, I can address it.
After reading this morning's responses, I disagree with Luis's comment that "The trend seems to be defensive/aggressive." While I see direct, non-PC feedback, frankly I see no evidence of either defensiveness or aggressiveness. Thank you for the non-defensiveness, and if I've accidently offended anyone with my feedback, that wasn't my intent. While I agree that threads that devolve should be brought back in line, it's a two-edged sword. Potentially productive (and difficult) discussions can be cut off too early. Specific process areas I see that are ripe for improvement: 1) Increased communication and a tweaking of contributor roles. I think perceptions such as [1] with phrases like "..he looks like ineligible for a maintainer" and "...the very poor maintenance status of rubygems..." are warning signs that the issue level has outpaced the project's ability to respond in a timely manner. This thread's issues and responses also appear (at least to me) to be warning signs. To me, these warnings indicate a need to review how RubyGems best utilizes it's contributors skills. As a User developer (outsider), I fully appreciate the fact that I don't have all the facts, but I think ideas like Backup Lead and/or Next Release Wrangler could help offload Eric when needed, enable much needed contributor "me time", take better advantage of the contributor horsepower you have, and minimize perceptions and emails like [1]. In a nutshell, evolution in the face of RubyGems central role. While the suggestions may sound good on paper, at the end of the day, you're in the best position to know what's sustainable by you. 2) Increased issue prioritization visibility. What are the key issues preventing the next release? There's no Issues at http://github.com/rubygems/rubygems (not really a problem) and the 59 open issues at [2] (sorted by Priority) don't really indicate which of those are viewed as "must fix" for the next release. Maybe this list lives somewhere and I'm missing it? I think a wiki page similar to [3] listing the just the key issues preventing the *next* RubyGems release is both maintainable and has tremendous benefits including: * Focusing contributor efforts to the highest priority issues. * Enables easier Drive-by-Contributions for folks having a limited amount of time to contribute, but wanting to contribute in the high value-add places. * Better expectation management. For example, if someone posted a bug, noticed it wasn't considered enough of an issue for the next release (and felt strongly about it), they could try to be more persuasive as to the risks if the issue remains unresolved. While I have my own favorites I'd like to see fixed, the issue I currently feel most strongly about is the RubyGems 1.3.7 differences between the one embedded in 1.9.2-p0 and standalone...both for technical and precedent reasons. Jon [1] http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/31236 [2] http://rubyforge.org/tracker/index.php?group_id=126&atid=575 [3] http://github.com/rubygems/rubygems/wiki/Summary-of-major-issues _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
