On Mon, 2010-01-25 at 01:00 -0500, Christopher Beland wrote: > On Tue, 2010-01-12 at 11:13 -0500, James Laska wrote: > > * jlaska to reach out to beland for guidance/ideas on how to > document > > the process (or point to existing documentation) for how bugs are > > noted > > (common_bugs, release notes, install guide etc...) How to determine > > which bugs land in which place > > I'm not sure why my name came up, but here's my take on the question: > > It's clear that any unintentional "known issues" need to get added to > Common Bugs, and that page is already self-documenting: > https://fedoraproject.org/wiki/Bugs/Common#My_bug_is_not_listed > > There's only one area which might be improved - CommonBugs keyword. > Is > there are particularly good workflow reason why it exists? Does > someone > come through periodically and check to see if all the bugs tagged with > this keyword are actually listed on the wiki page? Does it motivate > developers to see this keyword? Discussed at the meeting, but to recap - yes, jlaska and I periodically check CommonBugs-marked bugs. It doesn't really exist to motivate developers (though if it does, that's an added bonus). It mainly exists for two reasons: as a way to request a bug be added to CommonBugs if you don't want to do it yourself (and also for people who edit CommonBugs to make a quick 'mental note' to add a bug in future), and it also helps if, say, you're subscribed to a bug, see that it gets fixed, and then notice that it's marked CommonBugs with a URL, so there's a Common Bugs entry which should be updated to reflect that the bug's been fixed. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
