Re: Formal declaration of weak package ownership in source packages
Philip Hands <phil@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: