Yet another update from my internship at Mozilla, as part of the OPW.
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! :)
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).
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!).
[Warning: quite a bit of pics in this post]
[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.
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.
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).
For instance, Angelo Di Liberto, artistic director of the festival with the beautiful burlesque artist Grace Hall.
Or the amazingly dressed German couple I met in via Carducci.
And this couple too, was pretty cool.
The Prettiest Smile award goes to these lovely ladies!
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").
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.
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.
Yet another update from my internship at Mozilla, as part of the OPW.
A brief one, this time, sorry.
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!
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!
See you on Friday! :)
Time for an update from my internship at Mozilla, as part of the OPW.
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:
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 learnt how to find regression windows
- 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.
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.
On the documentation front, I finally managed to get out the Bugdays FAQ, draft a guide on how to run different versions of Firefox and multiple profiles for triaging purposes on Linux and Windows - still have to finish this one, though -, and participate to a very interesting discussion on the current state of QMO - the entry point for QA contributors in Mozilla.
The site, in my opinion, needs some love and I'd very much like to help in that sense.
Check out the discussion, and give us some feedback about the website on the dev-quality mailing list!
- when you're not feeling well, stick with the little things and don't feel guilty for that
- don't try to reproduce a bug when you're tired, you'll end up Doing It Wrong™
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
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 :)
Here's the grand total.
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.
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! :)
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.
They will probably become my next pet project.
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.
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.
AFAICT, there are basically three main sources of documentation:
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!
- a bug's life: lifecycle of bugs in BMO
- Tyler's BMO survival guide (parts 1, 2 and 3)
- Tyler's Triage Guidelines
- on reducing testcases
- bug verification walkthrough
And speaking of triage, special shout-out for the most useful addon ever for Mozilla triagers/testers: Nightly Tester Tools.
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.
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/
"Take, for example, the opening to Eleanor Catton's The Luminaries: 'The twelve men congragated in the smoking room of the Crown Hotel gave the impression of a party accidentally met.' This is emphatically not the same as starting a novel with 'So there they were: a dozen men in the Crown Hotel, all together in the smoking-lounge, looking like they'd only met there by chance.' Yes, the explicit narrative data conveyed in the two are the same, but just as you wouldn't be happy with your publisher simply producing a sort of casual paraphrase of your writing and publishing that under your name, so your foreign-language publishers are hiring people to write exactly the same book as the one you've written. (Except for all the words, obviously.) Sound difficult? The reality is harder still. Every language is different. There's no single word in one language that maps perfectly onto a word in another - not one. And every language has things it can do, and things it can't."
"Once the contract is signed, the translator takes a deep breath and dives in. Their job is two-fold, and simple: they read you, then they write you.
They read you with more care than anybody else will, more demandigly, more inquiringly. Yes, your editor might take a moment to consider your punctuation if it doesn't work and needs rethinking, but translators have to think hard about it even - or especially - if it does."
A beautiful piece on translators: "The curious condition of being a translator" by Daniel Hahn via Paula Góes on GV-Authors mailing list.
First of all, let me say this: Barcelona MiniDebconf was awesome.
So the most important part of this post is a very big thank you to the organizers, volunteers, speakers, sponsors and attendees.
Now, down to business.
Day 0 was a day of travelling, more or less: the Italian Cabal (me, Enrico, Elena and Diego) left in the early morning from Varese (where we had an epic Munchkin Apocalypse game the night before), and we travelled by car across Liguria and France and finally reached Barcelona in the evening.
(Boring! Even more if you don't drive. I hate long trips by car)
We reached Barcelona in time for the pre-registration event at Falstaff Bar, eat a great Falafel and hugged lots of people.
To me the highlight of Day 1 was to finally meet in person Laura Arjona, Spanish translator, publicity volunteer, pump.io and mediagoblin contributor. We had decided to have a workshop together about translations and we spent the morning more or less tweaking our presentation and chatting :). So, save for Elena's talk on 3d printing in Debian ("The Universal OS: now making tabletop games and cookie cutters!" -- which was great!) I missed all the talks in the morning.
But thanks to the always amazing videoteam, I'll be able to watch them later, when the recordings will be published :).
For me, the best talk of the day - well, no, actually of the conference! - was that afternoon: Ana Isabel Carvalho told us about the Libre Graphics Magazine project.
Libre Graphics Magazine is a well written and designed magazine at the crossroad between Free Software tools and ideals and graphic arts and design. A crossroad not very much frequented, I'd say. But then, maybe I'm wrong: it's not that graphic artists don't use Free Software tools, it's more like the one who do are invisible.
This is one purpose of a Libre Graphics Magazine: to serve as a catalyst for discussion, to build a home for the users of Libre Graphics software, standards and methods. In such a magazine, we may unite all our previously disparate successes, all the successes which have, until now, stood alone as small examples, disjointed from the larger community. We have the opportunity to elevate the discourse around Libre Graphics as a professionally viable option, to raise previously unmentioned issues and to push forward the conception of just what Libre Graphics can produce.
If you are even only vagued interested in typefaces, fonts, design and graphic art take a look at the magazine: it's CC-BY-SA licensed and you can download it for free, or buy a paper copy (which is amazing, really!). And it's not just about graphic arts: if you skim over the titles of the issues, you can find that they've talked about things like "Localisation/Internationalization", "Use Cases and Affordances" and, my favourite, "Gendering F/LOSS".
On a similar topic, Siri's talk about "Why aren't more designers using Debian or working for Debian?" tried to shed a light on the difficult relationship between Free Software tools and graphic artists.
These are the voices we need to listen to if we want to bring more graphic artists to Debian, and $deity knows that Debian needs them a lot :).
After Solveig's talk about bug triaging and Miriam's one on packaging, it was time for the l10n workshop. I think it went well: we tried to briefly explain the translation workflow in Debian, and to translate together with the audience a po-debconf message. It wasn't maybe enough to complete and submit a translation, but hopefully it gave the audience an idea about how to do it.
The day ended with a party for Debian Women 10th anniversary. And the cake wasn't a lie, beside being very good.
This, I'll remember as "the day I exited my comfort zone". Ok, I'm making a bit of fuss about it, but it was my first talk in English all alone. I spoke about the non-uploading DD process and how to keep your (and others') sanity in a big community project (slides here). I think it's very important to remind people that not all DDs are coding persons. And you don't need to be a developer to love Debian, contribute to it and become an official member of the project.
But writing this presentation was for me also the occasion to take stock of my experience in Debian so far: in that talk slipped many of my demons, as impostor syndrome or overcommitment. But all the things I said are more or less, common sense - nothing new! - and lesson learned on the road: it's been now 2 years as DD and 4 as contributor. I'm pretty sure it's thanks to the special conditions of this conference (only speakers identifying themselves as female, a safe and very friendly environment) that I had the courage to give a talk. So the conference was a complete success on that regard, too.
In the afternoon I was able to do one of the things I love: videoteam duty. Though I convinced Riccio to switch roles and to give me the camera: my experience in directing during last DebConf left me a bit scarred.
The Day(s) after: a Debian Contributors hackathon
In my experience a measure of a conference's success is the burst of activity in pet projects just afterwards.
In this, also, Barcelona MiniConf was a success: during the weekend, Enrico, Laura and I had the chance to talk together
about Debian Contributors and make some plans.
So, as soon as we got in Italy again, I took possession of Enrico's couch for a couple of days and we did a little bit of hacking on Contributors.
For my part, I mostly worked in trying to add more data sources to the site: my (not so) secret agenda is to map most of the non-coding contributions. That basically means: translators, publicity editors, event organizers and volunteers, etc.
Being in the same room as Enrico, gave me the chance to ask him how to add data sources and to test the existing code (we spot a little problem in the prototype for svn repository mining he made a while ago). At the end of the hackathon, I had managed to:
- add the debconfsubs project to the data sources
- add bits.debian.org to the data sources
- add publicity svn repo to the data sources
- clean up the wiki todo list
- ask penta debconf admins about adding debconf volunteers to contributors
Please note that if you have contributed to one of the repo above and you are not listed there, it means that the automatic recognition of your email address didn't work. We still need to implement a manual interface for the recognition of email addresses: patches are very much welcome!
- Implemented showing the log of all changes involving a person in the personal page
- Implemented visibility settings in the personal page
- Redone data aggregation, so that it can be computed after each setting change and after each data submission
- Implemented editing one's own display name
- Autofill people's display names from Debian and Alioth user full name information
- Read Debian and Alioth email forwarding fields to auto-associate more contributions to people
- Show activity of teams, not only of people
- Main contributors.debian.org page only shows the last year, with pagination for the previous ones
- Added some statistics to the Site status page
- New version of dc-tool, with fixed svn data source and quiet operation by default
- Auto-associate OpenPGP key fingerprints using Debian's LDAP
- Drafted about/privacy page
A quick roundup of things I made during the last months, following tutorials here and there.
1: a soft bunny more or less based on this one
2: skelly man! You can find pattern and instructions on Chez Beeper Bebe's blog
3: bibs: the embroidered one is based on this pattern by Charlotte Lyons on SouleMama's blog, the other re-uses the same pattern but add a bird applique instead.
1, 4: my first try with the beautiful Weekender Bag ended with
something else entirely: apparently, where euclidean geometry principles apply, cutting a piece of fabric 10 cm smaller
will result in a bag 10 cm smaller!
Go figure! Fhtang!
I'm happy anyway with the final result, but it resembles more a tote bag than a weekender one. I then made also a successful Weekender, but haven't taken a pic yet. If you try that pattern, you may find this blogpost helpful.
2: This is my try at copycatting this model without a pattern and didn't end very well.
However, a couple lessons learned:
- you don't improvise armholes and sleeves: you have to carefully plan them. I know this now, but at the time I was just a kid with a crazy dream ;)
- a-line dresses with straight necklines are definitely not meant for my body type. no matter how cute they look on someone else.
- I really should hack my mannequin, so to have it of my actual size. Or I will continue sew clothes fitting it, and not me.
3: Blouse with knit-stretchy stuff! (You love me when I speak technical, don't you?)
I did that without pattern, mostly using a similar top I have as inspiration/guide
With the help of Enrico and the Debian Listmaster Team
-and in particular Alexander Wirt: thank you very much! - the spam reviewers of the Debian mailing lists have been added to the list
of Debian Contributors.
While some statistics about the reviewing job already existed, adding these data to the Debian Contributors list is another little step to map all kind of Debian contributions.
Wondering what exactly is the job of the spam reviewers?
It consists in checking all the messages of the Debian mailing lists reported as spam: if a message reported as spam gets three reviews as spam (and none as ham) it is removed from the archive.
Only DDs can do this: if you are one check here how to do it.
But there's one - and probably more important job - that everyone can do: report spam. When a message is reported as spam by 5 or more persons, it will make to the reviewers' queue. There are some organized spam cleaning efforts you can join: here there's a list of them, while on this page you can find more information on the whole process.
Wondering what exactly is the Debian Contributors list?