On 2017-08-06 I have a talk at DebConf17 in Montreal titled "Consensually doing things together?" (video). Here are the talk notes. Abstract At DebConf Heidelberg I talked about how Free Software has a lot to do about consensually doing things together. Is that always true, at least in Debian? I d like to explore what motivates one to start a project and what motivates one to keep maintaining it. What are the energy levels required to manage bits of Debian as the project keeps growing. How easy it is to say no. Whether we have roles in Debian that require irreplaceable heroes to keep them going. What could be done to make life easier for heroes, easy enough that mere mortals can help, or take their place. Unhappy is the community that needs heroes, and unhappy is the community that needs martyrs. I d like to try and make sure that now, or in the very near future, Debian is not such an unhappy community. Consensually doing things together I gave a talk in Heidelberg. Valhalla made stickers Debian France distributed many of them. There's one on my laptop. Which reminds me of what we ought to be doing. Of what we have a chance to do, if we play our cards right. I'm going to talk about relationships. Consensual relationships. Relationships in short. Nonconsensual relationships are usually called abuse. I like to see Debian as a relationship between multiple people. And I'd like it to be a consensual one. I'd like it not to be abuse. Consent From wikpedia:

In Canada "consent means the voluntary agreement of the complainant to engage in sexual activity" without abuse or exploitation of "trust, power or authority", coercion or threats.[7] Consent can also be revoked at any moment.[8] There are 3 pillars often included in the description of sexual consent, or "the way we let others know what we're up for, be it a good-night kiss or the moments leading up to sex." They are:

• Knowing exactly what and how much I'm agreeing to
• Expressing my intent to participate
• Deciding freely and voluntarily to participate[20]

Saying "I've decided I won't do laundry anymore" when the other partner is tired, or busy doing things. Is different than saying "I've decided I won't do laundry anymore" when the other partner has a chance to say "why? tell me more" and take part in negotiation. Resources:

• https://www.morethantwo.com/blog/2013/10/guest-post-on-consent-in-romantic-relationships

Relationships Debian is the Universal Operating System. Debian is made and maintained by people. The long term health of debian is a consequence of the long term health of the relationship between Debian contributors. Debian doesn't need to be technically perfect, it needs to be socially healthy. Technical problems can be fixed by a healty community. The Thomas-Kilmann Conflict Mode Instrument: source png. Motivations Quick poll:

• how many of you do things in Debian because you want to?
• how many of you do things in Debian because you have to?
• how many of you do both?

What are your motivations to be in a relationship? Which of those motivations are healthy/unhealthy?

• healthy sustain the relationship
• unhealthy may explode spectacularly at some point

"Galadriel" (noun, by Francesca Ciceri): a task you have to do otherwise Sauron takes over Middle Earth See: http://blog.zouish.org/nonupdd/#/22/1 What motivates me to start a project or pick one up?

• I have an idea for for something fun or useful
• I see something broken and I have an idea how to fix it

What motivates me to keep maintaning a project?

• Nobody else can do it
• Nobody else can be trusted to do it
• Nobody else who can and can be trusted to do it is doing it
• Somebody is paying me to do it

What motivates you? What's an example of a sustainable motivation?

• it takes me little time?
• it's useful for me
• It's fun
• It saves me time to keep something running that if it breaks when I or somebody else needs it
• it makes me feel useful? (then if I stop, I become useless, then I can't afford to stop?)
• Getting positive feedback (more "you're good" than "i use it") ?

Is it really all consensual in Debian?

• what tasks are done by people motivated by guilt / motivated by Galadriel?
• if I volunteer to help team X that is in trouble, will I get stuck doing all the work as soon as people realise things move fine again and finally feel free to step back?

Energy Energy that thing which is measured in spoons. The metaphore comes from people suffering with chronic health issues:

"Spoons" are a visual representation used as a unit of measure used to quantify how much energy a person has throughout a given day. Each activity requires a given number of spoons, which will only be replaced as the person "recharges" through rest. A person who runs out of spoons has no choice but to rest until their spoons are replenished.

• https://s-media-cache-ak0.pinimg.com/736x/c3/05/dc/c305dc9d3ac3c2219f267dbc47bfacf5.jpg
• https://feckingme.files.wordpress.com/2015/05/keep-track-of-your-spoons.jpg

For example, in Debian, I could spend:

• Routine task: 1 spoon
• Context switch: 2 spoons
• New corner case: 5 spoons
• Well written bug report: -1 spoon
• Interesting thread: -1 spoon
• New flamewar: 3 spoons

What is one person capable of doing?

• are the things that we expect a person to do the things that one person can do?
• having a history of people who can do it anyway is no excuse: show compassion to those people, take some of their work, thank them, but don't glorify them

Have reasonable expectations, on others:

• If someone is out of spoons, they're out of spoons; they don't get more spoons if you insist; if you insist, you probably take even more spoons from them
• If someone needs their spoons for something else, they are entitled to
• If someone gets out of spoons for something important, and nobody else can do it, it's not their fault but a shared responsibility

Have reasonable expectations, on yourself:

• If you are out of spoons, you are out of spoons
• If you need spoons for something else, use them for something else
• If you are out of spoons for something important, and nobody else can do it, it's not your problem, it's a problem in the community

Debian is a shared responsibility

• Don't expect few people to take care of everything
• Leave space for more people to take responsibility for things
• Turnover empowers
• Humans are a renewable resource, but only if you think of them that way

When spoons are limited, what takes more energy tends not to get done

• routine is ok
• non-routine tends to get stuck in the mailbox waiting for a day with more free time
  • are we able to listen when tricky cases happen?
  • are we able to respond when tricky cases happen?
  • are we able to listen/respond when socially tricky cases happen?
  • are we able to listen/respond when harassment happens?
  • can we tell people raising valid issues from troublemakers?
• in NM
  • it's easier to accept a new maintainer than to reject them
  • it's hard or impossible to make a call on a controversial candidate when one doesn't know that side of Debian
• I'm tired, why you report a bug? I don't want to deal with your bug. Maybe you are wrong and your bug is invalid? It would be good if you were wrong and your bug was invalid.
• even politeness goes when out of spoons because it's too much effort

As the project grows, project-wide tasks become harder Are they still humanly achievable?

• release team
• DAM (amount of energy to deal with when things go wrong; only dealing with when things go spectacularly wrong?)
• DPL (how many people candidate to this year elections?)

I don't want Debian to have positions that require hero-types to fill them

• heroes are rare
• heroes are hard to replace
• heroes burn out
• heroes can become martyrs
• heroes can become villains
• heroes tend to be accidents waiting to happen

Dictatorship of who has more spoons:

• Someone who has a lot of energy can take more and more tasks out of people who have less, and slowly drive all the others away
• Good for results, bad for the team
• Then we have another person who is too big to fail, and another accident waiting to happen

Perfectionism You are in a relationship that is just perfect. All your friends look up to you. You give people relationship advice. You are safe in knowing that You Are Doing It Right. Then one day you have an argument in public. You don't just have to deal with the argument, but also with your reputation and self-perception shattering. One things I hate about Debian: consistent technical excellence. I don't want to be required to always be right. One of my favourite moments in the history of Debian is the openssl bug Debian doesn't need to be technically perfect, it needs to be socially healthy, technical problems can be fixed. I want to remove perfectionism from Debian: if we discover we've been wrong all the time in something important, it's not the end of Debian, it's the beginning of an improved Debian. Too good to be true There comes a point in most people's dating experience where one learns that when some things feel too good to be true, they might indeed be. There are people who cannot say no:

• you think everything is fine, and you discover they've been suffering all the time and you never had a clue

There are people who cannot take a no:

• They depend on a constant supply of achievement or admiration to have a sense of worth, therefore have a lot of spoons to invest into getting it
• However, when something they do is challenged, such as by pointing out a mistake one has made, or a problem with their behaviour, all hell breaks loose, beacuse they see their whole sense of worth challenged, too

Note the diversity statement: it's not a problem to have one of those (and many other) tendencies, as long as one manages to keep interacting constructively with the rest of the community Also, it is important to be aware of these patterns, to be able to compensate for one's own tendencies. What happens when an avoidant person meets a narcissistic person, and they are both unaware of the risks? Resources:

• Examples of abuse patterns (trigger warning: judgemental)
• Wikipedia on narcissist personality, supply, injury and rage (trigger warning: medical)

Note: there are problems with the way these resources are framed:

• These topics are often very medicalised, and targeted at people who are victims of abuse and domestic violence.
• I find them useful to develop regular expressions for pattern matching of behaviours, and I consider them dangerous if they are used for pattern matching of people.

Red flag / green flag http://pervocracy.blogspot.ca/2012/07/green-flags.html Ask for examples of red/green flags in Debian. Green flags:

• you heard someone say no
• you had an argument with someone and the outcome was positive for both

Red flags:

• you feel demeaned
• you feel invalidated

Apologies / Dealing with issues I don't see the usefulness of apologies that are about accepting blame, or making a person stop complaining. I see apologies as opportunities to understand the problem I caused, help fix it, and possibly find ways of avoiding causing that problem again in the future. A Better Way to Say Sorry lists a 4 step process, which is basically what we do when in bug reports already: 1, Try to understand and reproduce the exact problem the person had. 2. Try to find the cause of the issue. 3. Try to find a solution for the issue. 4. Verify with the reporter that the solution does indeed fix the issue. This is just to say

My software ate
the files
that where in
your home directory and which
you were probably
needing
for work Forgive me
it was so quick to write
without tests
and it worked so well for me

(inspired by a 1934 poem by William Carlos Williams) Don't be afraid to fail Don't be afraid to fail or drop the ball. I think that anything that has a label attached of "if you don't do it, nobody will", shouldn't fall on anybody's shoulders and should be shared no matter what. Shared or dropped. Share the responsibility for a healthy relationship Don't expect that the more experienced mates will take care of everything. In a project with active people counted by the thousand, it's unlikely that harassment isn't happening. Is anyone writing anti-harassment? Do we have stats? Is having an email address and a CoC giving us a false sense of security?

When you get involved in a new community, such as Debian, find out early where, if that happens, you can find support, understanding, and help to make it stop. If you cannot find any, or if the only thing you can find is people who say "it never happens here", consider whether you really want to be in that community.

(from http://www.enricozini.org/blog/2016/debian/you-ll-thank-me-later/)

There are some nice people in the world. I mean nice people, the sort I couldn t describe myself as. People who are friends with everyone, who are somehow never involved in any argument, who seem content to spend their time drawing pictures of bumblebees on flowers that make everyone happy. Those people are great to have around. You want to hold onto them as much as you can. But people only have so much tolerance for jerkiness, and really nice people often have less tolerance than the rest of us. The trouble with not ejecting a jerk whether their shenanigans are deliberate or incidental is that you allow the average jerkiness of the community to rise slightly. The higher it goes, the more likely it is that those really nice people will come around less often, or stop coming around at all. That, in turn, makes the average jerkiness rise even more, which teaches the original jerk that their behavior is acceptable and makes your community more appealing to other jerks. Meanwhile, more people at the nice end of the scale are drifting away.

(from https://eev.ee/blog/2016/07/22/on-a-technicality/) Give people freedom If someone tries something in Debian, try to acknowledge and accept their work. You can give feedback on what they are doing, and try not to stand in their way, unless what they are doing is actually hurting you. In that case, try to collaborate, so that you all can get what you need. It's ok if you don't like everything that they are doing. I personally don't care if people tell me I'm good when I do something, I perceive it a bit like "good boy" or "good dog". I rather prefer if people show an interest, say "that looks useful" or "how does it work?" or "what do you need to deploy this?" Acknowledge that I've done something. I don't care if it's especially liked, give me the freedom to keep doing it. Don't give me rewards, give me space and dignity. Rather than feeding my ego, feed by freedom, and feed my possibility to create.

"Every now and then I install and try emacs, just because. Usually this happens:

(aghisla talking about editors -- quoted with permission)

Debian and FLOSS community don't only occupy coding developers. They occupy people who write news, who talk about FLOSS, who help on booths and conferences, who create artistic forms of the community and so many others that contribute in countless ways. A lady, that is doing many of that is Francesca Ciceri, known in Debian as MadameZou. She is non-packaging Debian Developer, a fearless warrior for diversity and a zombie fan. Although it sounds intimidating, she is deep caring and great human being. So, what has MadaZou to tell us? Who are you? My name is Francesca and I'm totally flattered by your intro. The fearless warrior part may be a bit exaggerated, though. What have you done and what are you currently working on in FLOSS world? I've been a Debian contributor since late 2009. My journey in Debian has touched several non-coding areas: from translation to publicity, from videoteam to www. I've been one of the www.debian.org webmasters for a while, a press officer for the Project as well as an editor for DPN. I've dabbled a bit in font packaging, and nowadays I'm mostly working as a Front Desk member. Setup of your main machine? Wow, that's an intimate question! Lenovo Thinkpad, Debian testing. Describe your current most memorable situation as FLOSS member? Oh, there are a few. One awesome, tiring and very satisfying moment was during the release of Squeeze: I was member of the publicity and the www teams at the time, and we had to pull a 10 hours of team work to put everything in place. It was terrible and exciting at the same time. I shudder to think at the amount of work required from ftpmaster and release team during the release. Another awesome moment was my first Debconf: I was so overwhelmed by the sense of belonging in finally meeting all these people I've been worked remotely for so long, and embarassed by my poor English skills, and overall happy for just being there... If you are a Debian contributor I really encourage you to participate to Debian events, be they small and local or as big as DebConf: it really is like finally meeting family. Some memorable moments from Debian conferences? During DC11, the late nights with the "corridor cabal" in the hotel, chatting about everything. A group expedition to watch shooting stars in the middle of nowhere, during DC13. And a very memorable videoteam session: it was my first time directing and everything that could go wrong, went wrong (including the speaker deciding to take a walk outside the room, to demonstrate something, out of the cameras range). It was a disaster, but also fun: at the end of it, all the video crew was literally in stitches. But there are many awesome moments, almost too many to recall. Each conference is precious on that regard: for me the socializing part is extremely important, it's what cements relationships and help remote work go smoothly, and gives you motivation to volunteer in tasks that sometimes are not exactly fun. You are known as Front Desk member for DebConf's - what work does it occupy and why do you enjoy doing it? I'm not really a member of the team: just one of Nattie's minions! You had been also part of DebConf Video team - care to share insights into video team work and benefits it provides to Debian Project? The video team work is extremely important: it makes possible for people not attending to follow the conference, providing both live streaming and recording of all talks. I may be biased, but I think that DebConf video coverage and the high quality of the final recordings are unrivaled among FLOSS conferences - especially since it's all volunteer work and most of us aren't professional in the field. During the conference we take shifts in filming the various talks - for each talk we need approximately 4 volunteers: two camera operators, a sound mixer and the director. After the recording, comes the boring part: reviewing, cutting and sometimes editing the videos. It's a long process and during the conference, you can sometimes spot the videoteam members doing it at night in the hacklab, exhausted after a full day of filming. And then, the videos are finally ready to be uploaded, for your viewing pleasure. During the last years this process has become faster thanks to the commitment of many volunteers, so that now you have to wait only few days, sometimes a week, after the end of the conference to be able to watch the videos. I personally love to contribute to the videoteam: you get to play with all that awesome gear and you actually make a difference for all the people who cannot attend in person. You are also non-packaging Debian Developer - how does that feel like? Feels awesome! The mere fact that the Debian Project decided - in 2009 via a GR - to recognize the many volunteers who contribute without doing packaging work is a great show of inclusiveness, in my opinion. In a big project like Debian just packaging software is not enough: the final result relies heavily on translators, sysadmins, webmasters, publicity people, event organizers and volunteers, graphic artists, etc. It's only fair that these contributions are deemed as valuable as the packaging, and to give an official status to those people. I was one of the firsts non-uploading DD, four years ago, and for a long time it was just really an handful of us. In the last year I've seen many others applying for the role and that makes me really happy: it means that finally the contributors have realized that they deserve to be an official part of Debian and to have "citizenship rights" in the project. You were the leading energy on Debian's diversity statement - what gave you the energy to drive into it? It seemed the logical conclusion of the extremely important work that Debian Women had done in the past. When I first joined Debian, in 2009, as a contributor, I was really surprised to find a friendly community and to not be discriminated on account of my gender or my lack of coding skills. I may have been just lucky, landing in particularly friendly teams, but my impression is that the project has been slowly but unequivocally changed by the work of Debian Women, who raised first the need for inclusiveness and the awareness about the gender problem in Debian. I don't remember exactly how I stumbled upon the fact that Debian didn't have a Diversity Statement, but at first I was very surprised by it. I asked zack (Stefano Zacchiroli), who was DPL at the time, and he encouraged me to start a public discussion about it, sending out a draft - and helped me all the way along the process. It took some back and forth in the debian-project mailing list, but the only thing needed was actually just someone to start the process and try to poke the discussion when it stalled - the main blocker was actually about the wording of the statement. I learned a great deal from that experience, and I think it changed completely my approach in things like online discussions and general communication within the project. At the end of the day, what I took from that is a deep respect for who participated and the realization that constructive criticism does require certainly a lot of work for all parts involved, but can happen. As for the statement in itself: these things are as good as you keep them alive with best practices, but I think that are better stated explicitly rather than being left unsaid. You are involved also with another Front Desk, the Debian's one which is involved with Debian's New Members process - what are tasks of that FD and how rewarding is the work on it? The Debian Front Desk is the team that runs the New Members process: we receive the applications, we assign the applicant a manager, and we verify the final report. In the last years the workflow has been simplified a lot by the re-design of the nm.debian.org website, but it's important to keep things running smoothly so that applicants don't have too lenghty processes or to wait too much before being assigned a manager. I've been doing it for a less more than a month, but it's really satisfying to usher people toward DDship! So this is how I feel everytime I send a report over to DAM for an applicant to be accepted as new Debian Developer: How do you see future of Debian development? Difficult to say. What I can say is that I'm pretty sure that, whatever the technical direction we'll take, Debian will remain focused on excellence and freedom. What are your future plans in Debian, what would you like to work on? Definetely bug wrangling: it's one of the thing I do best and I've not had a chance to do that extensively for Debian yet. Why should developers and users join Debian community? What makes Debian a great and happy place? We are awesome, that's why. We are strongly committed to our Social Contract and to users freedom, we are steadily improving our communication style and trying to be as inclusive as possible. Most of the people I know in Debian are perfectionists and outright brilliant in what they do. Joining Debian means working hard on something you believe, identifying with a whole project, meeting lots of wonderful people and learning new things. It ca be at times frustrating and exhausting, but it's totally worth it. You have been involved in Mozilla as part of OPW - care to share insights into Mozilla, what have you done and compare it to Debian? That has been a very good experience: it meant have the chance to peek into another community, learn about their tools and workflow and contribute in different ways. I was an intern for the Firefox QA team and their work span from setting up specific test and automated checks on the three version of Firefox (Stable, Aurora, Nightly) to general bug triaging. My main job was bug wrangling and I loved the fact that I was a sort of intermediary between developers and users, someone who spoke both languages and could help them work together. As for the comparison, Mozilla is surely more diverse than Debian: both in contributors and users. I'm not only talking demographic, here, but also what tools and systems are used, what kind of skills people have, etc. That meant reach some compromises with myself over little things: like having to install a proprietary tool used for the team meetings (and getting crazy in order to make it work with Debian) or communicating more on IRC than on mailing lists. But those are pretty much the challenges you have to face whenever you go out of your comfort zone . You are also volunteer of the Organization for Transformative Works - what is it, what work do you do and care to share some interesting stuff? OTW is a non profit organization to preserve fan history and cultures, created by fans. Its work range from legal advocacy and lobbying for fair use and copyright related issues, developing and maintaining AO3 -- a huge fanwork archive based on open-source software --, to the production of a peer-reviewed academic journal about fanworks. I'm an avid fanfiction reader and writer, and joining the OTW volunteers seemed a good way to give back to the community - in true Debian fashion . As a volunteer, I work for the Translation Committee: we are more than a hundred people - divided in several language teams - translating the OTW website, the interface of AO3 archive, newsletter, announcements and news posts. We have a orga-wide diversity statement, training for recruits, an ever growing set of procedures to smooth our workflow, monthly meetings and movie nights. It's an awesome group to work with. I'm deeply invested in this kind of work: both for the awesomeness of OTW people and for the big role that fandom and fanworks have in my life. What I find amazing is that the same concept we - as in the FLOSS ecosystem - apply to software can be applied to cultural production: taking a piece of art you love and expand, remix, explore it. Just for the fun of it. Protect and encourage the right to play in this cultural sandbox is IMO essential for our society. Most of the participants in the fandom come from marginalised group or minorities whose point of view is usually not part of the mainstream narratives. This makes the act of writing, remixing and re-interpreting a story not only a creative exercise but a revolutionary one. As Elizabeth Minkel says: "My preferred explanation is the idea that the vast majority of what we watch is from the male perspective authored, directed, and filmed by men, and mostly straight white men at that. Fan fiction gives women and other marginalised groups the chance to subvert that perspective, to fracture a story and recast it in her own way." In other words, "fandom is about putting debate and conversation back into an artistic process". On a personal side - you do a lot of DIY, handmade works. What have you done, what joy does it bring to you and share with us a picture of it? I like to think that the hacker in me morphs in a maker whenever I can actually manipulate stuff. The urge to explore ways of doing things, of create and change is probably the same. I've been blessed with curiousity and craftiness and I love to learn new DIY techniques: I cannot describe it, really, but if I don't make something for a while I actually feel antsy. I need to create stuff. Nowadays, I'm mostly designing and sewing clothes - preferably reproductions of dresses from the 40s and the 50s - and I'm trying to make a living of that. It's a nice challenge: there's a lot of research involved, as I always try to be historically accurate in design, sewing tecniques and material, and many hours of careful attention to details. I'm right in the process of make photoshoots for most of my period stuff, so I'll share with you something different: a t-shirt refashion done with the DebConf11 t-shirt! (here's the tutorial)

DON T THINK OF IT AS DYING, said Death. JUST THINK OF IT AS LEAVING EARLY TO AVOID THE RUSH.

Terry Pratchett, Good Omens: The Nice and Accurate Prophecies of Agnes Nutter, Witch Thank you for everything you wrote. Each and every line was a gem, with another gem hidden inside.

"As long as people still think of people like me as "a dude in a dress" there is a lot work to do to fight transphobia and gain tolerance and acceptance."

This line in Rhonda's most recent blogpost broke my heart a little, and sparked an interesting conversation with her about the (perceived?) value of clothes, respect and identity. So, guess what? Here's a pic of a "girl in trousers". Just because. (Sorry for the quality: couldn't find my camera and had to use a phone. Also, I don't own a binder, so I used a very light binding)

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).

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! :) 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!).

[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. 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). 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! 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.

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! 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! 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: 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 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. 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. Documentation 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! Lessons learned

• 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 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 :) 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. 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.

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. 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. AFAICT, there are basically three main sources of documentation:

