Proposed directions for proven testers

[Aaron Faanes]

On Fri, Jun 18, 2010 at 2:14 PM, Adam Williamson <awilliam at redhat.com> wrote:
> On Thu, 2010-06-17 at 23:05 -0500, Aaron Faanes wrote:
>
>> I worked on this draft a bit on my own user-page. Specifically, I
>> wikified some of the links and heavily edited the overview paragraph.
>> I'm not an expert by any means on the proven-testers proposal, so I
>> might have introduced inaccuracies. Here's the link:
>>
>> https://fedoraproject.org/wiki/User:Dafrito/Draft_proventesters_instructions#Testing_process
>
> I definitely think your version is an improvement on mine, thanks very
> much. I'd say let's consider this the current working draft for now.
>
>> I wonder if the article would read better by shaping the article
>> around responsibilities directly. Each responsibility might be a
>> separate section. Here's an example:
>>
>> Overview
>> Responsibilities
>> - Find & install updates to test (Explain updates-testing, Bodhi,
>> --enablerepo, etc.)
>> - Ensure minimum required functionality (Explain release criteria,
>> critpath actions)
>> - Investigate problematic updates (Explain techniques?)
>> - Report karma to Bodhi, and Bugzilla if necessary (Explain karma rules)
>
> This seems to be how you've done it in your current draft, and I like
> that.
>
>> On the other hand, if it seems like these responsibilities share a lot
>> of information, then the separate sections could instead become bullet
>> points under a 'Responsibilities' section. The shared infomration
>> would then become separate sections:
>>
>> Overview
>> Responsibilities
>> Getting Updates (ways to enable updates-testing)
>> Criteria
>> - release criteria
>> - critpath actions
>> Tools
>> - fedora-easy-karma
>> - bodhi
>>
>> This might be too article-centric. If the goal of the page is to
>> strictly define proven-testers, then a step-by-step outline makes more
>> sense. However, linear instructions imply strict adherence, and there
>> seems to be a lot of flexibility in how proven-testers can/should
>> work.
>>
>> I'd be happy to continue working on this by implementing one of the
>> outlines above on my draft, or by doing something entirely different,
>> too! I just figured I'd throw some ideas out before I got ahead of
>> myself. :)
>
> I'm pretty pleased with your current draft, but if you like the second
> one better, that's cool too. Or you could draft both and we could pick
> which we like. =)

I'm kind-of liking the first one better, too. I think it emphasizes
the responsibilities more clearly. We might run into an issue if we
skim it down too much, but we'll see. :)

> I think the 'Investigate & provide feedback' section could be
> streamlined a little - with your nicer framework, some of the content is
> duplicated or unnecessary and can be trimmed.

I agree, that section could use some love. It seems to have a lot of
information, though. I sketched out a possible outline:

Typical Scenarios
- Major bug - Report, vote down
- Minor bug - Report, vote up/neutral
- Previously reported bug - Confirm, vote accordingly
Unusual Scenarios
- Unreproducible bug
- Unfamiliar package

It's possible we'd drop this outline into a separate section from
Responsibilities, and just leave the "Investigate" section to briefly
describe what needs to be done.

>Do you mind if I make some edits to achieve this? Thanks again!

Not at all! Go right ahead. You can copy it to yours if you want, or
to another page; I don't have a preference.

I really appreciate your feedback! I'll try to work on it more
tonight, and if not, then definitely tomorrow.

-- Aaron Faanes

> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
> http://www.happyassassin.net
>
> --
> test mailing list
> test at lists.fedoraproject.org
> To unsubscribe:
> https://admin.fedoraproject.org/mailman/listinfo/test
>