Project leadership transparency (Re: private email aliases considered harmful)
Hi Stefano,
Stefano Zacchiroli wrote:
On Tue, Nov 08, 2011 at 01:13:46PM -0500, Filipus Klutiero wrote:
> I believe the first thing to do is to make project leadership
> transparent. For as long as the constitution will give it such a
> crucial role, and as long as it will be so low on resources compared
> to the project's size, the team has high risks of seeing its
> performance degrade to sub-optimal levels. It often got minimal (if
> not worst) for fairly damaging durations.
I'm not sure of I should interpret "project leadership" here and in the
rest of your mail. In some parts it seems to refer to the DPL, in some
others it seems to be more broad. Under the assumption that you
actually meant the DPL, I feel obliged to comment on this.
"DPL" could pretty much be substituted to "project leadership", since
the DPL is currently Debian's only "executive director" (although there
has been some distribution of the role in the past nevertheless).
I hope that clarifies.
There are different kinds of transparency. For the DPL, a democratically
elected role, IMO the most important kind of transparency is
accountability towards Project members --- as it is them who get to vote
in DPL elections, and it is them who are represented by the DPL. I've
worked quite a bit on that front, by daily documenting since the
beginning of my first term what I've been doing with my DPL hat on. The
corresponding daily logs are, however, accessible only to project
members. I've discussed the reasons of this choice not a long ago in
reply to a follow-up by Paul Wise to a "bits from DPL" mail. It can
easily by found on -devel archives.
The second kind of transparency descends from the general commitment to
openness of the Debian Project. I've tried to fulfill that kind of
transparency with monthly "bits from DPL" mails (see wiki.d.o/Teams/DPL
for an index), that are essentially summarized versions of the daily
logs for the corresponding reporting period. My implicit assumption in
all the above has always been that people should be able to understand
the DPL "team" has a problem (e.g. has gone MIA, burned out, whatever)
as soon as he/she stops reporting.
As long as the DPL remains a single-seat position, it's not clear to me
what more can be done to play that role more transparently. We could do
better if, for instance, we had a board of DPL helpers that shares the
corresponding TODO list. Such a board + the DPL could hold periodic
public meetings on IRC to discuss the status quo of the open tasks and
also spare some time for interaction with attendees for questions and
the like. That is the sole arrangement I can imagine that would have
chances to increase the transparency of DPL-related activities even
further. [...]
I see leadership meetings and having a "question time" as 2 different
things. It may be efficient to hold both one after the other, but one
doesn't need the other.
If leadership thinks having a question time is worth it, it can be done
even with a single-member team. However, in my view the concept of
question time is mostly good for groups which are accountable to the
public, but which operate (take decisions) in private, such as political
parties. In my opinion, Debian's management should operate as publicly
as possible, in such a way that transparency is natural and doesn't need
active efforts like question time to be achieved. In a group that
operates openly, questions from question time can largely be replaced by
questions asked in an issue report or in the discussion the group is
having on a topic internally.
Realistically, we can't expect much active transparency in an
organization based almost exclusively on voluntary work.
If the lack of regular reports to the public should be interpreted as a
sign of team breakage, we would have to set standards pretty low not to
conclude that all Debian teams are broken with a few exceptions. This is
not to say that reports aren't useful, just that they're far from being
a sufficient indicator of team health.
Conversely, a team which reports is not necessarily healthy. A team
could have manpower, but none doing good job, or not enough to cope with
important issues.
Although I don't think that actively achieving transparency by
communicating with the public is particularly prioritary, I do think
that making operations as naturally transparent as possible is very
important. The fact that most Debian contributors are distant and only
exceptionally communicate in person may make communication harder in a
sense, but also means we can very easily make our communications
publicly accessible. I think some simple "passive transparency" choices
such as using forums give more results *and* are much cheaper to make
than going for "active transparency". We already have fair
infrastructure for mailing lists and issue tracking, so in my opinion
only the most trivial teams may afford offering a private email alias as
their main contact point, unless secrecy is actually wanted.
I agree that transparency is a great attribute to get [re-]elected as
DPL, but in my opinion this isn't its main benefit. Transparency informs
about the project and provides confidence to the project's potential
users and contributors. It also maintains the confidence of existing
users and contributors, and dispels cabal theories.
To get there, however, the raw material needed are volunteers to help
with DPL tasks. Having thought about the above since quite a while, I've
repeatedly called for volunteers to work on DPL-related tasks.
Unfortunately, with little success so far ... but I haven't given up
hope yet (hint hint :-)).
Interesting. I for one volunteered to help project leadership, not yet 3
years ago. In the case of my offer, it was not even answered. It is
quite bad if we are now in the opposite extreme.
I guess this should be taken as an illustration of the lack of
transparency's cost :-/ Indeed, not only is it very hard to detect and
investigate breakage in opaque teams, but precious offers to help remedy
problems are likely to be wasted.
Reply to: