On Sat, Sep 10, 2011 at 02:51:46PM +0200, Giuseppe Sacco wrote:
> probably BTS could help on the visibility problem side. I would like
> to find a way to solve other problems too. Maybe there are some
> instruments that could easy this listing work.
Heya, although here I'm really stepping into something it should really
be up to you to discuss, let me just give some feedback in case you were
looking for it.
> Let's start from what are pointing out: lack of visibility about email
> processing. I think there are a few other areas where problem arise.
> Some of them are related to processing: who is in charge for a specific
> activity. Others are relate to checks that could probably be done
> automatically: periodic checks about email/URL validity, alerts about
> listing requests never checked, just to name a few.
Correct. Opening up the email aliases fix the visibility problem of
unprocessed incoming requests, but not the others (even though, AFAICT,
the others problems were already present in the alias-based workflow ---
having a shared mailbox alone does nothing to help dispatching tasks
within the people behind the alias or ensure they do not slip through
the cracks, etc).
> Is there any way in Debian BTS to easily add a current state of the
> processing? I mean, as in a workflow or in a task list. Something that
> would say: listing request has been received, URL has been checked and
> contains services on Debian, personal page is still to be created,
> listing is still to be added.
As far as I can tell, there is nothing as general as you imply here. But
there are various features that can help. FWIW I've been using them
within the QA team to triage bugs related to the "qa.debian.org"
pseudo-package and assign them to sub-project (e.g. the PTS, DDPO, etc.)
that, in turn, have corresponding "maintainers" within the team. How the
QA team uses them is documented at [1]; a sample outcome of how it looks
like is visible at [2].
[1] http://wiki.debian.org/qa.debian.org/bugs
[2] http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=qa.debian.org;dist=unstable
With such a workflow, either the user already submit bugs with the
appropriate user tags --- making them land from day 1 in the appropriate
category --- or someone within the team notice an unclassified bug and
triage them to the appropriate category, by adding user tags. As an
example, when I was maintaining the PTS (which was my main role within
the QA team) I knew I should mainly look at the sections mentioning
"Package Tracking System" and, possibly, to untriaged bug and triage
them adding user tags.
Regarding your point of knowing the status of a specific request, the
BTS has the "summary" keyword
http://www.debian.org/Bugs/server-control#summary that enables to point
at a specific mail within a bug log that contains the current status of
the issue (unless "title" is already enough for your needs). I've never
used this one in specific bug-based workflow, so I don't have first hand
experience to share.
This is, I think, the BTS has to offer to implement in-team workflow. I
find it to be pretty flexible, but I can't tell if it is to your liking
or not.
> If this is viable, or even without it, BTS could be used in order to get
> a better visibility, but I am unsure about any influence the BTS can
> have in speedup of listing. Just as an example: I don't think people
> will "fix bugs" sorted by submission date, so probably you'll have old
> requests still sitting there and new one already fixed.
Fair enough, but FWIW this was *not* the main goal. I think being "slow"
is acceptable as long as people (both submitters and fellow developers)
can observe the current status.
> What about having a public mailing list instead of BTS. It would solve
> the problem of visibility and probably (at least) permit to sort emails
> by date and check if any action has still to be done (grouping email
> with In-reply-to).
You're right, but if the maintainer backing a specific (pseudo)package
in the BTS already is a list, you have that too. AFAICT this is already
the case for the "www.debian.org" pseudo package.
Thanks for this interesting discussion,
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 »
Attachment:
signature.asc
Description: Digital signature