On Sun, Mar 13, 2005 at 10:11:18PM +0100, Matthias Urlichs wrote: > Hi, Matthew Garrett wrote: > > The DPL's team should be made up of everyone involved in the project, > > not a subset of it. > Your definition of "team" probably differs from the one the Scud people > use. > To pick a not-so-random example: To solve the "too-long NEW queue" > problem, you'd have a meeting with <10 people if you want to actually > accomplish something. If you round up 300+ active DDs and put them in one > room, mailing list or IRC channel instead, reaching that goal becomes > somewhat unlikely. OTOH, solving the "too-long NEW queue" problem, or most problems within the project, requires having the *right* <10 people in the room. I think people have the perception that the DPL team concept means that the people on that team are going to be exclusively involved in making decisions for the rest of the project, where in reality the hope is to distribute the coordination/facilitation tasks of the DPL among a small group of developers (advisors?) making common cause, to be better able to scale to meet the demands of coordinating activity in a project that's 1000-strong. The idea is not to make the DPL team the <10 people in the room; the idea is to put together a DPL team that includes people who are often in the room *anyway*, and commit to the goal of coordinating amongst ourselves to stay better aware of current issues. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature