Future of Bugdays
ashughes
the way of the Dodo. I've written a fairly detailed blog post about
why I think this is a BAD idea. I don't expect that you'll agree with
everything I said -- it is all just my point of view as someone who
has sat on both sides of the fence (Bugday organizer and Bugday
contributor). The purpose of this is to get my opinion out there in
the hopes that it will spur some healthy discussion. The end result,
I hope, will be the first step in getting a solid plan in place to
revitalize and better utilize Bugdays as a tool to improve the quality
of Firefox.
Please post all feedback, questions, comments, and rebuttals here.
I'll post a link to the blog post following this message.
Cheers!
Anthony Hughes
Jr Quality Engineer, Mozilla QA
IRC: ashughes
ashughes
http://ashughes.com/?q=node/130
You should also find it on planet shortly.
Happy discussing!
ashughes
attitude I think QA SHOULD be taking toward Bugdays.
-----
Submitted by Luis Villa on Mon, 05/10/2010 - 23:29.
I can pretty plainly say that I owe my career (law school and all,
believe it or not) to bug days, so I'm clearly in favor of them. What
we found in GNOME was that the short-term payoff might be low, but the
long-term payoff of the 'face-to-face' interaction of bugdays was
huge- the people who came in through that route became deeply involved
in, and eventually leaders of, the GNOME community. I imagine there
are at least a handful of similar stories in Mozilla. It certainly
can't hurt to tweak things from time to time (and perhaps merge with
testdays?) but this should be one of the lowest-barrier-to-entry ways
to get involved in Mozilla, and as such should be hugely important to
the health of the community.
Really, given Diederik's brown bag at the office a few weeks ago (see
in particular slide 13 of this set) you'd think QA would be launching
an aggressive push to make bugdays better, not thinking about
canceling them altogether.
But I'm just an emotionally attached alum, not a current participant,
so maybe there is something I'm missing?
ashughes
> in particular slide 13 of this set) you'd think QA would be launching
> an aggressive push to make bugdays better, not thinking about
> canceling them altogether.
>
http://www.slideshare.net/dvanliere/how-shallow-is-a-bug-how-open-source-communities-help-fix-bugs
Asa Dotzler
> It was recently brought to my attention that Bugdays could be going
> the way of the Dodo. I've written a fairly detailed blog post about
> why I think this is a BAD idea.
> Please post all feedback, questions, comments, and rebuttals here.
From the guy that invented bugdays more than a decade ago, I'd just
like to chime in with my initial thought after reading your blog post:
*WTF!?!*
Who on Earth is pushing for ending bugdays? That's insanity.
Your post covers more than enough to demonstrate the value of and the
need to revitalize bugdays. Where is the post explaining the upside to
ending this program?
The suggestion that we should kill the most effective entry point to the
project ever (empirically provable with a quick survey of our core
developer and qa communities over the last 11 years -- both paid and
voluteer staff) blows my mind.
There is no way that the Mozilla of today, with nearly 300 full-time
employees, is so under-resourced that it can't dedicate a day of paid
staff each week to maintain and grow this invaluable program.
Seriously, WTF?
- A
ashughes
the "architect".
> Your post covers more than enough to demonstrate the value of and the
> need to revitalize bugdays. Where is the post explaining the upside to
> ending this program?
You don't find this point of view in my post because I am in full
support of keeping bugdays and improving them. The counter point
(scrapping bugdays) is not a view point I share, so it is not one that
I can openly and honestly comment on. I do, however, invite those who
share this counter point to chime in and make their reasons known. I
want everyone involved in this discussion -- otherwise, it's just
preaching to preachers.
ashughes
>
>> On Tue, May 11, 2010 at 1:44 AM, ashughes <anthony....@gmail.com> wrote:
>> It was recently brought to my attention that Bugdays could be going
>> the way of the Dodo.
>>
> unnamed attention-bringer when you presented your case to them
> directly?
>
> So far this is about a strawman, which doesn't seem like a productive
> way to discuss how we invest in bug days in the future.
>
> Mike
Out of respect for the party (or parties), I'd prefer not to call them
out. I'd much rather have them chime in on this thread under their
own volition. Rest assured, there are REAL people on both sides of
this discussion (even though it appears to be very one sided at this
point).
Benjamin Smedberg
> It was recently brought to my attention that Bugdays could be going
> the way of the Dodo. I've written a fairly detailed blog post about
> why I think this is a BAD idea. I don't expect that you'll agree with
> everything I said -- it is all just my point of view as someone who
> has sat on both sides of the fence (Bugday organizer and Bugday
> contributor). The purpose of this is to get my opinion out there in
> the hopes that it will spur some healthy discussion. The end result,
> I hope, will be the first step in getting a solid plan in place to
> revitalize and better utilize Bugdays as a tool to improve the quality
> of Firefox.
I really haven't ever participated in bugdays, and as a developer I haven't
directly experienced their usefulness. I sometimes see things go by about
how we're going to have a bugday to close out old bugs, reduce the
UNCONFIRMED bug list, and such like that. In general, bugdays of that sort
feel like makework, and my impression is that they are a lot of work for
little effective gain.
Perhaps we should turn the question around: assuming we do have bugdays,
what activities are most useful and would most benefit the project?
One of the things that I think would be most useful is getting a group of
people who can help shepherd bugs through the system. This includes at least
the following steps:
* Triage of new incoming bugs in Core:General and Firefox:General into
appropriate components and especially cc'ing the right people
* Finding older bugs where the bug had a patch bug review was never
requested or was requested of an inactive reviewer, and finding the right
reviewer
* Creating reliable steps to reproduce bugs
* Finding regression ranges for bugs
* Writing and condensing testcases for bugs
* Finding bugs with reviewed patches which were never committed (adding
checkin-needed, or being even more proactive and just committing them)
In some cases we'll have big projects such as the HTML5 parser,
out-of-process plugins, new extension manager, etc, and bugdays can help
with these projects even more specifically: looking through new bugs in
those components, nominating important bugs to block the relevant releases.
--BDS
Mike Shaver
<benj...@smedbergs.us> wrote:
> Perhaps we should turn the question around: assuming we do have bugdays,
> what activities are most useful and would most benefit the project?
I think it's probably better to turn it in another direction:
What are the benefits we hope or expect to get from bugdays? Are
bugdays the best way for us to invest in getting some/all/none of
those benefits? How would we prioritize those outcomes against each
other, and then against other activities that the leaders could be
running, or that others could be participating in?
As an example, for an OOPP-related "coverage sprint", our desired
outcomes might be:
- improve coverage of the new feature, especially in different configurations
- evaluate qualitative characteristics like performance/responsiveness
from a wider audience
- identify folks who could be helpful in plugin-specific cases in the
future (identifying regression ranges with plugin combinations, being
willing and able to capture dumps, interested in testing beta versions
of plugins, etc.)
For some of those outcomes, we might well want to reach out to other
communities, rather than our own QA community: post on forums for
Flash/Java games (and game developers), video sites,
Java/Silverlight/Flash support and developer forums, banner ads on
Facebook ("tired of ads crashing your browser? us too! find out
more"), a million other things I won't think of very quickly because
I'm not a QA-community-leverage expert.
For some other outcomes (like verifying add-on manager bugs after the
big landing, or doing a workshop on regression range finding or
profiling of performance issues), we might want to bias on the side of
people who are interested in being part of our process specifically,
so those could be better served by the current bugday model.
I don't think that our premise should be a certain activity, in a
certain form. It's true that we have some key contributors who came
up through the bugday programme, but reasoning on that basis is
hazardous: we have a survivor bias, and we aren't really able to see
the opportunity cost of not having those people (leaders and
participants) work on other things. We were certainly a different
project back then, and had different strengths and weaknesses, so we
should be careful about how we map those things to our current context
and needs.
Mike
ashughes
> On 5/11/10 1:44 AM, ashughes wrote:
>
> > It was recently brought to my attention that Bugdays could be going
> > the way of the Dodo. I've written a fairly detailed blog post about
> > why I think this is a BAD idea. I don't expect that you'll agree with
> > everything I said -- it is all just my point of view as someone who
> > has sat on both sides of the fence (Bugday organizer and Bugday
> > contributor). The purpose of this is to get my opinion out there in
> > the hopes that it will spur some healthy discussion. The end result,
> > I hope, will be the first step in getting a solid plan in place to
> > revitalize and better utilize Bugdays as a tool to improve the quality
> > of Firefox.
>
> I really haven't ever participated in bugdays, and as a developer I haven't
> directly experienced their usefulness. I sometimes see things go by about
> how we're going to have a bugday to close out old bugs, reduce the
> UNCONFIRMED bug list, and such like that. In general, bugdays of that sort
> feel like makework, and my impression is that they are a lot of work for
> little effective gain.
>
I think it signals a need to showcase the value of bugdays, not to
drop them. It shows that we have been doing a bad job (for the most
part) in both communicating and selecting topics which result in the
highest value and "return on invest" for Firefox.
> * Triage of new incoming bugs in Core:General and Firefox:General into
> appropriate components and especially cc'ing the right people
> * Finding older bugs where the bug had a patch bug review was never
> requested or was requested of an inactive reviewer, and finding the right
> reviewer
> * Creating reliable steps to reproduce bugs
> * Finding regression ranges for bugs
> * Writing and condensing testcases for bugs
> * Finding bugs with reviewed patches which were never committed (adding
> checkin-needed, or being even more proactive and just committing them)
>
> In some cases we'll have big projects such as the HTML5 parser,
> out-of-process plugins, new extension manager, etc, and bugdays can help
> with these projects even more specifically: looking through new bugs in
> those components, nominating important bugs to block the relevant releases.
>
These are all great suggestions for bugday topics. I think having
topics which are highly productive and useful to Firefox are key to
the success of Bugdays. This is highly useful feedback and exactly
what I was hoping to inspire by writing this post.
Thanks Benjamin!
ashughes
> On Wed, May 12, 2010 at 9:50 AM, Benjamin Smedberg
>
> > Perhaps we should turn the question around: assuming we do have bugdays,
> > what activities are most useful and would most benefit the project?
>
> I think it's probably better to turn it in another direction:
>
> What are the benefits we hope or expect to get from bugdays?
> Are bugdays the best way for us to invest in getting some/all/none of
> those benefits? How would we prioritize those outcomes against each
> other, and then against other activities that the leaders could be
> running, or that others could be participating in?
other. We need to identify the benefits we want to get from Bugdays
and only then can we identify the activities which will result in
those benefits. In other words, tailor the activities to the
benefits, don't haphazardly run events to see what benefits results.
>
> As an example, for an OOPP-related "coverage sprint", our desired
> outcomes might be:
>
> - improve coverage of the new feature, especially in different configurations
> - evaluate qualitative characteristics like performance/responsiveness
> from a wider audience
> - identify folks who could be helpful in plugin-specific cases in the
> future (identifying regression ranges with plugin combinations, being
> willing and able to capture dumps, interested in testing beta versions
> of plugins, etc.)
>
These are excellent activities more appropriate for a Testday. In
fact, these are the sorts of activities we ask of our community during
a Testday. Unfortunately, I don't think we do a good job of
communicating those other activities upfront (ie. on the QMO Event
page, in our social networking groups, etc). As with Bugdays, we need
to do a better job communicating.
> For some of those outcomes, we might well want to reach out to other
> communities, rather than our own QA community: post on forums for
> Flash/Java games (and game developers), video sites,
> Java/Silverlight/Flash support and developer forums, banner ads on
> Facebook ("tired of ads crashing your browser? us too! find out
> more"), a million other things I won't think of very quickly because
> I'm not a QA-community-leverage expert.
>
I don't think anyone in QA can consider themselves a QA-community-
leverage expert. Leveraging the QA community is something we
constantly struggle with and constantly seek to improve. Community
participation has increased over the years, mostly through trial and
error on our part. I love these suggestions. This kind of feedback
helps us a lot.
> For some other outcomes (like verifying add-on manager bugs after the
> big landing, or doing a workshop on regression range finding or
> profiling of performance issues), we might want to bias on the side of
> people who are interested in being part of our process specifically,
> so those could be better served by the current bugday model.
>
I tend to agree with you here, but I have a tweak on the statement you
are making. I agree that we need "people who are interested in being
part of our process specifically". These are the kind of people that
would best serve Firefox during Bugdays. However, I believe we need
Bugdays across many topics and varying levels of challenge to identify
these people. I assume this is how things work in the development
world as well. Someone new to the community starts out by
investigating and solving a rather trivial issue. As their skills,
experience, aptitude, and confidence improves, they seek out more and
more challenging issues, more and more complex bugs. In QA, I think
our challenge is designing community activities which harness this
effect.
> I don't think that our premise should be a certain activity, in a
> certain form. It's true that we have some key contributors who came
> up through the bugday programme, but reasoning on that basis is
> hazardous: we have a survivor bias, and we aren't really able to see
> the opportunity cost of not having those people (leaders and
> participants) work on other things. We were certainly a different
> project back then, and had different strengths and weaknesses, so we
> should be careful about how we map those things to our current context
> and needs.
>
I agree with you here too. I think it's important not to forget the
past, but we need not forget about the historical context either. We
need to look at Bugdays and the state of the project, past and
present. We need to look at what we did years ago, why that worked
and why that didn't. What context and needs existed back then? Are
there any lessons there that can be brought forward to today? Looking
at today, what are the needs, what is the current context, what works
(do more of this), what doesn't work (stop doing that).
Thanks Mike for this excellent feedback. I love how this conversation
is going.
Tracy Walker
In November of 1999, Asa started bugdays
http://www.mozillazine.org/talkback.html?article=954 for the Mozilla
suite. Bugdays quickly became popular as it was one of the few ways to
contribute to this amazing project. Those early times of BugDays were
really more like a combined Testday and Bugday. Asa was the man, he read
every bug. He had his finger on the pulse of the entire project. Bugdays
were exciting to take part in and a great entry point into the Mozilla
project. There is no doubt about that.
Then in Feb of 2002, Asa announced, "BugDays are back!"
http://www.mail-archive.com/mozilla...@mozilla.org/msg16771.html.
The focus becomes more about cleanup work in Bugzilla. Then again in
December of 2003, Asa announced, "The Return of BugDay"
http://www.mozillazine.org/articles/article4100.html. Only Asa could
elaborate what happened between the BugDay restarts. Eventually, Asa's
efforts turned to spreadfirefox and marketing. BugDays were dead.
In May of 2006, I attempted to resurrect BugDays. Through community
feedback, we created 3 globally regional sessions to serve our growing
community. For a year I ran those cleanup type Bugdays with moderate
success. Eventually, I handed Bugday off to Tomcat and the leaders in
the community. A year later, after less than productive times,
https://wiki.mozilla.org/QA/Community/Bug_Day/Archive Bugdays had fallen
the way of the Dodo.
Then, in early 2010, I decided to attempt to revive Bugdays yet again.
The only productive Bugday so far this year has been the Seamonkey one.
I believe this one was most successful because a couple leaders in the
project and a few devout followers were in channel interacting and
knocking out bugs themselves.
So what is the future of Bugdays? We can't continue it as a
one-foot-in-its-next-grave project. Should we morph it into a testday
like event with some of the focus on bug work (this is what the original
and most successful Bugdays were like under Asa at the turn of the
century)? Or take it a step further and make it an a la carte service
for anyone that needs it within the Mozilla project enlarge?
I believe Bugdays should be a tool that we promote to the Mozilla
community. It could be used for most anything anyone wanted to make
their Mozilla related project better. For example, Feature Lead: "Hey
QA, we're going to be landing a bunch of fixes/feature changes in a
couple of weeks, can you all get some community eyes on it to verify
those fixes and pound on it to find any new bugs?" QA: "Sure, we'd be
glad to work *with* you on that. Let's get a Bugday scheduled and come
up the details." Sounds more like a Testday, doesn't it?
I don't want to see Bugdays go away. However, I believe the current
model of just Bugzilla cleanup up does not generally work as an enticing
entry point into the world of Mozilla. I think the history shows that.
Tracy
AaronMT
> I'd like to provide a little history here.
>
> suite. Bugdays quickly became popular as it was one of the few ways to
> contribute to this amazing project. Those early times of BugDays were
> really more like a combined Testday and Bugday. Asa was the man, he read
> every bug. He had his finger on the pulse of the entire project. Bugdays
> were exciting to take part in and a great entry point into the Mozilla
> project. There is no doubt about that.
>
> Then in Feb of 2002, Asa announced, "BugDays are back!"
> The focus becomes more about cleanup work in Bugzilla. Then again in
> December of 2003, Asa announced, "The Return of BugDay"http://www.mozillazine.org/articles/article4100.html. Only Asa could
> elaborate what happened between the BugDay restarts. Eventually, Asa's
> efforts turned to spreadfirefox and marketing. BugDays were dead.
>
> In May of 2006, I attempted to resurrect BugDays. Through community
> feedback, we created 3 globally regional sessions to serve our growing
> community. For a year I ran those cleanup type Bugdays with moderate
> success. Eventually, I handed Bugday off to Tomcat and the leaders in
> the way of the Dodo.
>
> Then, in early 2010, I decided to attempt to revive Bugdays yet again.
> The only productive Bugday so far this year has been the Seamonkey one.
> I believe this one was most successful because a couple leaders in the
> project and a few devout followers were in channel interacting and
> knocking out bugs themselves.
>
> So what is the future of Bugdays? We can't continue it as a
> one-foot-in-its-next-grave project. Should we morph it into a testday
> like event with some of the focus on bug work (this is what the original
> and most successful Bugdays were like under Asa at the turn of the
> century)? Or take it a step further and make it an a la carte service
> for anyone that needs it within the Mozilla project enlarge?
>
> I believe Bugdays should be a tool that we promote to the Mozilla
> community. It could be used for most anything anyone wanted to make
> their Mozilla related project better. For example, Feature Lead: "Hey
> QA, we're going to be landing a bunch of fixes/feature changes in a
> couple of weeks, can you all get some community eyes on it to verify
> those fixes and pound on it to find any new bugs?" QA: "Sure, we'd be
> glad to work *with* you on that. Let's get a Bugday scheduled and come
> up the details." Sounds more like a Testday, doesn't it?
>
> I don't want to see Bugdays go away. However, I believe the current
> model of just Bugzilla cleanup up does not generally work as an enticing
> entry point into the world of Mozilla. I think the history shows that.
>
> Tracy
Tracy,
In my opinion, herein lies the predominant issue. One must question
the lure and attraction of Bugdays, in association through identifying
the intended target audience. Is the enticement intended for new
community members, or an appeal for those with both feet already in
the door? For the former, I must question (not to speak for all
community members of course) the ease (or lack thereof) of entry, and
thus perhaps is the cause for low attendance.
Benjamin Smedberg
> These are excellent activities more appropriate for a Testday. In
> fact, these are the sorts of activities we ask of our community during
> a Testday. Unfortunately, I don't think we do a good job of
> communicating those other activities upfront (ie. on the QMO Event
> page, in our social networking groups, etc). As with Bugdays, we need
> to do a better job communicating.
Hrm, I wonder if it makes sense for "testdays" and "bugdays" to be separate
events, then. There is certainly a lot of overlap when you're talking about
targeted testing. For example, if you wanted to do a "*day" on a standard
dot-release candidate, you might have the following activities:
* verify bugs fixed in the RC
* look at crash-stats data to compare it with prior releases
* look at new bugs filed against that RC
Perhaps it makes sense to combine the two efforts in a more wholistic way?
--BDS
ashughes
> I believe Bugdays should be a tool that we promote to the Mozilla
> community. It could be used for most anything anyone wanted to make
> their Mozilla related project better. For example, Feature Lead: "Hey
> QA, we're going to be landing a bunch of fixes/feature changes in a
> couple of weeks, can you all get some community eyes on it to verify
> those fixes and pound on it to find any new bugs?" QA: "Sure, we'd be
> glad to work *with* you on that. Let's get a Bugday scheduled and come
> up the details." Sounds more like a Testday, doesn't it?
>
> I don't want to see Bugdays go away. However, I believe the current
> model of just Bugzilla cleanup up does not generally work as an enticing
> entry point into the world of Mozilla. I think the history shows that.
>
Thanks for providing some context to this discussion Tracy. I think
your idea of Bugdays as a tool is bang-on. It should be a tool
feature/community leaders consider using almost instinctively, not
"that thing QA does once in a while".
ashughes
That's actually something we have been thinking about this quarter.
ashughes
> In my opinion, herein lies the predominant issue. One must question
> the lure and attraction of Bugdays, in association through identifying
> the intended target audience. Is the enticement intended for new
> community members, or an appeal for those with both feet already in
> the door? For the former, I must question (not to speak for all
> community members of course) the ease (or lack thereof) of entry, and
> thus perhaps is the cause for low attendance.
I believe that the ratio of technical-minded to non-technical-minded
people (users and the community) sways a lot more to the non-technical
than it the past. We need to adapt our activities as the makeup of
our community changes. In the past, when we had a more technical
audience, investigating and verifying bugs was quite appealing. Now,
we get a lot more day-to-day Firefox users who are just coming to help
out any way they can. The technical minded people are still there too
though. I think we need to have activities that cater to both groups
of people. We can roll these different activities into a single event
or break them into specific, targeted events. We need to be careful to
foster development and growth within the community while keeping the
barrier to entry minimal.
Asa Dotzler
I should have said this up front: I had some assumptions about what
bugdays are (were) that may not be current. The bit that I think is
critical is that we have core community members representing QA (paid
staff and or volunteer) who will make themselves available on live
channels (irc, IM, whatever) on a schedule of some sort to help new QA
contributors develop into regular community members and to encourage
casual bug filers or other supporters to get more deeply involved in the
project.
If the various iterations of bugdays over the last decade are no longer
the right mechanism, that's fine so long as there is a suitable
replacement mechanism for developing interested volunteers and for
trying to convert causal supporters into regular volunteers.
I happen to think that realtime communication channel and a "anyone is
welcome, from the first time bug reporter to the person looking to
deepen their QA skills and involvement" is the right approach and that
it should be driven with some consistency and by people with a solid
understanding of the project and the most important QA/etc focus areas.
I also think that the value of such a channel is not purely in how many
work units get completed each bugday so it misses out if we just say
"what work needs to get done and what's the best way to get volunteers
to do that work." That overlooks a huge benefit of having such a
welcoming open door to the project that lies right at low wall between
hundreds of millions of users and a couple thousand dedicated
technical-type volunteers.
- A
Mark Banner
> Then, in early 2010, I decided to attempt to revive Bugdays yet again.
> The only productive Bugday so far this year has been the Seamonkey one.
> I believe this one was most successful because a couple leaders in the
> project and a few devout followers were in channel interacting and
> knocking out bugs themselves.
Errm, I've not seen Thunderbird mentioned in this discussion. We do have
testdays and bugdays, unfortunately Ludovic is afk this week so I can't
get him to feedback his feelings.
Standard8
Robert Kaiser
> In November of 1999, Asa started bugdays
> http://www.mozillazine.org/talkback.html?article=954 for the Mozilla
> suite. Bugdays quickly became popular as it was one of the few ways to
> contribute to this amazing project. Those early times of BugDays were
> really more like a combined Testday and Bugday. Asa was the man, he read
> every bug. He had his finger on the pulse of the entire project. Bugdays
> were exciting to take part in and a great entry point into the Mozilla
> project. There is no doubt about that.
> Then, in early 2010, I decided to attempt to revive Bugdays yet again.
> The only productive Bugday so far this year has been the Seamonkey one.
> I believe this one was most successful because a couple leaders in the
> project and a few devout followers were in channel interacting and
> knocking out bugs themselves.
Now, I see an interesting parallel in those early buigdays and the
successful SeaMonkey one now - and no, I don't mean both working on the
suite. ;-)
What catches my eye is that someone strong in the project and in
development was part of this in both cases. The large benefit from the
early bugdays came IMHO to a (good) part from developers, testers, and
bug triagers interacting.
And I think that's one key thing there. You need people devoted to the
area the bugday is working on to be present for questions, hard cases,
and for aking the right questions to people unsure what to look for
specifically.
What do you think? Am I mistaking things or is there something to this
train of thought?
Robert Kaiser
ashughes
> What catches my eye is that someone strong in the project and in
> development was part of this in both cases. The large benefit from the
> early bugdays came IMHO to a (good) part from developers, testers, and
> bug triagers interacting.
> And I think that's one key thing there. You need people devoted to the
> area the bugday is working on to be present for questions, hard cases,
> and for aking the right questions to people unsure what to look for
> specifically.
>
> What do you think? Am I mistaking things or is there something to this
> train of thought?
>
> Robert Kaiser
I think you are bang on here. This is something I tried to point out
in my blog post, but you've articulated it better than I could. In
fact, this is how leveraging the community should work as a whole, not
just for Bugdays. This is exactly what I meant by a "feature/
community expert". Certainly when we had the Seamonkey Bugday, you
were on hand to help. Likewise, when we we had the Tab Matches in
Awesomebar Testday, we had the developer of this feature on hand to
help. Both of these events were successes largely because of the
devotion and support of "feature/community experts".
Gaby2300
I love assisting to Bugdays! I feel I'm really helping Firefox then!
Tracy is always very kind and helpful and she explains you very
clearly the steps you have to follow to complete the object of the
Bugday. I really hope Mozilla keeps planning them!
Best regards,
Gaby
Tracy Walker
and Testdays have been when key person(s) from the project in focus were
actively participating.
Let me make one more conclusion from this discussion. Testdays are
generally for testing a feature/product with maybe some bug work mixed
in. These are great for active Mozillians and a good entry point for new
community members. Bugdays are generally for Bugzilla related tasks with
perhaps some exploratory testing mixed in. These are better suited for
active Mozillians, but of course not exclusively so. It's a simple
distinction to help filter which community day a feature owner may want
to use and who to promote the actual event to.
Where to go from here? How do we promote Bugdays to the project and
feature owners such that they understand how Bugdays can help them make
their product better? We need to make Bugdays appealing such that
they'll want to use it and will come to QA to collaborate on making
their Bugday a success.
Tracy
Matt Evans
for his insightful blog post that started this thread. You all can blame
me for the initial impetus of this thread. I had mentioned to Tracy in
our 1 on 1 about my frustration with low attendance and my perception
regarding the ineffectiveness of bugdays. Tracy had started a revival of
sorts, but there wasn't much improvement in participation. This prompted
my suggestion that maybe we should just cancel bug days. But to be sure,
in my mind is was more about an overhaul of the bug day concept rather
than nuking the program altogether. It was an unbaked thought at the
time, but it obviously sparked background conversations and ultimately
the wonderfully insightful opinions contained in this thread.
Since I started some 3 to 4 months ago, I've had my frustration with
bugdays. Most bugdays I had observed were low attended, mostly bug
maintenance events. It was difficult for me to see the beneficial impact
given the efforts of the QA folks to stage and run these events. They
did little IMO to spark passion or interest in the project under test
and didn't garner much participation by project leaders in QA,
development and the community.
On the other hand I have a rather short historical perspective. In the
past Asa-ian era, bugdays were a different animal and had a much more
direct and universally understood link to Mozilla participation and
impact. Today's more bug maintenance focused bugdays just don't have
that same appeal nor do they offer community members a real path to
deeper involvement and greater impact within Mozilla projects. Maybe
they do, I just don't really see it.
The recent successful seamonkey bugday demonstrates that they can
produce productive results. However as pointed out, this was largely do
to project leaders and stakeholders showing passionate participation.
Clearly we need to do some rethinking regarding bug days.
I guess my suggestion really stirred the pot, but the pot needed
stirring. Thanks to all the Mozilla chefs for their observations and
suggestions on the bugday recipe. Any more to follow, will be
appreciated as well. All will be thoughtfully considered as they
indicate a need for modification, morphing and eventual evangelizing of
what the expected outcome and purpose of a bugday should be. Time to
experiment in the kitchen.
Tony Mechelynck
Maybe there is a hint there, of why the SeaMonkey bugday was the most
successful one? After all, IIUC both the SeaMonkey application and its
target audience are much more like those of the old Suite than what
Firefox has become. And yet there is an increasing proportion of common
code between SeaMonkey OT1H, Firefox & Thunderbird OTOH, so I couldn't
believe that a single QA activity would profit the one and be
detrimental to the others. As a SeaMonkey user, I look forward to the
upcoming Addons-manager Day, which admittedly has been labeled a
"testday"; but if "bugdays" come up where I can discern a "SeaMonkey
side" (maybe a Toolkit bugday? or a Mailnews bugday?) I'll take part
just as eagerly as I did the SeaMonkey-General bugday, and so much the
better if I meet "Firefox people", Thunderbird people" or even "Core
(Gecko etc.) developers" there.
This said, to my bright-eyed newcomer's eyes, bugdays haven't gone the
way of the dodo, but rather that of the phoenix: from what Tracy said,
it seems that whenever Bugdays looked gone away forever and fit for the
grave, someone resurrected them. And even if ($DEITY and ;-) Asa Dotzler
forbid) the Mozilla (MoCo or MoFo?) executives decide to disallow
participation to their employees, there will (hopefully) be some unpaid
enthusiasts to push them forward — at least on the SeaMonkey side, where
all of them people are of that ilk.
Best regards,
Tony.
--
I like to believe that people in the long run are going to do more to
promote peace than our governments. Indeed, I think that people want
peace so much that one of these days governments had better get out of
the way and let them have it.
-- Dwight D. Eisenhower
Benjamin Smedberg
> I believe that the ratio of technical-minded to non-technical-minded
> people (users and the community) sways a lot more to the non-technical
> than it the past. We need to adapt our activities as the makeup of
> our community changes. In the past, when we had a more technical
> audience, investigating and verifying bugs was quite appealing. Now,
> we get a lot more day-to-day Firefox users who are just coming to help
> out any way they can. The technical minded people are still there too
> though. I think we need to have activities that cater to both groups
> of people.
I'm not sure this is true. If we have worthwhile tasks that non-technical
people can do in bugzilla, then sure, let's invite them in. But I believe
that just because there are non-technical people who want to help doesn't
mean we have to design QA activities specifically for them, or especially
design bugdays around that group of people.
Bug work and QA in general is an inherently technical activity: it doesn't
require coding ability, but it does require attention to detail, familiarity
with technology, and precision. If people come in without these abilities,
we should perhaps push them towards other community activities which are
non-technical in nature, rather than trying to mold bugdays differently.
--BDS
Tanner M. Young
I wonder if the bugdays would be more successfully if they weren't
events but ongoing, making them into a small community-assisted triage
program. For example, we have Jesse, Tracy, and half-a-dozen others in
the #bugday channel (which a number of us auto-join anyway) ready to
help anyone who wants to participate, and we have a buglist in the
channel topic that people can work on at their leisure and just ask
questions of the channel leaders as needed.
Rather than trying to have a major bug event every few weeks, community
members contribute five minutes per day doing a little triage, perhaps
addressing two or three bugs each, making it manageable for the people
in the channel and manageable for the community members. This also
opens the door to triaging smaller topics or features that wouldn't
merit a full bugday, and therefore help areas of Bugzilla that are
sometimes ignored.
The main risk is that bugdays could lose their draw because they
wouldn't be events, but I think billing it as a simple opportunity to
help Mozilla five minutes each day would more than compensate.
Tanner
Tony Mechelynck
> It seems we're in agreement. The most productive and rewarding Bugdays
> and Testdays have been when key person(s) from the project in focus were
> actively participating.
>
> Let me make one more conclusion from this discussion. Testdays are
> generally for testing a feature/product with maybe some bug work mixed
> in. These are great for active Mozillians and a good entry point for new
> community members. Bugdays are generally for Bugzilla related tasks with
> perhaps some exploratory testing mixed in. These are better suited for
> active Mozillians, but of course not exclusively so. It's a simple
> distinction to help filter which community day a feature owner may want
> to use and who to promote the actual event to.
>
> Where to go from here? How do we promote Bugdays to the project and
> feature owners such that they understand how Bugdays can help them make
> their product better? We need to make Bugdays appealing such that
> they'll want to use it and will come to QA to collaborate on making
> their Bugday a success.
>
> Tracy
I think QA must stress the fact that Bugdays (and Testdays) can help the
projects affected by them, but only if someone (and preferably several
someones) with a position of responsibility for said projects is there
to contribute, show the good example, stir emulation among all
contributors, and answer difficult questions. It's not just a Tinkerbell
effect of "it will work if you believe in it", it's mostly "put your
hands into the grease and your manpower where your mouth is" -- there
needs to be a leader (or leaders) or there'll be no followers. There's
nothing magical to *days, they're just a way to promote collective work
by example, and by setting a date when we'll show the world that where
"one man alone can do nothing, together we can do anything".
I'm not sure where "QA professionals" fit in, except maybe in the
logistics common to all bugdays and testdays, non-project-related
organization, and maybe also, once the date has come, in demonstrating
how someone not particularly versed in the technical side of the product
at hand can usefully contribute.
Best regards,
Tony.
--
XIIdigitation, n.:
The practice of trying to determine the year a movie was made
by deciphering the Roman numerals at the end of the credits.
-- Rich Hall, "Sniglets"
ashughes
place here. I've received a lot of great feedback and ideas. At this
point, I'm considering this phase of the discussion closed.
I've written a follow-up blog post summarizing and concluding the
discussion. I've also outlined some very important questions we need
to be asking ourselves as we move forward. Here's the link:
http://ashughes.com/?q=node/131
At this point, we are going into brainstorm mode. I think we all
agree that Bugdays need to stay but they need to evolve
significantly. This is something I am passionate about and will be
taking on personally. I'll be planning at least one (maybe more)
brainstorming session at Mozilla. For those who will be unable to
attend these sessions, I've set up a wiki.mozilla.org page so that you
can give us your ideas. Here's the link: https://wiki.mozilla.org/User:Ashughes/Bugday_Brainstorm
Thanks again everyone for taking your time to engage in discussion
about Bugdays.
Cheers,
Anthony Hughes
IRC: ashughes