Re: Ruby's Standard Library could use a lead maintainer

James Edward Gray II wrote:
> On Nov 4, 2007, at 11:22 AM, Gregory Brown wrote:
>
>> During the Town Hall meeting with Matz at RubyConf, I asked him
>> several questions about Ruby's standard library.  I then caught up
>> with him later on and talked a bit about maintenance and progress
>> issues with the stdlib, and tried to come up with some suggestions.
>>
>> Basically, Ruby's standard library has some great stuff in it, but
>> it's difficult to keep it organized, up to date, and representative of
>> what the Ruby community needs.
>
> This is an interesting issue.  It will surely not be easy to address 
> all concerns, but I think talking about it is healthy.
>
>> Some issues I'm thinking about that currently exist are:
>>
>>   - It is sometimes hard to contact the maintainers of some of the 
>> packages
>
> With TextMate, we do try to keep a current contact email address in 
> each bundle.  These addresses are available to the users and we 
> encourage them to take their issues there first, but we try to 
> function as a backup if that plan doesn't work for whatever reason.
>
> I'm not suggestion Ruby adopt this strategy.  I'm just sharing what 
> I've seen elsewhere.
>
> I do believe this is a fairly big issue.  I mean we currently have a 
> thread about unbundling YAML and people are concerned by that 
> possibility.  We do need to find someway to at least maintain what's 
> there.
>
>>   - We have several competing libraries within the standard lib, some
>> of them probably can be removed
>
> I believe the current plan is to remove some of these and I'm glad to 
> see that step being taken.  I think we're making progress here.
>
>>   - There are some libraries that have become defacto standards (such
>> as FasterCSV) in the Ruby community, effectively deprecating the
>> stdlib which ship with Ruby.
>
> Some standard libraries do have bugs or performance issues.  In some 
> cases there are libraries that do the same job better or faster.
>
> Sometimes this is hard to judge though.  Sometimes competing libraries 
> each have their strengths and it's hard to call one better.
>
> Even in cases where there is a clearly better option, replacing a 
> standard library is a tricky thing to do.  Most people will likely be 
> angry when Ruby starts breaking their code with regular updates, just 
> because we wanted to swap out a library.  I think Matz tries to be 
> conservative with the changes for this reason.
>
> This is a hard problem to solve.
>
>> My suggestion is that perhaps someone with decent experience with the
>> standard library (not me :) could be selected to be a lead developer
>> for it.  This person wouldn't necessarily be responsible for
>> maintaining everything, they'd just be responsible for looking at the
>> state of the stdlib as a whole, rather than just the individual
>> packages.
>
> This is a pretty neat idea, though it does sound like a hard job.  I'm 
> having a little bit of a hard time seeing where this person fits into 
> the current structure.  That doesn't mean it's not a good idea, just 
> that I think the role would need to be pretty well defined to avoid 
> people getting upset by the person's actions.
>
>> This person might:
>>
>> - monitor RCRs and make cases for strong ones to Matz
>
> The current RCR process seems to be struggling.  I think that process 
> probably needs fixes, before it can be incorporated.
>
>> - help locate maintainers who have gone missing, or find replacements
>> in the event of orphaned code
>
> Typically, the best way to find a maintainer is to grab someone who 
> starts submitting patches.  Of course, without a maintainer, I think a 
> lot of current patching efforts are being ignored.  We may need to 
> think about this a little.
>
>> - Keep an eye on community discussions and give feedback to the core,
>> as well as relay information about changes to the stdlib back to the
>> community
>
> We probably need to strengthen the feedback loop all around.  This is 
> the easiest point, but I do think it's valuable.
>
>> - Act as a decision maker when controversy arises.
>
> This would be tough.  It's hard to know what's the best choice in many 
> situations that arise with maintenance of the standard library.  No 
> one wants to make a bunch of Ruby developers angry.  Clearly 
> discussion would be needed, at the minimum and Matz probably needs to 
> be involved on some level, for major decisions.
>
>> I think that we might benefit a lot from having a person who could do
>> this sort of thing to make sure that the stdlib stays up to par with
>> the rest of ruby.
>>
>> What do you all think?
>
> The above is just my opinions.  I could be wrong on any number of things.
>
> On the whole, the idea is interesting.  I'm not sure I completely 
> understand the role yet, but I'm for anything that makes things easier 
> for the developers.  I think it's at least a great topic of discussion 
> and I'm glad you brought it up.
>
> James Edward Gray II
>
>
Well, I think this is one of those, "Oh gosh yes ... that's a *really* 
great idea ... but *I* just don't have the time" situations. The code 
base is growing, there are more developers, etc. Somehow all the major 
open source projects manage to get things done, and I doubt very 
seriously if Ruby will turn out to be any different in that respect.

But you know, considering what a pragmatic bunch of behavior-driven 
continuous-integration-automation-crazed people Rubyists are (in between 
Werewolf championships) it wouldn't surprise me one bit if we didn't end 
up with something that made CPAN look like a slave labor camp. :)

Can you tell I'm fading rapidly? :)