A rare shot of some members of the Trout Cabal doing their secret handshake,
while wearing red noses to bring the fun back to Debian (as per their shadow DPL platform).

During the meeting, the members of the cabal were able to update their manifesto as well as devise new brilliant ways to promote Debian around the world.
Many thanks to MiniDebconf UK 2014 organizers for hosting this important meeting.
Also, thanks Nattie for the pic :).

It's not about how it inits, it's all about how it ends. (Going out in style, you know?)

"I have seen a picture," Havzhiva went on.
The Chosen was impassive; he might or might not know the word. "Lines and colors made with
earth on earth may hold knowledge in them. All knowledge is local, all truth is partial," Havzhiva said
with an easy, colloquial dignity that he knew was an imitation of his mother, the Heir of the Sun, talking
to foreign merchants. "No truth can make another truth untrue. All knowledge is a part of the whole
knowledge. A true line, a true color. Once you have seen the larger patttern, you cannot go back
to seeing the part as the whole.

I've just finished to read "Four Ways to Forgiveness" by U.K Le Guin.
It deeply resonated within me, it's still there doing its magic in my brain, lingering in the corners of my mind, tickling my view of reality, humming with the beauty of ideas you didn't knew were inside you till you've seen them written on paper.
And then, you know they were there all along, you just didn't know how to make them into words.
Le Guin knows how to do it, wonderfully.

I loved the whole book, but the last two stories were eye-openers.
Thanks Enrico for suggesting me this one, thanks dkg for having introduced me to Le Guin's books (with another fantastic book: The Left Hand of Darkness).

An online triage workshop

One of the most interesting thing I've done during the last weeks has been to held an online
Bug Triage Workshop on the #testday channel at irc.mozilla.org.
That was a first time for me: I had been a moderator for a series of training sessions on IRC
organized by Debian Women, but never a "speaker".
The experience turned out to be a good one: creating the material for the workshop had me basically summarize (not too much, I'm way too verbose!)
all what I've learned in this past months about triaging in Mozilla, and speaking of it on IRC was a sort of challenge to my usual shyness.

And I was so very lucky that a participant was able to reproduce the bug I picked as example, thus confirming it! How cool is that? ;)

The workshop was about the very basics of triaging for Firefox, and we mostly focused on a simplified lifecycle of bugs, a guided tour of bugzilla (including the quicksearch and the advanced one, the list view, the individual bug view) and an explanation of the workflow of the triager.
I still have my notes, and I plan to upload them to the wiki, sooner or later.

I'm pretty satisfied of the outcome: the only regret is that the promoting wasn't enough, so we have few participants.
Will try to promote it better next time! :)

about:crashes

Another thing that had me quite busy in the last weeks was to learn more about crashes and stability in general.
If you are unfortunate enough to experience a crash with Firefox, you're probably familiar with the Mozilla Crash Reporter dialog box
asking you to submit the crash report.

But how does it works?

From the client-side, Mozilla uses Breakpad as set of libraries for crash reporting. The Mozilla specific implementation adds to that a crash-reporting UI, a server to collect and process crash reported data (and particularly to convert raw dumps into readable stack traces) and a web interface, Socorro to view and parse crash reports.

Curious about your crashes? The about:crashes page will show you a list of the submitted and unsubmitted crash reports.
(And by the way, try to type about:about in the location bar, to find all the super-secret about pages!)

For the submitted ones clicking on the CrashID will take you to the crash report on crash-stats, the website where the reports are stored and analyzed.
The individual crash report page on crash-stats is awesome: it shows you the reported bug numbers if any bug summaries match the crash signature, as well as many other information. If crash-stats does not show a bug number, you really should file one!

