Re: Suggestion for the organization of QA work
Hi Adrian,
I like the idea of setting up more structure for QA. Overall there are
many things that can be done in QA with differing levels of impact to
users's experience. Coordinating this should be very helpful.
http://qa.debian.org/documentation/qas.html/
Adrian, would you consider your proposal an extension to what is displayed
on the QA pages? You know, I've been on this email list awhile now and I
still don't know if that is just a proposal from Feb 2000 or has it become a
reality. I assume it wasn't assigned to real people yet.
* Adrian Bunk <bunk@fs.tum.de> [011122 10:43]:
> Hi,
>
> I'd like to hear your opinion on the following proposal:
>
> Currently QA works the way that people find something to do themselves and
> everyone works for himself at the tasks he sees. I propose to change this
> to define tasks of QA work with usually 2-3 people responsible for each
> area. These people responsible can do the work either themselves or by
> organizing that it gets done (e.g. by organizing bug-squashing parties).
>
> advantages:
> - it's clear who's responsible for what
> - it's more easy to find other people helping (I remember that sometimes
> people come that say they are interested in QA work) when you can say
> "We are looking for someone to help with xyz."
>
>
> A first proposal for tasks:
>
> - fixing bugs
> * try to fix bugs (especially RC bugs (but not limited to RC bugs!))
> e.g. via bug-sqaushing parties
> * find MIA maintainers (could be separated out, but my experience is
> that you find most MIA maintainers when going through bugs)
>
> - send bug reports for uninstallable packages, unsatisfied
> recommends/suggests and priority problems in unstable
> * the problems are listed at [1]
>
> - problems with testing
> * e.g. find problems why packages don't go into testing
> (there are sometimes long dependencies that prevent a package from
> getting into testing; it seems that some big library updates are
> nearly impossible without manual interaction)
In a more generalized way, you might want to consider having QA "leads"
or contacts for each distribution: stable, testing, unstable. This might
be as simple as somone who is on (for example) the debian-testing and
debian-qa lists that passes information when appropriate.
> - failed builds
> * on some archs there aren't enough people to go through all logs of
> failed builds to check whether they are problems in the autobuilder or
> to send bug reports
"Leads" for each port would be appropriate. Minimal requirements would be
simple enough to fulfill, and it would give the people stepping into those
positions an incentive to help out a little more if they are recognized.
> - WNPP
> * maintain the WNPP bugs and the orphaned packages
Bas Zoetekouw's work on this has been excellent.
- QA website updates
> I'd like to hear your opinion on:
> 1. the proposal
> 2. my suggestion of the tasks (e.g. did I miss tasks?)
When thinking about QA, I feel it's important to try to understand what
issues people are having. Ultimately, it's the users that benefit from the
work done in QA.
In this project, QA can even be seen as "free support." Care needs to be
taken in how this reality is presented, but I think it's true.
--
-- Grant Bowman <grantbow@svpal.org>
Reply to: