iarly selbir wrote:
I was talking about topic [4] last week, if I could add to my triage
list the same component that other Triager already have, this could be
point for next bugzappers meeting?
- ActiveTriagers and Components List ( who work where )
Regards,
- -
iarly selbir ( ski0s )
:wq!
On Sat, Feb 28, 2009 at 9:13 PM, Christopher Beland
<beland@xxxxxxxxxxxx <mailto:beland@xxxxxxxxxxxx>> wrote:
1.) In an effort to start cleanup, I merged
[[BugZappers/GettingStarted]] into [[BugZappers/Joining]] and cleaned
up links from the front page. [[BugZappers/HelpWanted]] should also
be trimmed and merged in there.
I also renamed [[BugZappers/TakingAction]] to [[BugZappers/How to
Triage]], so it has a clearer purpose.
2.) The subpages under [[BugZappers/HouseKeeping#Task_Breakdown]]
should probably be merged into the master page.
3.) [[BugZappers/components]] and [[BugZappers/FindingBugs]] are both
serving the dual purpose of tracking what needs to be worked on and
providing links to BugZilla to find bugs that need work. Any
objections to merging to [[BugZappers/Tracking]]?
4.) [[BugZappers/Joining]] and [[BugZappers/ActiveTriagers]] have
somewhat contradictory advice:
"This does mean certain components are reserved. If you are
unfamiliar with a component and someone is very active there, it is
probably a good idea to pick a different component."
vs.
"It is okay for more than one person to cover the same component"
We need to have clearer advice.
I also see that [[BugZappers/Special Procedures]] has a note arguing
that special opt-outs for certain developers are not scalable
I think it would actually be a good idea if we took the list at
[[BugZappers/components]] and merged in the list of people who are
working on a particular component. (Adding a second list for non
"key" components if people are claiming those.) The clearest
indication for new triagers would be to add a column to indicate for
each column whether or not more help is wanted for that component
("Yes") or if the existing triagers or developers think they have it
covered ("No"). But there are other ways to present this information.
5.) As for the other content on [[BugZappers/Special Procedures]],
[[BugZappers/How to Triage]] is the main instruction page, but we also
have [[BugZappers/BugStatusWorkFlow]] and lots of advice on
[[BugsAndFeatureRequests]] (which is oriented toward bug filers, not
bug triagers).
Clearly we need the One True List of Things Every Bug Should Have,
which filers should supply and triagers will request if they don't.
(This varies by component, and type of bug - e.g. crashes
vs. misspellings vs. feature requests.) The ASSIGNED section of
[[BugZappers/BugStatusWorkFlow]] has some of that info, which can be
removed and replaced with a link to the canonical place.
BugStatusWorkFlow can then just be an explanation of Bugzilla states.
[[BugZappers/How to Triage]] and [[BugsAndFeatureRequests]] then need
to be harmonized and streamlined. This is the crux of the problem of
making a minimal set of instructions that bug filers and triagers
can actually follow.
6.) [[BugZappers/Meetings]] and the front page don't mention that
Triage Days are held immediately after meetings. Has that been
decided for certain?
-B.
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx <mailto:fedora-test-list@xxxxxxxxxx>
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
My understanding has been that yes you can triage components that
someone else has chosen. For greatest triage impact it would be best to
choose components not already chosen, however, triage components you
feel most comfortable with.
This may change after the meeting Tuesday. I believe this is the correct
answer for now though. I know you've asked this question a number of
times now and not really received an answer.
Edward (TK009)
Fedora Partisan Ranger
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
