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.
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@alum.mit.eduwrote:
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@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
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@alum.mit.edu mailto:beland@alum.mit.edu> 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@redhat.com <mailto:fedora-test-list@redhat.com> 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
TK009 wrote:
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.
I changed the admonition on the joining page. https://fedoraproject.org/wiki/BugZappers/Joining#How_to_Sign_Up
Is that better?
John
Could be a point sending a e-mail to fedora-test-list, for we know the new member interested in BugTriager, as has spoken here previously .
What you think?
Regards,
- - iarly selbir ( ski0s )
:wq!
On Thu, Mar 5, 2009 at 11:06 PM, John Poelstra poelstra@redhat.com wrote:
TK009 wrote:
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.
I changed the admonition on the joining page. https://fedoraproject.org/wiki/BugZappers/Joining#How_to_Sign_Up
Is that better?
John
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
John Poelstra wrote:
TK009 wrote:
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.
I changed the admonition on the joining page. https://fedoraproject.org/wiki/BugZappers/Joining#How_to_Sign_Up
Is that better?
John
I think it was the conflicting wording
https://fedoraproject.org/wiki/BugZappers/ActiveTriagers the note above the components list says: "*It is okay for more than one person to cover the same component" * while https://fedoraproject.org/wiki/BugZappers/Joining#How_to_Sign_Up says: *"If you are unfamiliar with a component and someone is very active there, it is probably a good idea to pick a different component or talk to that person and see if you can work together."
*TK009* *
So at the last IRC meeting, I was asked to combine
https://fedoraproject.org/wiki/BugZappers/components with https://fedoraproject.org/wiki/BugZappers/ActiveTriagers
and add a "Need Help" Yes/No column. Since I had already produced a draft combining
https://fedoraproject.org/wiki/BugZappers/FindingBugs with https://fedoraproject.org/wiki/BugZappers/components
I have just finished integrating everything into a draft for your approval:
https://fedoraproject.org/wiki/BugZappers/Tracking
I could redirect FindingBugs, components, and ActiveTriagers to this page if there is general consensus to do so, or I could merge only the latter two (with the contents of the "Component and Triager List" section) if that is preferred. Please indicate what you would support doing, or if there are any changes you would like to see.
Thanks!
Beland
Christopher Beland wrote:
So at the last IRC meeting, I was asked to combine
https://fedoraproject.org/wiki/BugZappers/components with https://fedoraproject.org/wiki/BugZappers/ActiveTriagers
and add a "Need Help" Yes/No column. Since I had already produced a draft combining
https://fedoraproject.org/wiki/BugZappers/FindingBugs with https://fedoraproject.org/wiki/BugZappers/components
I have just finished integrating everything into a draft for your approval:
https://fedoraproject.org/wiki/BugZappers/Tracking
I could redirect FindingBugs, components, and ActiveTriagers to this page if there is general consensus to do so, or I could merge only the latter two (with the contents of the "Component and Triager List" section) if that is preferred. Please indicate what you would support doing, or if there are any changes you would like to see.
Thanks!
Beland
I don't like the goals part. I am going to need another email for that as I have a lot to say. I like the new component/active triage/need help list. EOL versions, Blocker and Target Bugs, and Finding dupes doesn't belong on the page (IMO).
The redirecting of the goals page seems to have been premature, and BugZappers/Metrics looks like the start of recreating it. I liked the idea of combining the active triagers info with the components list, thought I must have missed that part in the meeting about also combining finding bugs and not sure it fits here.
I worry that to much its trying to be done with one page, and feel strongly goals don't belong here. Also please stop creating draft pages in the main wiki. You were asked by poelcat and myself not to do that, and reminded by adamw in an email. Create drafts in your user space. Please respect that policy.
As to making it "live", my vote is no (for now). Discussion at the meeting and time for feedback. I and I know others are thankful for the work you are putting in to whipping the wiki in to shape, but please understand changes need to be discussed and may not happen on your time schedule.
Edward (TK009)
The FindingBugs/components merger was in the e-mail I sent before the meeting; I don't think we had time to discuss it over IRC. But since it was related, I thought we could consider it now.
It sounds like you are voting for chopping the page back up into three bits, putting "Goals" back on its own page, keeping "Component and Triager List" here, and everything after that on FindingBugs? We can put links between all three pages for easy(er) navigation.
-B.
On Fri, 2009-03-06 at 14:32 -0500, TK009 wrote:
I don't like the goals part. I am going to need another email for that as I have a lot to say. I like the new component/active triage/need help list. EOL versions, Blocker and Target Bugs, and Finding dupes doesn't belong on the page (IMO).
The redirecting of the goals page seems to have been premature, and BugZappers/Metrics looks like the start of recreating it. I liked the idea of combining the active triagers info with the components list, thought I must have missed that part in the meeting about also combining finding bugs and not sure it fits here.
I worry that to much its trying to be done with one page, and feel strongly goals don't belong here.
Top posting is generally discouraged here :)
Christopher Beland said the following on 03/06/2009 01:58 PM Pacific Time:
The FindingBugs/components merger was in the e-mail I sent before the meeting; I don't think we had time to discuss it over IRC. But since it was related, I thought we could consider it now.
It sounds like you are voting for chopping the page back up into three bits, putting "Goals" back on its own page, keeping "Component and Triager List" here, and everything after that on FindingBugs? We can put links between all three pages for easy(er) navigation.
We should only add links if it makes sense in the context of what is presented. Our goal is not to make users aware of every possible BugZapper's page at each turn.
John
-B.
On Fri, 2009-03-06 at 14:32 -0500, TK009 wrote:
I don't like the goals part. I am going to need another email for that as I have a lot to say. I like the new component/active triage/need help list. EOL versions, Blocker and Target Bugs, and Finding dupes doesn't belong on the page (IMO).
The redirecting of the goals page seems to have been premature, and BugZappers/Metrics looks like the start of recreating it. I liked the idea of combining the active triagers info with the components list, thought I must have missed that part in the meeting about also combining finding bugs and not sure it fits here.
I worry that to much its trying to be done with one page, and feel strongly goals don't belong here.
Christopher Beland said the following on 03/06/2009 10:27 AM Pacific Time:
So at the last IRC meeting, I was asked to combine
https://fedoraproject.org/wiki/BugZappers/components with https://fedoraproject.org/wiki/BugZappers/ActiveTriagers
and add a "Need Help" Yes/No column. Since I had already produced a draft combining
At our last meeting we asked you to create DRAFT pages in your own namespace :) For example: https://fedoraproject.org/wiki/User:Beland/My_Draft
I think combining components and ActiveTriagers works really well. I'd stop there in terms of including any other content or purpose. I also do not think it is a good idea to maintain stats inside this page because of all the manual work to do it each week. Over time it will stop being updated and then the page will look stale. Metrics capture should be done in a central place where the data can be reported dynamically.
I'd propose calling the page: Components_To_Triage
https://fedoraproject.org/wiki/BugZappers/FindingBugs with https://fedoraproject.org/wiki/BugZappers/components
I have just finished integrating everything into a draft for your approval:
Please create draft pages in your own namespace. This particular title is confusing, particularly when referring to BugZapper/Trackers from the same page.
I could redirect FindingBugs, components, and ActiveTriagers to this page if there is general consensus to do so, or I could merge only the latter two (with the contents of the "Component and Triager List" section) if that is preferred. Please indicate what you would support doing, or if there are any changes you would like to see.
I do not think we are ready for redirects until our overall redesign is done. Redirects should be used to route around pages that are completely dead or not used vs. combining a bunch of pages into one.
As you can probably tell by now I am very against long wiki pages that scroll for ever and cover a multitude of topics. Short and to the point is my preference and I think works best in terms of not overwhelming new people. I have also found that breaking them into logical pieces by topic makes them easier to maintain over time.
So I think it continues to make sense to have one wiki page whose sole focus is to tell people all the different ways to find bugs. This makes a nice catch-all to link to from other pages when you need to provide suggestions on locating bugs. It is also a lot nicer for people when they follow that link to only receive information on the topic they were interested in knowing more about... versus being bombard the user with 5 other un-related topics which is what I think happens with the proposed "Tracking" page.
John
On Mon, 2009-03-09 at 10:02 -0700, John Poelstra wrote:
At our last meeting we asked you to create DRAFT pages in your own namespace :) For example: https://fedoraproject.org/wiki/User:Beland/My_Draft
I will do so in the future, but for this page I was simply updating a draft that already existed.
I do not think we are ready for redirects until our overall redesign is done. Redirects should be used to route around pages that are completely dead or not used vs. combining a bunch of pages into one.
Well, Wikipedia convention is to leave redirects behind whenever pages are merged or moved, in case there are still external links or bookmarks to the old URLs. I don't see much of a downside to them.
But I think that's three votes now for splitting back up into Goals, Components to Triage, and Finding Bugs.
I also do not think it is a good idea to maintain stats inside this page because of all the manual work to do it each week. Over time it will stop being updated and then the page will look stale. Metrics capture should be done in a central place where the data can be reported dynamically.
That would be lovely, but at the moment as far as I know, we have no scripts capable of doing so.
-B.
TK009 said the following on 03/06/2009 08:10 AM Pacific Time:
John Poelstra wrote:
TK009 wrote:
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.
I changed the admonition on the joining page. https://fedoraproject.org/wiki/BugZappers/Joining#How_to_Sign_Up
Is that better?
John
I think it was the conflicting wording
https://fedoraproject.org/wiki/BugZappers/ActiveTriagers the note above the components list says: "*It is okay for more than one person to cover the same component"
while https://fedoraproject.org/wiki/BugZappers/Joining#How_to_Sign_Up says: *"If you are unfamiliar with a component and someone is very active there, it is probably a good idea to pick a different component or talk to that person and see if you can work together."
*TK009*
How about if we remove "*It is okay for more than one person to cover the same component" for now ?
John
John Poelstra wrote:
TK009 said the following on 03/06/2009 08:10 AM Pacific Time:
John Poelstra wrote:
TK009 wrote:
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.
I changed the admonition on the joining page. https://fedoraproject.org/wiki/BugZappers/Joining#How_to_Sign_Up
Is that better?
John
I think it was the conflicting wording
https://fedoraproject.org/wiki/BugZappers/ActiveTriagers the note above the components list says: "*It is okay for more than one person to cover the same component"
while https://fedoraproject.org/wiki/BugZappers/Joining#How_to_Sign_Up says: *"If you are unfamiliar with a component and someone is very active there, it is probably a good idea to pick a different component or talk to that person and see if you can work together."
*TK009*
How about if we remove "*It is okay for more than one person to cover the same component" for now ?
John
We need to remove one of them for sure. I see no issue with removing "*It is okay for more than one person to cover the same component". I have one question though, does the *"If you are unfamiliar with a component and someone is very active there, it is probably a good idea to pick a different component or talk to that person and see if you can work together." fit best where it is or would it better in place of the "*It is okay for more than one person to cover the same component"?
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.
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
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 :)
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.
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.
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
-
Christopher Beland -
iarly selbir -
John Poelstra -
TK009