The CrashKill team works on these reports tracking the general stability of the various channels, triaging the top crashes, ensuring that the crash bugs have enough information and are reproducible and actionable by the devs.
The crash-stats site is a mine of information: take a look at the Top Crashes for Firefox 34.0a1.
If you click on a individual crash, you will see lots of details about it: just on the first tab ("Signature Summary") you can find a breakdown of the crashes by OS, by graphic vendors or chips or even by uptime range.
A very useful one is the number of crashes per install, so that you know how widespread is the crashing for that particular signature.
You can also check the comments the users have submitted with the crash report, on the "Comments" tab.

One and Done tasks review

Last week I helped the awesome group of One and Done developers, doing some reviewing of the tasks pages.

One and Done is a brilliant idea to help people contribute to the QA Mozilla teams.
It's a website proposing the user a series of tasks of different difficulty and on different topics to contribute to Mozilla. Each task is self-contained and can last few minutes or be a bit more challenging.
The team has worked hard on developing it and they have definitely done an awesome job! :)

I'm not a coding person, so I just know that they're using Django for it, but if you are interested in all the dirty details take a look at the project repository.
My job has been only to check all the existent tasks and verify that the description and instruction are correct, that the task is properly tagged and so on.
My impression is that this an awesome tool, well written and well thought with a lot of potential for helping people in their first steps into Mozilla. Something that other projects should definitely imitate (cough Debian cough).

What's next?

Next week I'll be back on working on bugs. I kind of love bugs, I have to admit it.
And not squashing them: not being a coder make me less of a violent person toward digital insects.
Herding them is enough for me. I'm feeling extremely non-violent toward bugs.

I'll try to help Liz with the Test Plan for Firefox 34, on the triaging/verifying bugs part.
I'll also try to triage/reproduce some accessibility bugs (thanks Mario for the suggestion!).

[Edit: changed the post title, while I love the music, the actual lyrics
of "Shake Rattle and Roll" made me facepalm. Ronnie Dawson's song is
better :)]

Last weekend I've been in Senigallia for the 15th edition of Summer Jamboree.
It was my first time there, and it was epic. Really.
If you are into roots music and early rock'n'roll and/or into vintage 40s and 50s clothes, go there.
You won't regret it!

(You have time until August 10th, hurry up!)

If you follow my identi.ca account (whooo! shameless plug!), you may know that I love music in general and Blues, Jazz and Rockabilly in particular.
If you read my blog, you may know that I make clothes - particularly reproductions of 50s and retro clothes.
So, it's not much of a surprise that going to the Summer Jamboree has been a mindblowing experience to me.
What surprised me it's that I've felt the very same wonder of my first Debconf: the amazing feeling that you are not alone,
there are other people like you out there, who love the same things you love, who are silly about the same little details
(yes, I equally despise historically innacurate pin up shoes and non free software), who dance - metaphorically and not - at your same beat.
Same wonder I felt when I first read some authors - Orwell and David Foster Wallace, just to mention a couple - or when I first delved in
anarchist thinkers.
By nature I'm not much of a social person, and I tend to live and love alone. But that sense of being part of something, to find
like-minded people always blows me away.

I'm not much of a blog writer, so I won't probably be able to give you a good impression of the awesomness of it.
But hey, watch me trying.

The Vintage Market

I spent most of the morning travelling by train to reach Senigallia (and met the most beautiful French girl ever in the process, who sketched me in her notebook because, hey!, I was already in full Rockabilly gear).
The hotel was pretty close to the station, and to the part of the city where the festival was taking place, so I spent a couple of hours sleeping, then started the adventure.
The festival takes place mostly near the Rocca Roveresca, a beautiful fifteenth century castle, and on its gardens, but the all the other venues are in walking distance.
All around the Rocca there is a market with vintage clothes, records, shoes, retro jewelry.

A special mention for two fantastic dressmakers: Laura of Bloody Edith Atelier from Rome and Debora of The Black Pinafore from Sarzana. I bought just a piece from each of them, but I was able to do that only with a huge amount of self restraint.

Guitars! Tattoos!

Yes, I may have spent a bit drooling on the Gibson Cherry Red, and I tried (without amp, though) that beautiful orange Gretsch Electromatic.

