Toshio wrote:
> Jef, how would you feel if some bug day we had experienced QA'ers team
> with new QA'ers to nitpick packages? This could be a good first or
> second time QA experience: irc with a more experienced QA'er and pick
> apart the good and bad of a package. Or we could assemble a team of
> experienced QA'ers to do second reviews once a new user did the first
> one. This could be useful for a more advanced QA'er. Kinda have a
> short apprenticeship followed by a test what you know phase.
I strongly believe that a mentoring concept, can help the larger Fedora
effort turn users into contributors, better than that, creating
contributors and building a body of shared best practices through a
process of continuous self-examination of the process. Who learns more
about the subject when a lesson is taught...the teacher or the student?
Often times it can be the teacher. At least that's what I think.
But I am wary of doing exactly the sort of thing you have suggested..
prematurely. I really want to make sure there is a large enough group of
DEDICATED apprentice QA'ers to make sure the veterans do not feel like
making time to hold exactly that sort of irc session is a waste of their
time. I want to make sure the first one i weasel people into
participating in is worthwhile enough to build momentum and continued
interest in holding such events.
And frankly...i was waiting for someone else to suggest it....
because I don't think I have time to be the only community volunteer
thinking about and heading up exactly these sorts of experiments in
bridge building (and i would argue Red Hat as a managing entity needs to
hire someone, actually trained in exactly this sort of volunteer
management/coordination for these sorts of ideas to not fall through the
cracks and get lost). Let me state an essential truth, a lot of how
things are going to work in the new "fedora community" is about people
taking the initiative to state an idea AND follow through with it.
Basically...if you suggest an idea...you sort of own it..unless you are
clever and sneaky enough to convince someone else to take ownership of
the idea. I think your post proves I am clever and sneaky enough.....
> What I would like to see (for both QA and packager) is an RPM Best
> Practices Handbook. Accumulated wisdom about how to do things well
> organized by use cases with in depth justifications available as side
> passages for those who are curious why %{buildroot} and
> ${RPM_BUILD_ROOT} have such strong proponents on each side :-)
As interesting as this sounds as a historical non-fiction thriller novel
that I'd buy at the bookstore...i don't know how useful this would be to
a new QA'er. It would have some worth for the historical record....but
not much use as a functional educational document that re-enforces a
working process.
Let me instead suggest that what might be instructive are SHORT...
"anatomies of a QA review" case examples. A few good and a few bad
reviews that can highlight common issues...and that can suggest a
general flow of how things are suppose to work. A good example of this
sort of thing..is the Gnome Bugsquads triage examples.
http://developer.gnome.org/projects/bugsquad/triage/examples.html
I'd point to fedora triage examples...but we haven't gotten that far
yet. In fact, i could probably argue that building a set of case
examples would be VERY instructive to a small group apprentice QA'ers
almost as instructive as an active irc session with old-timers. And I
would argue that working on such a set of case examples would show a
level of dedication that might encourage established QA'ers to spend
time communicating more closely...which is what you sort of wanted in
the first place.
-jef"things would just go smoother if everyone would just agree now to
do my bidding without question or comment"spaleta
Attachment:
signature.asc
Description: This is a digitally signed message part
