On Sat, Sep 10, 2011 at 09:20:02AM +0200, Giuseppe Sacco wrote: > I am receiving the consultants@d.o emails.
After discussion with Francesca, I've been informed that you're now back
on track processing requests: that is great, thanks a lot!
> > WRT Stefano's proposal (redirect request for additions in the BTS),
Here, however, I disagree. Nonetheless, there is the big disclaimer on
what follows that you're doing the work, you ought to choose how to do
that. Mine is just a suggestion, based on some recurrent history which
I've observed all around the project.
Teams and sub-teams come and go, people are enthusiastic in the
beginning to do something, then their attention fade away. It's just the
way it is, there is nothing bad into that. Then we find "new blood /
minions" for a team, and we start over.
The problem is the lack of visibility. With private mail aliases, nobody
knows that a given team went inactive until some user complain that the
corresponding mail aliases is not responsive. At the time of this
complaint, and for all the MIA period of the team, we're not giving a
good impression of the Debian project. That is not a big deal, we're all
volunteers and we have no guaranteed services. But at the same time it
is a internal waste as maybe there *are* people willing to work on such
a task, but they simply don't know there is a backlog, because the mail
alias is private.
Of course there are cases where a private mail alias is justified
(e.g. security-/privacy-sensitive issues), but it seems to me that we
have way more than just those.
Last but not least, encouraging people to use the BTS instead of writing
to private mail aliases will also be a way to have our users exposed to
the BTS, which is a good goal per se.
Now, to the specific objections raised:
> > IMHO it could be a regression of the current workflow: the idea is
> > to delegate and extend tasks regarding the website, not to
> > concentrate them in few hands.
I don't follow this argument much. A private alias is *exactly*
concentrating the task in few hands. While if you use the BTS you can
have a set of people who routinely work on a specific task, but at the
same time empower other people to "cover up" (and/or notice that the
backlog is growing) in case of need.
It is exactly what happens in many FOSS development project: many people
have commit access rights, but there are usual roles where maintainer of
specific subsystems generally touch only those, but can occasionally
work on other subsystems.
[ FWIW: I've discussed on IRC this matter with Francesca, after this
mail of her. I think we're now in agreement, but of course I can't
speak for her :-) ]
> I think the main problem is to coordinate work and, most important,
> try to find what is pending since more time. I am unsure about the
> real help that bug reporting could do. Just to write an example: how
> may we assign each bug to specific people?
And how do you do that right now with a private mail alias? I concede
that this is a problem, but it seems to me you already have that within
the "team" at present, with the extra malus that nobody else can help.
Let me reiterate that as long as you're doing the work, it's your call
how to do that. And I thank you for the work you're doing! I just took
this change to make a point against unneeded private mail aliases in
Debian in general.
Cheers.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences ...... http://upsilon.cc/zack ...... . . o
Debian Project Leader ....... @zack on identi.ca ....... o o o
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
