Le 2011-10-09 09:48, Stefano Zacchiroli a écrit :
[...]
- I've made the private email aliases considered harmful point [10],
in a somehow unrelated thread. I ask you to watch out for interactions
in Debian that could happen only through private email addresses.
There are some cases where they are warranted (e.g. security or
privacy concerns), but having regular activities of a team going
through private email aliases harms us in so many ways.
Thank you Stefano. I agree, transparency in communications is very
powerful, we should try hard to be as transparent as possible. One of
the primary points which attracted me to Debian was its transparency,
which was mostly achieved through the issue tracking system. I am very
dissatisfied to see that years after I switched, some of our critical
contact points are still using private email aliases (rather than the
BTS, public mailing lists, or something else).
Please point
me to project areas that could benefit from improvements on this
front, ... unless you can just go ahead and fix the issue!
I had several problems with the BTS a few years ago. The main contact
point for the BTS being a private email alias, it took me a very long
time to realize that the team had chronic issues. And, when I realized
it, it took me a very long time to investigate these.
Of course, one of the first resources to contact when teams break should
be project leadership. Project leadership has been conducting a survey
of teams, hoping to detect problems just like the BTS team's.
Preliminary results were published in June 2008, but I haven't heard
about the survey since. I asked lea...@debian.org for an update on the
teams survey in March 2010, but am still waiting for an answer. Project
leadership also has the black box issue, apparently even more than the
BTS team.
In fact, I waited to hear from private email aliases for years. When
time came to go further, I no longer had the free time and motivation to
tackle sizable issues like team breakage. Meaning the problem with the
BTS team probably persists, and is probably affecting other people. I
can only hope some will be less patient than I was towards private email
aliases.
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. On one hand, using a private email alias is
less problematic for teams with a clearly identified leader, as it's
easier to see when such teams break. On the other hand, teams with few
people are more fragile, and overloaded teams are also more fragile. If
it takes say a year to investigate a black box, that means with yearly
elections we could be investigating the team full time.
The fact that private email aliases make it so hard to even detect team
breakage is the most important problem for me.
Even though the project is mostly transparent, there is a surprising
number of private email aliases still in use. And it's not too hard to
find some, if you just look at http://www.debian.org/intro/organization
and search for @debian.org. Several teams which are regularly
discussed do match that pattern.
DSA appears to be a more complicated case: http://wiki.debian.org/Teams/DSA
Of the 3 contact methods:
* debian-ad...@debian.org mailto:debian-ad...@debian.org is
clearly private
* debian-ad...@lists.debian.org mailto:debian-ad...@debian.org
(the contact address on the organization page) appears to be for
non-confidential purposes, but the list seems to be private
* The team also has a request tracker, which the documentation (
http://wiki.debian.org/Teams/DSA/RTUsage ) suggests is public, but
it also appears to be private
listmaster, which uses the address listmas...@lists.debian.org, is a
misleading case. That address doesn't actually correspond to a mailing list.
So lots of opportunities for improvement. Some teams simply have a
composition that refuses accountability. Others, like project
leadership, should be fairly easy to make [more] transparent. Some teams
deal with confidential information and shouldn't simply get public. Such
teams could use having different contact points (like DSA appears to
intend to have) depending on the topic. For some of these, only a
minority of activities are sensitive.
It would be great if our issue tracking system would support
confidentiality, but let's not wait for that to happen. Teams
exclusively using a private email alias which do not refuse
accountability should choose between a public mailing list and an issue
tracker and, depending on their activities, implement it as either their
new single contact method, their preferred contact method or as
