No subject
Fri Jul 20 17:26:04 UTC 2012
a new Bugzapper than being a new general QA volunteer for Fedora.
Besides the cool name, what causes this?
While I am not a Bugzapper, it would seem to me that QA runs on strict
cycles. A new build comes out, and everyone is asked to test it in a
timely manner. A test day for X is held on day Y and if you are not
available on Y (give or take a day) you may feel that no one will look at
your results.
Meanwhile a Bugzapper sounds like they do not have to install anything if
they do not want to verify a fix. They can go through Bugzilla at their
leisure. Their changes appear in realtime and they can immediately feel
they made a difference.
But given I primarily work on a downstream Fedora Remix, there is only so
much time I have to do upstream QA. It takes time to research each update
fedora-easy-karma says needs feedback so I can determine if I can
personally test the fix(es). And there is no guarantee that what I do
makes a difference; many updates get pushed because someone says "works for
me" or the maintainer pushes on a timeout.
Most times when I file ABRT reports it seems like I hit duplicates.
So how can we get people involved with Fedora QA and make them feel good
about it? Unfortunately I do not have a good answer. I agree with your
comments about advertising and trying to better explain how long it takes
to do individual tasks. But I personally wouldn't see virtualization as
"Kind of Easy".
---
SJG
On Thu, Aug 23, 2012 at 3:56 AM, Robyn Bergeron <rbergero at redhat.com> wrote:
> On 08/23/2012 01:07 AM, Adam Williamson wrote:
>
>> On 2012-08-22 19:18, Arnav Kalra wrote:
>>
>>> Maybe you can try making a simple SQL database in which people post
>>> their results. It should have different tables for different test
>>> days. This would allow you to easily sort the data and would not be
>>> very difficult to implement.
>>>
>>> The advertisement part is easy to do but I think your main problem is
>>> collection of data and making that data easily accessible to users.
>>>
>>
>> It...really isn't that simple, unfortunately. I wrote an overview a few
>> days back on devel@, so I'll just link to that:
>>
>> https://lists.fedoraproject.**org/pipermail/devel/2012-July/**170437.html<https://lists.fedoraproject.org/pipermail/devel/2012-July/170437.html>
>>
>> The 'edit your results into a wiki table' approach certainly isn't the
>> perfect answer to managing test day results, but making it better is a more
>> complex problem than it might appear. In practice, I don't think it's
>> something that's a massive dampener on people's willingness to participate
>> in test days, though we don't really have any evidence either way on that,
>> so it all comes down to gut feeling...
>>
>
> Yeah, I feel like the wiki isn't really a barrier, except maybe from the
> point of view of someone who might be interested and just sees a reallllly
> long list (speaking more to TC/RC testing, not really test days) and is
> overwhelmed and runs.
>
> Advertisement may be easy but a lot of it really has to do with being able
> to keep the person captive who was already interested when they clicked the
> link. Maybe it's worth thinking about having something in the InfoBox on
> the wiki that says "how easy it is" - maybe with some sort of matching page
> of criteria for 3 or 4 levels of ease - SuperEasy being "I can boot from a
> USB key into a desktop", Kind of Easy being "I can boot from a USB key into
> a desktop and also use virtualization," etc.
>
> And then going back to ... well, stuff that crosses over to thinks
> marketing could maybe help with, and would be useful when doing the actual
> advertising... "New to testing? Watch this shiny 5-minute video," "Why is
> testing important?" ... "How you can help out in XXX minutes or less,"
> kind of stuff. I think people often are willing to do things, and are
> looking for short-duration ways to help out, and maybe they aren't aware
> that test days or validation tests can be a good place to do that. Or they
> don't know when getting to the test day page, or test matrix, if they're
> going to need 20 minutes, or a day.
>
> Maybe something to do would be to work with infra around the time of the
> next test day or even as we move towards another RC test round, and as we
> advertise in our normal ways (ie: QA folks blog that it's happening) see if
> we can figure out how many times the wiki page is being accessed - if we're
> getting lots of hits but not a lot of turnout, maybe it's confusing, but if
> we're not getting hits, maybe it's just that we're not making enough noise,
> or the same people see it many times and sort of phase it out.
>
> -r
>
>
>
> --
> test mailing list
> test at lists.fedoraproject.org
> To unsubscribe:
> https://admin.fedoraproject.**org/mailman/listinfo/test<https://admin.fedoraproject.org/mailman/listinfo/test>
>
--e89a8fb203fa1de2f604c7eb7cc7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I think there is a more fundamental issue.<br><br>From casual observation, =
it seems that more people like announcing they are a new Bugzapper than bei=
ng a new general QA volunteer for Fedora.<br><br>Besides the cool name, wha=
t causes this?<br>
<br>While I am not a Bugzapper, it would seem to me that QA runs on strict =
cycles.=A0 A new build comes out, and everyone is asked to test it in a tim=
ely manner.=A0 A test day for X is held on day Y and if you are not availab=
le on Y (give or take a day) you may feel that no one will look at your res=
ults.<br>
<br>Meanwhile a Bugzapper sounds like they do not have to install anything =
if they do not want to verify a fix.=A0 They can go through Bugzilla at the=
ir leisure.=A0 Their changes appear in realtime and they can immediately fe=
el they made a difference.<br>
<br>But given I primarily work on a downstream Fedora Remix, there is only =
so much time I have to do upstream QA.=A0 It takes time to research each up=
date fedora-easy-karma says needs feedback so I can determine if I can pers=
onally test the fix(es).=A0 And there is no guarantee that what I do makes =
a difference; many updates get pushed because someone says "works for =
me" or the maintainer pushes on a timeout.<br>
<br>Most times when I file ABRT reports it seems like I hit duplicates.<br>=
<br>So how can we get people involved with Fedora QA and make them feel goo=
d about it?=A0 Unfortunately I do not have a good answer.=A0 I agree with y=
our comments about advertising and trying to better explain how long it tak=
es to do individual tasks.=A0 But I personally wouldn't see virtualizat=
ion as "Kind of Easy".<br>
<br>---<br>SJG<br><br><br><div class=3D"gmail_quote">On Thu, Aug 23, 2012 a=
t 3:56 AM, Robyn Bergeron <span dir=3D"ltr"><<a href=3D"mailto:rbergero@=
redhat.com" target=3D"_blank">rbergero at redhat.com</a>></span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div class=3D"im">On 08/23/2012 01:07 AM, Adam Williamson wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On 2012-08-22 19:18, Arnav Kalra wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Maybe you can try making a simple SQL database in which people post<br>
their results. It should have different tables for different test<br>
days. This would allow you to easily sort the data and would not be<br>
very difficult to implement.<br>
<br>
The advertisement part is easy to do but I think your main problem is<br>
collection of data and making that data easily accessible to users.<br>
</blockquote>
<br>
It...really isn't that simple, unfortunately. I wrote an overview a few=
days back on devel@, so I'll just link to that:<br>
<br>
<a href=3D"https://lists.fedoraproject.org/pipermail/devel/2012-July/170437=
.html" target=3D"_blank">https://lists.fedoraproject.<u></u>org/pipermail/d=
evel/2012-July/<u></u>170437.html</a><br>
<br>
The 'edit your results into a wiki table' approach certainly isn=
9;t the perfect answer to managing test day results, but making it better i=
s a more complex problem than it might appear. In practice, I don't thi=
nk it's something that's a massive dampener on people's willing=
ness to participate in test days, though we don't really have any evide=
nce either way on that, so it all comes down to gut feeling...<br>
</blockquote>
<br></div>
Yeah, I feel like the wiki isn't really a barrier, except maybe from th=
e point of view of someone who might be interested and just sees a realllll=
y long list (speaking more to TC/RC testing, not really test days) and is o=
verwhelmed and runs.<br>
<br>
Advertisement may be easy but a lot of it really has to do with being able =
to keep the person captive who was already interested when they clicked the=
link. =A0Maybe it's worth thinking about having something in the InfoB=
ox on the wiki that says "how easy it is" - maybe with some sort =
of matching page of criteria for 3 or 4 levels of ease - SuperEasy being &q=
uot;I can boot from a USB key into a desktop", Kind of Easy being &quo=
t;I can boot from a USB key into a desktop and also use virtualization,&quo=
t; etc.<br>
<br>
And then going back to ... well, stuff that crosses over to thinks marketin=
g could maybe help with, and would be useful when doing the actual advertis=
ing... "New to testing? Watch this shiny 5-minute video," "W=
hy is testing important?" ... "How you can help out in XXX minute=
s or less," =A0kind of stuff. =A0I think people often are willing to d=
o things, and are looking for short-duration ways to help out, and maybe th=
ey aren't aware that test days or validation tests can be a good place =
to do that. =A0Or they don't know when getting to the test day page, or=
test matrix, if they're going to need 20 minutes, or a day.<br>
<br>
Maybe something to do would be to work with infra around the time of the ne=
xt test day or even as we move towards another RC test round, and as we adv=
ertise in our normal ways (ie: QA folks blog that it's happening) see i=
f we can figure out how many times the wiki page is being accessed - if we&=
#39;re getting lots of hits but not a lot of turnout, maybe it's confus=
ing, but if we're not getting hits, maybe it's just that we're =
not making enough noise, or the same people see it many times and sort of p=
hase it out.<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
-r</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
-- <br>
test mailing list<br>
<a href=3D"mailto:test at lists.fedoraproject.org" target=3D"_blank">test at list=
s.fedoraproject.org</a><br>
To unsubscribe:<br>
<a href=3D"https://admin.fedoraproject.org/mailman/listinfo/test" target=3D=
"_blank">https://admin.fedoraproject.<u></u>org/mailman/listinfo/test</a></=
div></div></blockquote></div><br>
--e89a8fb203fa1de2f604c7eb7cc7--
More information about the test
mailing list