1. the wiki
2. the Mozilla Developer Network
3. the site of the QA team

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!

1. a bug's life: lifecycle of bugs in BMO
2. Tyler's BMO survival guide (parts 1, 2 and 3)
3. Tyler's Triage Guidelines
4. on reducing testcases
5. bug verification walkthrough

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/

"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.

Wow, I cannot believe it has already been 2 weeks from MiniDebConf Barcelona.
It has been the first Debian event (and free software conference) that I have attended in person, and I took the opportunity to get more involved, giving a talk about translations together with Francesca Ciceri, and two lightning talks about two free software projects that I use and love and I d like to see them packaged for Debian: Pump.io and GNU MediaGoblin (videos coming soon). I also somehow-promoted Keysigning during the conference (well, in fact, I just sent some two emails to the mailing list before, and printed stickers with May I sign your key? slogan so we could keysign easily in the freetime between talks). The people I ve met some people in person, who I was following in the Debian mailing lists and identi.ca for long time (years, in some cases \o/). It has been amazing to meet Francesca Ciceri and Enrico Zini, since their blogposts and vision about Debian diversity skills have influenced very much in my involvement in Debian. It has been very important to me to be able to say THANK YOU to Tiago from the Debian video team (sorry Holger, I couldn t manage to meet you face to face), because I have learned so many things watching videos from Debconfs! Videos helped me to feel that I m part of the community, even when I cannot attend to the events, by following the streaming and being able to recognize the faces of the people and the work they do in Debian. I ve met many Debian Women, of course. I m so fan of all of them! I m enjoying a welcoming and diverse community thanks to many of them that worked since many years ago to make Debian what it is now, and faced bitter moments too. I cannot say that I engaged in many deep conversations (well, maybe some 2 or 3, and me mostly listening), but the most important thing that I keep from them was simply being there , watching and listening, enjoying the voices of the experience like Ana and Miriam, and the freshness and joy of Tassia, Solveig and Elena, for example. I ve tried to be welcoming too, I m not a newbie anymore as new people come to the group :) New projects (and renewing forces for other) Debian contributors I wanted to get more involved in the Debian contributors project and it has been a perfect opportunity to understand better all what I had read and watched about it before going to Barcelona. My plan is, apart of doing promotion as with all the projects that I use and love, to try to get translator work credited via Debian Contributors. That means to hack the l10n bot that now gathers info from the mailing lists to build the coordination pages for translators. It shouldn t be difficult to make it send that info to contributors.debian.org site, but I ll try to understand how it works and propose an elegant patch. No idea about Perl, btw, but anyway, it s a good excuse to start learning. Mediagoblin and pump.io packaging I m not sure I can help on this, but I ll keep an eye in the evolution of the Debian packaging of GNU MediaGoblin and the Pumpiverse software. I ll give moral support, at least, to the people actually working on that :) Website and Publicity team After Solveig s talk about bug triaging I ve been thinking about some bugs that I reviewed in the Website and Publicity team, and I think I should make a new round on the pending bugs to close them if they don t apply anymore, or to try to push a bit more towards a solution, if I can. Tails website translation Tails is a Debian derivative preconfigured to work out-of-the-box with privacy and anonymity features, since uses the Tor network for all the outgoing and ingoing connections.
Solveig proposed me to join the Spanish translators team at Tails. I just joined the translators mailing list, in order to help translating the Tails website into Spanish (the software is already translated, under the Tor Project). This is a new challenge from the translation point of view, since they work with PO files. And now, what? Well, first, I ll try to clean a bit my TODO list, mainly about translations, and other things not related to Debian. From now on until summer, I ll keep an eye and a hand on all the projects in which I am involved, and also I ll try to keep on engaging with the community via pump.io, the mailing lists, and IRC channels. Next summer, if I can put in order my GPG keys (long story), I ll try to join the Debian New Member process. If not, I ll try to get new keys and some signs, and then I ll apply. OTOH, thanks to the end of Windows XP support, it seems that some people are willing to migrate to any GNU/Linux distribution, and of course I m recommending Debian. Expect some blog posts about these migrations (wow, I should migrate some servers that still run Squeeze too ) and my new role of Debian help desk at job, if finally some people decide to migrate. I have gathered Debian stickers to proudly give to anyone that installs Debian in their computer!
Filed under: Events, My experiences and opinion, Videos Tagged: Communities, Contributing to libre software, Debian, English, Free Software, libre software, MediaGoblin, Moving into free software, pump.io, translations

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 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. Day 1 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. Day 2 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. Special mention for Laura speaking of pump.io and MediaGoblin and Solveig of Tails during the "Lightning Talks" and the people from LelaCoders during the "Bits from Local Communities" session. 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! Meanwhile Enrico:

• 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

If you care about recognition of diverse contributions in Debian, help us: read the project todo list and subscribe to the low traffic mailing list or browse the project Git repository.

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

On responsibilities I feel like in my Debian projects I have two roles: the person with the responsibility of making the project happen, and the person who does the work to make it happen. As the person responsible for the project, I need to keep track of vision, goals, milestones, status. To make announcements, find contributors, motivate them, deal with users and bug reports, maintain documentation, digest feedback. As the person who does the work to make it happen, I need quiet time, I need to study technology, design code, write unit tests, merge patches, code, code, code, ask around about deployment information, more code. I have a hard time doing both things at the same time: the first engages my social skills and extroversion, requires low-latency interaction, and acting when outside things happen. The second engages my technical skills and introversion, requires quiet uninterrupted periods of flow, and acting when inspiration strikes. I never managed to make good use of "gift bugs" or "minions": I often found the phrase "it's easier for me to do than to explain it" sadly relevant. Now I understand that it's not because of the objective difficulty of explaining or doing things, nor about the value of doing or of involving people. It's about switching from one kind of workflow to another. If I rephrase that as "it's easier for me to stay in flux and fix it, than to switch my entire attitude to ask for help". Of course this does not scale: we've all been saying it since I can remember. Looking at the situation from the point of view of those two roles, however, I now wonder if those two roles shouldn't really require two people. In other worlds they are: the project managers, taking responsibility for making the project happen, and the software designers, artists, and all other kind of artisans doing the work to make it happen. Of course I don't want the kind of project manager that shifts responsibilities to artisans, does nothing and takes the credit for the project: not in paid work, not in Debian. Project management is something else. I would be interested instead in having the kind of project manager that takes responsibility for the project, checks how the artisans are doing and communicates what is happening to the rest of the world, deals with the community, motivates more people to help, test, try, use, give feedback on things as they happen. A project manager / community manager. So that while I'm flux there is someone who tags bugs as "gift", mentors people to find code and documentation, and remembers to write an announcement if I implemented three cool things in a row and I'm already busy working on the fourth. So that I don't write cool ideas in my todo list where nobody can read them, but I can share them to a mailing list where someone picks up a relevant one and finds someone to make it happen while I'm busy refactoring old code that only I can understand. So that if I say "sorry, paid work calls, I won't be able to work on this project for a month", I'll be able to completely forget about that project for a whole month, without leaving the community out there to die. That's an interesting job for non-uploading DDs: please take over my projects. Let's share a vision, and team up to make it happen. Give me the freedom of being the craftsman I enjoy being, and take away from me those responsibilities that I've never asked for. The worst project managers are those that never asked to be one, but were promoted to it. Let's not repeat that mistake in Debian. A good part of the credits for this post go to Francesca Ciceri, for the discussions we had on our way back from MiniDebConf Barcelona 2014. P.S. I'm seeing how a non-uploading DD could be in the Maintainer field for one or more packages, with uploading DDs being, well, uploaders. Food for thought.

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? It's a brilliant effort started by Enrico to map all kind of contributions in Debian.
You can read more about it here and here.

I'm sorry, I couldn't resist: words so good need a pretty (fsvo pretty) framing. source