Philip Hands <p...@hands.com> writes: > Until now I've tended to be irritated by the way courts do that, but > suddenly I have more of an understanding of why they do ;-)
> Having someone that is familiar with court processes on the TC might > help. I don't know if any of the current batch have a legal background. > I wonder how long it would be before people start acting as advocates to > guide others though our increasingly arcane rules -- that might actually > work quite well though. Perhaps we'd have a better process if someone > not involved in the dispute acted as champion for each party, so that > even timid folk could be confident that the person they were dealing > with was on their side. This is not a fully-thought-out idea, but reading this, it occured to me to wonder if we're erring here in going farther down the path of legal process, which inherently emphasizes the grievanace and personal responsibility aspects of the problem. A lot of the problems that come before the TC strike me more as project management problems than legal problems, in that the question isn't about liability and harm so much as it's about technical and procedural approach and about tradeoffs between several possible good approaches. The TC is quite competent to make judgement calls on the relative importance of several different possible technical outcomes, but that doesn't necessarily help if the maintainer still disagrees with their call and isn't happy with letting their judgement be overridden. (I have a talk I gave at work on the emotional and personal motivations of free software work that I should reproduce in some more public forum.) But treating this as legal action puts hard emphasis on rights and responsibilities and other such things that I think tends to make this all more fraught. In a workplace, this sort of thing is usually sorted out by a project manager instead, who talks to the various stakeholders, tries to build consensus for some general approach forward, puts timelines on it, and then holds people accountable to those timelines. This is always trickier to do with volunteer work, where you can't really enforce any timeline, but the overall strategy feels better to me. Project managers come with the base assumption that this is not an adversarial process, everyone is trying to produce the best outcome, but there are both resource and direction conflicts that have to be resolved somehow. Project management in general is a huge gap in the free software world, and I think we're no exception. It's easy to underestimate the power of a good project manager unless you've worked with one. Quite a lot of this process feels to me like it would benefit hugely from a project manager, including the perpetual complaint that the TC is too slow, which is one of the core things that project management can help with just by keeping the eye on the specific actions that have to be taken to move things along. And we should strive to emulate processes that have the properties we feel we're missing, so if more timely action is a goal, emulating legal process (which is notorious for interminable delays) may not be a good idea. One of the roles of project managers everywhere is to guide people and projects through whatever process is used by the larger organization. If there's anyone out there reading this with project management experience who has been wondering what they could volunteer to do to help Debian immensely.... -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>