Wiki suggestions

[Christopher Beland]

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:

http://fedoraproject.org/wiki/QA
http://fedoraproject.org/wiki/User:Johannbg/Draft/QA
https://fedoraproject.org/wiki/User:Leam
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.  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.


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.  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).


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.  There is still plenty of room for improvement.
I encourage other testers to read these pages if they haven't already,
and encourage everyone to make additions, especially of the type "If
you have a bug of type X, try doing Y yourself to diagnose the problem
before reporting it."

-- Beland