And Greg Gregory of the Travel Ink Tattoo Studio from UK was there, with his shiny Airstream.

I also spent a while among the records in the Bear Family Records booth. They are a Germany based independent record label specialised in reissues of country and 50s rock'n'roll. Couldn't resist, and I bought a beautiful Sun Records' tshirt.

Just Rockin' and Rollin'. Aka: dance time

After that, it was time to dance. I missed the dance camp of the afternoon, but the DJ sets were fantastic, all 40s and 50s stuff, and I fell in love with Lindy Hop and Boogie Woogie, and well, obviously, Jive.

I could have spent hours watching the people dancing, and clumsily trying the most basic moves myself.

People

And the people, did I mention the people?
They were cosplaying the 40s and 50s so wonderfully I couldn't help but take some photos (and find a new fetish of mine: men in 40s clothes. Sexy as hell).

Cars

Who knows me, can tell that I don't love cars.
They stink, they are noisy, they are big.
But these ones where shiny and looked beautiful.

Also, the black Cadillac had the terrible effect on me of putting "Santa Claus is Back in Town" in my head (or, more precisely, Elvis tomcatting his way through the song, singing "Got no sleigh with reindeer / No sack on my back / You're gonna see me comin' in a big black Cadillac").

Music!

Sadly, I missed Stray Cat's Slim Jim Phantom but I was just in time for Ben E. King.
It was lovely: backed by the house band (The Good Fellas), he sang a lot of old Drifters hits, from On Broadway to Save the Last Dance for Me to - obviously - the great Stand By Me.

Then a bit of hillbilly country, with Shorty Tom and the Longshots, a French combo consisting of a double bass, a rhythm guitar and a steel guitar.

And, well, more dancing: the dj sets on the three stages went on until 3 am.

Day 2

The next morning I took advantage of the early opening of Rocca Roveresca to visit it. The Rocca itself is beautiful and very well maintained, and hosts various exhibitions.
"Marilyn In White" shows the incredible photos taken by George Barris on the set of "The Seven Year Itch" as well as some taken in 1962. Beautiful, really, especially the series on the beach.

But the ones moving me were the pics from "Buddy Holly, The Day The Music Dies": a collection of photos taken by Bill Francis during the (sadly brief) career of Buddy Holly from the very beginnings to his death.

After that, it was time to come back to year 2014, but really I felt like I've walked for a while in another decade and planet. And the cool thing is that I could enjoy the great 40s and 50s music and dances (and clothes!) without the horrible stereotypes and cultural norms of the time period. A total win. :)

So, ehm, that's it. I'm a bit sad to be back, and to cheer myself up I'm
already planning to attend Wanda Jackson gig in Aarburg (CH) next month.
And take Lindy Hop and Boogie lessons, obviously.

Bugs, Bugs, Bugs, Bacon and Bugs

I've continued with my triaging/verifying work and I feel now pretty confident when working on a bug.
On the other hand, I think I've learned more or less what was to be learned here, so I must think (and ask my mentor) where to go from now on.
Maybe focus on a specific Component?
Or steadily work on a specific channel for both triaging/poking and verifying?
Or try my hand at patches?
Not sure, yet.

Also, I'd like to point out that, while working on bug triaging, the developer's answers on the bug report are really important.
Comments like this help me as a triager to learn something new, and be a better triager for that component.
I do realize that developers cannot always take the time to put in comments basic information on how to better debug their component/product, but trust me: this will make you happy on the long run.
A wiki page with basic information on how debug problems for your component is also a good idea, as long as that page is easy to find ;).

So, big shout-out for MattN for a very useful comment!

Community

After much delaying, we finally managed to pick a date for the Bug Triage Workshop: it will be on July 25th.
The workshop will be an online session focused on what is triaging, why is important, how to reproduce bugs and what information ask to the reporter to make a bug report the most complete and useful possible.
We will do it in two different time slots, to accomodate various timezones, and it will be held on #testday on irc.mozilla.org.
Take a look at the official announcement and subscribe on the event's etherpad!

