Hi all, 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.
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. 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. 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. And, about periodic check: should we open a new bug every two years in order to made visible that new actions are taken in order to check emails or URL? I am interested in a way to also let's this kind of operation visible. 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). Bye, Giuseppe -- To UNSUBSCRIBE, email to debian-www-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1315659113.5057.37.camel@scarafaggio
