[AstroPy] Proliferating py-astro-libs

[Mark Sienkiewicz]

Erik Bray wrote:
> On 06/14/2011 04:50 PM, Erik Tollerud wrote:
>   
>> I think more than one is better mainly because the BDFL/BDFN model may
>> not be entirely fitting here.  It works well for Python because Guido
>> wrote the initial code base himself, so it already had a clear vision.
>>   In this case, we're talking about combining a number of disparate
>> approaches and ways of working, so a group with somewhat different
>> perspectives makes sense.  But as long as it's small enough (3 is
>> probably ideal), it hopefully will still be able to quickly agree on a
>> unified approach.
>>     
>
> +1 to this.  I was thinking it might be a bit awkward to have one person 
> who didn't write or even originate 99% of the code we're talking about 
> dictating

I reject your choice of the word "dictating".  The purpose of the 
organizer is to provide the service of organizing the group.  If 20 
people propose 20 mutually incompatible solutions, the organizer must 
aid the group in discussing the advantages/disadvantages of all the 
solutions.  The organizer must aid the group in negotiating to the point 
of choosing a single solution.  Sometimes there will not be agreement, 
and the organizer must aid the group in choosing which of the 
alternatives to implement.  And finally, the organizer must make a clear 
statement when a decision has been reached.

There is no dictating involved, except when the organizer acts as a 
tie-breaker at the end of this process.

The organizer has very little power.  That's ok, because the organizer 
doesn't _need_ much power to get the job done -- he needs other people 
to recognize that he is doing them a favor by doing all this.

I'm making such a point of this because it really is a key part of 
understanding how the system has to work.  If you try to think of the 
organizer in terms of military or business command/control, you will 
miss the point completely.  In that respect, BDFL is a horribly 
misleading term, but AFAIK it is the only term that would be widely 
understood in the python community.


>  those projects.  Of course, even with 3 or 5 people you still 
> have people making decisions for projects that they did not create.  But 
> making it a handful of people instead of just one person is still an 
> improvement.

The alternative is that nobody makes those decisions at all, so I think 
it is an acceptable tradeoff.


>   It makes the personality of the BDFL less of an issue.
>   

For it to work well, the 3 to 5 people acting as organizers need 
basically the same personality traits as a single organizer would, but 
it is hard to find people with those ideal characteristics.  It can 
sometimes happen that having a group will help compensate for non-ideal 
characteristics, as different members will have different strengths and 
be able to help each other out.

I wonder if we will have the luxury of 3 volunteers to take on the 
organizing job.