The last weeks have been a bit rough: I have my usual migraines to thank for that.
It's not easy to work with them: you are either stoned by the meds, or cannot look at a monitor. And while you're trying to sleep your headaches away, the world keeps rolling. Silly world.
As Liz, my mentor, suggested I tried to stick with the little things and to do a bit of something everyday.
"Waiting for the miracle", you know.
So, here's what I've been up to:

Triaging

I probably failed my personal 5-bugs-a-day policy, in the last two weeks, but beside that I'm pretty satisfied of my progress:

I verified some more bugs (mostly Developer Tools or Theme related) on both Linux and Windows (yeah. Don't.Ask.)

I triaged a lot of them. Also botched a couple, and felt an idiot for that.

All in all, I realized that I really love triaging/verifying bugs: being not a developer nor a simple user, but a bit of both, gives me
the right mindset - I think - to mediate between these two worlds.

Community

On the community front, I finally managed to meet - virtually - the Mozilla Italian community. The guys are great and beside running the forum to give user support, they do a whole lot of activities related to localization.
They are also trying to encourage participation of Italian users and enthusiasts to Mozilla events: don't miss, for instance, the upcoming Marketplace Day when a couple of us will be available to help other Italian users with the day's activities.
Read Daniele's post on the forum for more information in Italian.

After two weeks working as OPW intern for Mozilla, it's time for a recap!
What exactly I've been doing in these two weeks?

100 bugs triaged: achievement unlocked!

Yes, this is the thing I'm most proud of.

I'm a bit cheating here, as strictly speaking, since the beginning of the internship I've triaged only
44 bugs.
But I've decided to count from the beginning of my activity on bugzilla, at the end of March, since I've started work on that as part of the small contribution required for applying to OPW.
Therefore, it's all OPW related :)

Right now, I've decided to work on an average of 5 bugs a day: it's mostly triage and/or verification, which is quite fun.
It consists in trying to have a more complete and detailed bug report for the developers: asking the right questions to the reporter,
ensuring that the bug is filed against the right product or component and all the information about platforms and version are correct.

Or verifying that the bug isn't a duplicate, which involves doing some voodoo with Bugzilla quicksearch (I'm not so good with that yet, mostly because I'm not imaginative enough in the queries... but I'm getting better!)

Sometimes triaging means reading lots of documentation (to be sure that something is a bug and not a feature) and checking meta-bugs and release notes to be able to pinpoint the time when something was introduced and the reasoning behind it.
That takes a lot of time, but it makes you discover some funny things, like the Mighty Bouncing Unicorn.

And while I know it sounds a bit cruel, it's really good when you're verifying a fix and you find it's not totally ok, or that it triggered another bug.
I've been assured that feeling satisfied after that it's an essential part of the sadistic QA work.

Writing FAQs for new triager

This started as a personal project even before knowing I've been selected for OPW, and it's now part of my internship: I've been writing a first draft of FAQ for those who approach for the first time the Bug Triaging and Verifying work in Mozilla.

It meant taking a whole lot of IRC logs and scan them for the most asked questions during bugdays, and you can find here my first draft. I'll send a RFC today about it on dev-quality mailing list and link it to the main Bugdays page.

Lessons learned

So, what I've learned in these two weeks?

That I'm pretty good at figuring things alone, but I like to have feedback on what I'm working on.
That testing things is an art, and perfectionism is a big plus.
That there are such things as stupid questions, but you have to ask them nonetheless.
That people in the Mozilla community are quite friendly and not scary at all. Not even in video! :)

Wishlist

I've been thinking about this a lot, and I think I'd like to have

a guide to all the technical terms in the UI (it took me a while to figure out what exactly was the hamburger menu, or understand the difference between awesomebar, search bar and new tab search). This is essential when triaging or verifying theme related bugs, or UI bugs in general.

a big jargon/acronym file: m-c? UX? nightlies? australis? WFM? STR? m-a? Mozilla's people speak another language, especially in bug reports. You get familiar with that after a while, but at first glance can be quite obscure.

