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 leader@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:
listmaster, which uses the address listmaster@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 an alternative. Please keep up the good work, Filipus |