On 2017-12-23, Kapetanakis Giannis <bil...@edu.physics.uoc.gr> wrote: > On 23/12/17 12:24, Stuart Henderson wrote: >> Forwarded? No way! Same for bugs@ as tech@. It needs manual work to >> triage, identify what is a bug, follow up with the reporter to make >> sure the report is accurate and has enough information to be useful. >> Same whatever the entry point is. If reporters can add bugs to it >> directly, they need to go into a triage queue and *not* appear in the >> main system until that's done. >> >> The idea of a bug tracking system is to spread the work and help >> people remember things. It should *reduce* work done by devs because >> they no longer have to drag even the most basic information out >> of a reporter and figure out whether it's a bug or user error >> or a support request in disguise. >> >> If it means *extra* work for devs, it's not going to work. >> >> > > I still don't agree with you about maintaining both @tech/@bugs in > correlation with a web interface (bugtracking). > Not a gain, just extra trouble.
Probably not long term, but looking at existing unfixed bug reports on lists would be a good way to seed the database. And information spread across multiple mails can be synthesized into a coherent report, hopefully going some way to showing others what a proper bug submission should actually look like. > What happens in other places is that if a mail comes that looks like a > possible ticket (not resolvable by mail), someone replies and says > "please open bug report in https://..."; > so we can track it. > However you 're right with the last paragraph above and it's something I > haven't thought before. > More people might get involved and eventually this might get some work > out of the devs.