Random thoughts of a new contributor

I've started to contribute to Mozilla - and particularly to the Firefox Desktop QA team -
at the end of March, in order to apply for the OPW
with Mozilla as Bug Wrangler.
While being already part of the Free Software world as contributor clearly helps,
it's always difficult to find your way at first in such a big project, no matter how helpful the people you're working with are.

It's about trying to understand how the project is organized and who works on what, what is expected from you
as contributor and the specific style of interaction and contribution accepted in the project.

So, here's a couple of thought about it: the necessary disclaimer is that I'm a long-time Debian contributor meaning that,
inevitably, Debian is my reference model.
Also, everything I'm writing here regards only the specific part of the project I've been working in: Desktop QA and Bugmastering.

Documentation

The first thing that I noticed is the huge amount of documentation. Everything is very well documented
and while this is definitely a plus in my book, it's sometimes difficult to keep track of all this resources.

Some of the documents on these three different places are sometimes similar, making them redundant and it's difficult
to remember where you read what. At least for me. My workaround has been to bookmark pages as a mad woman, and also to
make a list on my wikipage of the pages I found more useful.
My top five of useful pages? Here we go!

And speaking of triage, special shout-out for the most useful addon ever for Mozilla triagers/testers: Nightly Tester Tools.

Community interaction

For someone coming from Debian, where everything is done via public mailing lists and/or IRC chans, Mozilla was a bit of a cultural shock.
The mailing lists are not very much used, at least in the QA community (or I'm not subscribed to the right ones ;)).
As for IRC, while there are many channels, they are not very active: meetings and important discussions are held using a proprietary videoconference software (Vidyo), and are mostly restricted to employees (but other people can join if they have a guest URL).

On the other hand, every time I asked for help - even the most stupid question - on IRC, I got a useful reply. And thanks to the folks on #testdays and #qa (especially petruta and Aleksej) I was able to speed up the learning process and understand how things work in the project.
So, while I'd like to see more public meetings, it's also true that the community is working well on interaction among contributors.

Community outreach

This is where I think Debian could borrow a couple of ideas. Mozilla basically got me hooked
thanks to their Bugdays: every Monday and Wednesday are - respectively -
dedicated to Triage and Verification of bugs. The events are open to everyone,
the wikipages for the events provide a good tutorial explaining the workflow in detail, and if you have any doubts
there are always people willing to help you on the dedicated IRC chan.
Every bug worked on during these events is also tagged: so that later it's possible to
check how successful the day was in terms of participation.

Bugzilla and the triaging/verification workflow

About Bugzilla I can only say that I like it. I like how flexible is for search queries, I like the possibility to have custom tags
on the whiteboard (as the [bugday-xxxxxx] one) and the smart way to interact among people in the bug without making the bug go stale (ie,
mostly the needinfo feature).
But beside the software used as BTS, I must admit that I really like the workflow and the whole concept of triaging in Mozilla.
The granularity of rights (everyone, canconfirm, editbugs) and the clear procedure for a permission upgrade; the presence of a team
constantly working on cleaning the incoming bugs, regardless of the product/component, to make easier for the developers the filtering
and the resolution as well; the attention to details of the verification process: each bug marked as Resolved → Fixed need
to be Verified, to be sure that it's been actually fixed... All these things are really impressive.

This, obviously, is something that can be done inside an upstream project where there are people doing paid work,
and where the products are not too many. I cannot see how this kind of QA process can be applied to bugs against an entire OS.
But there are some things we (as in Debian) could take inspiration from.

Organizing regular Bugdays, for instance.
Creating a team of triagers to help both with incoming and with very old bugs.
And this, again, is a kind of work that can be done by everyone,
not only coding contributors: meaning that an additional effect would be to increase the diversity in the contributors pool.

As a side note: I'll start my OPW internship next Monday, and will spend three months playing with bugs and learning
how to be a Bug Wrangler! \o/\o/