[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Improved wiki tracking of active triagers and components (draft)

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


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


I have just finished integrating everything into a draft for your


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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]