On Tue, Aug 16, 2005 at 02:46:35PM +0200, Petter Reinholdtsen wrote: > [Alexander Schmehl] > > Do you realy think you can enforce teamwork? I don't think so. > > Either some people will work together as a team or individuals will > > do it their own way. And I don't think it will be a good idea, to > > force those individuals to work in a team. > > I agree. There will always be people unwilling or incapable of > working in teams, and some of them will be debian developers. I > wounder how many of these decided to join in on this thread. > > But I believe it is a good idea to remove the most important packages > in debian from the single set of hands maintaining them at the moment, > if the current maintainer is unwilling to maintain these in a team. I disagree. If the maintainer is doing a good job on his (or her) own, then there is no need at all to take away their packages. [...] > We should strive to increase what I normally call the bus-factor; how > many people need to be run over by a bus before the project stops. > And for several of the packages in debian, the count is 1 or less. That's not true. For several of the packages in Debian, it is true that there will be a problem if their maintainer will be run over by a bus. However, that in no way means the project "stops". As the past has taught us, should something like that happen, there will be people willing to take over. It might take a bit longer for the new maintainer to be up to speed as compared to when one member of a team gets run over by a bus, but that doesn't mean "the project stops". We should strive to increase the quality in Debian. If some people can produce higher-quality packages by working in a team, then more power to them. If other people can produce higher-quality packages by /not/ working in a team, then there is no reason to force them to work in a team. Don't forget that every bit of teamwork results in some overhead; you have to communicate to your team members what you're doing, and all of your team members have to understand it (which may involve tedious explanations and/or some learning time for your team members). Depending on the complexity of a package and the amount of work required to maintain it, this overhead may just not be worth it. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond
Attachment:
signature.asc
Description: Digital signature