John Poelstra wrote:
Thanks for all your hard work to make these pages cleaner. I am a
little concerned that you are moving very quickly and in some cases
making some drastic changes :) I do appreciate that you are keeping
us updated here.
It is often a good idea when making large changes like this to create
your own draft and so the group can look at it first.
I am concerned with the speed of the changes as well. Another reason to
discuss before any drastic changes are made is that others may also be
working on updating the wiki. This will prevent duplication or waste of
effort. Redirecting or re-naming pages are drastic change IMHO and need
to be discussed and given time for feedback before being implemented live.
It may not look like it but what we have was a result of a lot of
rework and discussion a year ago of what using material from the years
before the current group got involved with triage. What this means is
that in some cases we should probably take a big step back rewrite
some of the pages from scratch instead of continuing to roll the
content forward, merge it into different pages, etc.... which is what
we did a year ago :)
What might help most is to create a site map of sorts and do a layout
design so we have a larger view of
I agree, our little corner of the wiki needs a complete overhaul. I
think everyone agrees on this point. The wiki needs a complete rewrite,
the "site map" idea is the right way forward. Let's think strategically
instead of reacting with tactically expedient fixes.
Christopher Beland 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.
I disagree. The main page was too big and was intentionally broken
down this way. Breaking the tasks up makes it easier to maintain.
Having spent a week reworking this section I'd be sad to see it all
reverted unless other people think it would work better a different way.
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]]?
Yes, but your redirect of Goals-->Components didn't help make things
any cleaner. This is why we need to discuss and coordinate some of
these changes :)
Christopher was correct when he pointed out the old goals page was
"crusty" I think it was, it was! I have to disagree with the redirect
change though for the same reason poelcat point out. Also I am not sure
that description of the goal is really the goal we already agreed upon
the week before. I really should have worded it better in the meeting
recap email, an error on my part.
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"
Every time I see that I want to remove it. It is confusing and if not
for poelcat's comment on discussion below I probably would have after
reading that. To me that is a minor change and one I would have advised
of changing but not thought needed discussion.
We need to have clearer advice.
Let's discuss at our meeting on Tuesday
I also see that [[BugZappers/Special Procedures]] has a note arguing
that special opt-outs for certain developers are not scalable
Yes, those comments were mine. I think this page should should go away.
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.
Yes, as long as we have two separate pages as they are two different
tasks.
Please don't make any more major changes to the wiki. Create a draft,
and give some time for your fellow team members to give their input on
the changes you'd like to make.
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
