On Fri, Jun 18, 2010 at 2:14 PM, Adam Williamson <awilliam@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe: > https://admin.fedoraproject.org/mailman/listinfo/test > -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
