Wiki suggestions

["Jóhann B. Guðmundsson"]

Christopher Beland wrote:

An introduction would be nice.
> As someone who has been filing bugs for a long time but who is new to
> this mailing list, I have some suggestions regarding wiki page
> cleanup.
>
> I see four "main" QA pages floating around:
>
>   
This is the official one
> http://fedoraproject.org/wiki/QA
>   
This is the approved replacement
> http://fedoraproject.org/wiki/User:Johannbg/Draft/QA
>   
This is a new idea.
> https://fedoraproject.org/wiki/User:Leam
>   
And if i'm not mistake this is old one from moin?
> http://fedoraproject.org/wiki/SIGs/QA
>
> First of all, some clarity is needed whether BugZappers and QA are
> "subprojects" or a "SIGs", and [[SIG/QA]] should be merged with [[QA]]
> and its subpages.
>
>   
> The User:Leam page is intended as a destination for a link from
> http://fedoraproject.org/wiki/Join. 

Leam's page is to formal seems more directed at QE' s then an new linux 
user
that might have the dream or just wanting to try out testing or triaging

Any mention on certification a degree in any form or way or reference to 
coding
and from my perspective my scare people away instead of encourage them 
to join.

>  I think it would be a good idea
> to add a "Tester" role to [[Join]], since "OS Developer" to me means
> someone who can write or edit code, but there is plenty of work to be
> done by people who only do testing.  I guess a new table could be
> added for that role, with specific tasks, but I don't think there's a
> need for an entirely separate page just for new volunteers.  The
> "Testing" link points to [[QA]], and making that the one-stop shop for
> "what's up with this subproject" seems like a good idea to me.
>
>   
There already is work in creating a QA joining page
( which is missing from the http://fedoraproject.org/en/join-fedora )
> To be honest, I prefer the current copy of
> http://fedoraproject.org/wiki/QA to the Johannbg draft.  Splitting up
> activities into "Quality Control", "Quality Assurance" and
> "Development" does not seem helpful, especially since "Quality
> Control" and "Quality Assurance" sound like synonyms to many people,
> and the latter has no content in that draft.
>   And as far as I can
> tell, "Development" (actually fixing bugs) is outside the scope of the
> QA subproject.  
Well you clearly did not understand this page correctly which just means 
I failed my task
and need rewrite the whole thing again.
> This is what [[Package Maintainers]] does.
> [[Development]] is also something of a mess; [[QA]] is listed as a
> subset, along with [[PackageMaintainers]] and (implicitly)
> [[ReleaseEngineering]].  This page should probably just go away.
>
> The most important thing for [[QA]] to do is clearly list all of the
> activities of the subproject on one page, so volunteers can find tasks
> of interest, and the content for everything is really easy to find.
> As far as I can tell, this is what people do now or want to be able to
> do:
>
> Documented by [[BugZappers]]:
> * Bug Triage: Examine bugs reported by other people and resolve
>   duplicates, incomplete reports, and other problems to save time for
>   [[PackageMaintainers]].  This is coordinated at the independent
>   [[BugZappers]] subproject, which shares the fedora-test-list mailing
>   list.
>
> Documented by [[Testing]] and [[BugsAndFeatureRequests]]
> * Post-release testing: Run or install Fedora 9 or 10 and report bugs
>   either as you find them spontaneously or while intentionally testing
>   a particular component.
> * Update pre-release testing: Run newly-built software from the Fedora
>   9 or 10 updates-testing repositories and report problems or approval
>   for general public release in Bodhi.
> * Rawhide testing: Run or install Fedora 11 Rawhide (updated daily)
>   and report bugs as you find them spontaneously or while
>   intentionally testing a particular component.
>
> Systematic QA:
> * Re-testing on request: Test bugs labelled NeedsRetesting.
> * Systematic manual testing: Use one of the test plans listed at
>   [[QA/TestPlans]] to perform a specific list of tasks and report any
>   bugs found.  Especially important when alpha, beta, and release
>   candidate installers are released.
> * Semi-automated testing: Run QA scripts and file problems in Bugzilla. 
> * Develop automated and semi-automated tools for QA testing - see
>   [[Beaker]], [[Automated QA Testing Project]], etc.
>
> Events:
> * [[QA/Test Days]]
>
> Documented in other SIGs: 
> * Font testing
> * Documentation testing
> * etc...
>
> I'm not sure that "Stream Liasion" as described in the Leam draft is
> distinct from these processes, since there are a variety of reasons to
> engage in testing, and different people will naturally focus on
> different components.
>
> I assume Adam is taking the lead on updating the main QA wiki pages,
> so I haven't implemented these suggestions myself (and I didn't feel
> comfortable doing so unilaterally).
>
>   
The process so far is that people create drafts then they are review and 
the community reaches
conscious.
> I found these pages:
>
> https://fedoraproject.org/wiki/Testing
> https://fedoraproject.org/wiki/BugsAndFeatureRequests
>
> exceedingly useful in answering questions that testers like me have,
> such as, "when should I use the mailing list vs. filing a bug report"
> and "what should I put in reports for this type of bug"?  
>
> Just now, I signed up for an account and did some tidying up to make
> these pages clearer.  
Do not edit the official wiki pages directly and if you did either on 
those you mentioned
and potentially any others that you might have made some changes to 
please revert those changes asap.

You might upset a lot of people of  if you altered any of the official 
wiki pages

JBG.