Did you know that the estimated cost of malware is hundreds of billions of dollars per year? Even without data loss or identity theft, the time and annoyance spent dealing with infected machines is a significant cost.

Firefox 31 offers improved malware detection. Firefox has integrated Google’s Safe Browsing API for detecting phishing and malware sites since Firefox 2. In 2012 Google expanded their malware detection to include downloaded files and made it available to other browsers. I am happy to report that improved malware detection has landed in Firefox 31, and will have expanded coverage in Firefox 32.

In preliminary testing, this feature cuts the amount of undetected malware by half. That’s a significant user benefit.

What happens when you download malware? Firefox checks URLs associated with the download against a local Safe Browsing blocklist. If the binary is signed, Firefox checks the verified signature against a local allowlist of known good publishers. If no match is found, Firefox 32 and later queries the Safe Browsing service with download metadata (NB: this happens only on Windows, because signature verification APIs to suppress remote lookups are only available on Windows). In case malware is detected, the Download Manager will block access to the downloaded file and remove it from disk, displaying an error in the Downloads Panel below.

How can I turn this feature off? This feature respects the existing Safe Browsing preference for malware detection, so if you’ve already turned that off, there’s nothing further to do. Below is a screenshot of the new, beautiful in-content preferences (Preferences > Security) with all Safe Browsing integration turned off. I strongly recommend against turning off malware detection, but if you decide to do so, keep in mind that phishing detection also relies on Safe Browsing.

Many thanks to Gian-Carlo Pascutto and Paolo Amadini for reviews, and the Google Safe Browsing team for helping keep Firefox users safe and secure!

http://monica-at-mozilla.blogspot.com/2014/07/download-files-more-safely-with-firefox.html

http://featherweightmusings.blogspot.com/2014/07/libhoare-pre-and-postconditions-in-rust.html

For a while now a number of Mozillians have been discussing the need for some sort of technical training on Gecko and other Mozilla codebases. A few months ago, Vlad and I and a few others came up with a plan to try out a “bootcamp”-like event. We initially thought we’d have non-core developers learn from more senior developers for 4 days and had a few goals:

• teach people not developing Mozilla code daily about the development process
• expose Mozillians to areas with which they’re not familiar
• foster shared ownership of areas of code and tools
• teach people where to look in the code when they encounter a bug and to more accurately file a bug (“teach someone how to fish”)

While working towards this we realized that there isn’t as much shared ownership as there could be within Mozilla codebases so we focused on 2 engineering teams teaching other engineers. The JavaScript and Graphics teams agreed to be mentors and we solicited participants from a few paid Mozillians to try this out. We intentionally limited the audience and hand-picked them for this first “beta” since we had no idea how it would go.

The event took place over 4 days in Toronto in early June. We ended up with 5 or 6 mentors (the Graphics team having a strong employee presence in Toronto helped with pulling in experts here and there) and 9 attendees from a variety of engineering teams (Firefox OS, Desktop, and Platform).

The week’s schedule was fairly loose to accommodate questions and make it more of a conversational atmosphere. We planned sessions in an order to give a high level overview followed by deeper dives. We also made sessions about complementary Gecko components happen in a logical order (ex. layout then graphics). You can see details about the schedule we settled upon here: https://etherpad.mozilla.org/bootcamp1plans.

We collaboratively took notes and recorded everything on video. We’re still in the process of creating usable short videos out of the raw feeds we recorded. Text notes were captured on this etherpad which had some real-time clarifications made by people not physically present (Ms2ger and others) which was great.

The week taught us a few things, some obvious, some not so obvious:

• people really want time for learning. This was noted more than once and positive comments I received made me realize it could have been held in the rain and people would have been happy
• having a few days set aside for professional development was very much appreciated so paid Mozillians incorporating this into their goals should be encouraged
• people really want the opportunity to learn from and ask questions of more seasoned Mozilla hackers
• hosting this in a MozSpace ensured reliable facilities, flexibility in terms of space, and the availability of others to give ad hoc talks and answer questions when necessary. It also allowed others who weren’t official attendees to listen in for a session or two. Having it in the office also let us use the existing video recording setup and let us lean on the ever-amazing Jonathan Lin for audio and video help. I think you could do this outside a MozSpace but you’d need to plan a bit more for A/V and wifi, etc.
• background noise (HVAC, server fans, etc.) is very frustrating for conversations and audio recording (but we already knew this)
• this type of event is unsuitable for brand new {employees|contributors} since it’s way too much information. It would be more applicable after someone’s been involved for a while (6 months, 1 year?).

In terms of lessons for the future, a few things come to mind:

• interactive exercises were very well received (thanks, kats!) and cemented people’s learning as expected
• we should perhaps define homework to be done in advance and strongly encourage completion of it; videos of previous talks may be good material
• scheduling around 2 months in advance seemed to be best to balance “I have no idea what I’ll be doing then” and “I’m already busy that week”
• keeping the ratio of attendees to “instructors” to around 2 or 3 to 1 worked well for interactivity and ensuring the right people were present who could answer questions
• although very difficult, attempting to schedule around major deadlines is useful (this week didn’t work for a few of the Firefox OS teams)
• having people wear lapel microphones instead of a hand-held one makes for much better and more natural audio
• building a schedule, mentors, and attendee list based on common topics of interest would be an interesting experiment instead of the somewhat mixed bag of topics we had this time
• using whiteboards and live coding/demos instead of “slides” worked very well

Vlad and I think we should do this again. He proposed chaining organizers so each organizer sets one up and helps the next person do it. Are you interested in being the next organizer?

I’m very interested in hearing other people’s thoughts about this so if you have any, leave a comment or email me or find me on IRC or send me a postcard c/o the Toronto office (that would be awesome).

http://overholt.ca/wp/?p=456

http://blog.swarnava.in/2014/07/flashing-flame-devices-with-firefox-os.html

A couple of months ago, an experimental feature Google introduced in the ‘Canary’ build of its Chrome browser prompted a flurry of posts in the tech press. The change was to go one step further than displaying an ‘origin chip’ and do away with the URL entirely:

I have to admit that when I first heard of this I was horrified – I assumed it was being done for the worst of reasons (i.e. driving more traffic to Google search). However, on reflection, I think it’s a nice example of progressive complexity. Clicking on the root name of the site reveals the URL. Otherwise, typing in the omnibox allows you to search the web:

Progressive complexity is something we should aspire to when designing tools for a wide range of users. It’s demonstrated well by my former Mozilla colleague Rob Hawkes in his work on ViziCities:

http://slidesha.re/1kbYyYU

Using this approach means that those that are used to manipulating URLs are catered for – but the process is simplified for novice users.

Something we forget is that URLs often depend on the file structures of web servers: http://server.com/directory/sub-directory/file.htm. There’s no particular reason why this should be the case.

Pages on Mac OS X saving to iCloud

Google Drive interface

It’s worth noting that both Apple and Google here don’t presuppose you will create folders to organise your documents and digital artefacts. You can do so, or add tags, but it’s just as easy to dump them all in one place and search efficiently. It’s human-centred design.

My guiding principle here from a web literacy point of view is whether simplification and progressive complexity is communicated to users. Is it clear that there’s more to this than what’s presented on the surface? With the examples I’ve given in this post, I feel that they are.

Questions? Comments? I’m @dajbelshaw or you can email me at doug@mozillafoundation.org.

http://literaci.es/making-the-web-simple

Highlights

This week I rolled out the l10n changes, after a few more iterations of tweaks / improvements / nice-to-haves. I am coordinating with Hal about when we can cut over from legacy (as this will need his involvement) which depends a little bit on his availability - he has already proactively contacted me to let me know he is quite tied up at the moment, so it is unlikely we’ll be able to engage in roll out work together for the next couple of weeks until hg issues have stablised, and he has completed some work with fubar/bkero and the interns.

I’ve had discussions with Aki about various vcs sync matters (both technical and business relationship-wise) and am confident I am in a good position to lead this going forward.

I also rolled out changes to the email notifications, which unfortunately I had to roll back.

Now l10n is done (apart from cutover) the last two parts are gecko.git and gecko-projects - which I anticipate as being relatively trouble-free.

After that comes git-hg and git-git support (currently new vcs sync only supports hg-git).

Other

Looking forward to getting involved with release process (https://bugzilla.mozilla.org/show_bug.cgi?id=1042128)

http://petemoore.tumblr.com/post/92634132373

The gaiatest python package provides a test framework and runner for testing Gaia (the user interface for Firefox OS). It also provides a handy command line tool and can be used as a dependency from other packages that need to interact with Firefox OS.

Documentation for this package has now been moved to gaiatest.readthedocs.org, which is generated directly from the source code whenever there’s an update. In order to make this more useful we will continue to add documentation to the Python source code. If you’re interested in helping us out please get in touch by leaving a comment, or joining #ateam on irc.mozilla.org and letting us know.

http://blargon7.com/2014/07/a-new-home-for-the-gaiatest-documentation/

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

http://blog.zouish.org/posts/opw3/

This is a list (URL acquired from spam) of prices for fraudulent (but perhaps “genuine” in terms of the materials used, I don’t know) passports, driving licenses and ID cards. It is a fascinating insight into the relative security of the identification systems of a number of countries. Of course, the prices may also factor in the economic value of the passport, but it’s interesting that a Canadian passport is more expensive than a US one. That probably reflects difficulty of obtaining the passport rather than the greater desirability of Canada over the US. (Sorry, Canadians, I know you’d disagree! Still, you can be happy at the competence and lack of corruption in your passport service.)

One interesting thing to note is that one of the joint lowest-price countries, Latvia (€900), is a member of the EU. A Latvian passport allows you to live and work in any EU country, even Germany, which has the most expensive passports (€5200). The right to live anywhere in the EU – yours for only €900…

Also interesting is to sort by passport price and look if the other prices follow the same curve. A discrepancy may indicate particularly weak or strong security. So Russian ID cards are cheaper than one might expect, whereas Belgian ones are more expensive. Austrian and Belgian driver’s licenses also seem to be particularly hard to forge, but the prize there goes to the UK, which has the top-priced spot (€2000). I wonder if that’s related to the fact that the UK doesn’t have ID cards, so the driver’s license often functions as one?

Here is the data in spreadsheet form (ODS), so you can sort and analyse, and just in case the original page disappears…

http://feedproxy.google.com/~r/HackingForChrist/~3/Ft7KmaDU15w/

Implemented in bug 853108 by the bmo team, using the tracking flags will automatically updated the comment field with some templates.
The goal is to reduce back and forth in Bugzilla on bug tracking. We also hope that is going to improve our response time.

For example, for the tracking requests (tracking-firefoxNN, tracking-firefox-esrNN or blocking-b2g), the user will see the text added into the Bugzilla comment field:

[Tracking Requested - why for this release]:

With this change, we hope to simplify the decision process for the release team.

For the relnotes-* flags:

Release Note Request (optional, but appreciated)
[Why is this notable]:
[Suggested wording]:
[Links (documentation, blog post, etc)]:

This change aims to simplify the process of release notes writing. In some cases, it can be hard for release manager to translate a bug into a new feature description.

Flags on which this option is enabled are:

• relnote-firefox
• relnote-b2g
• tracking-firefoxNN
• tracking-firefox-esrNN
• blocking-b2g

Finally, we reported bug 1041964 to discuss about a potential auto-focus on the comment area.

http://sylvestre.ledru.info/blog/2014/07/23/auto-comment-on-the-release-mgmt-flags

After my last post on my running GitHub streak, I've pretty much continued to contribute to the same projects, so I didn't see much of a point of posting about it again — the fun part about these posts is talking about all the new projects I've started or joined. However, this time an arbitrary base-ten milestone comes rather close to another development on the GitHub side which is way more awesome than a streak; hence the post.

Firstly, a screenshot:

I wish there was more dark green

Now, let's have a look at the commit that made the streak reach 200. That's right, it's a merge commit to Servo — something which is created for the collaborator who merges the pull request¹. Which is a great segue into the second half of this post:

I now have commit/collaborator access to Servo. :D

It happened around a week back. Ms2ger needed a reviewer, Lars mentioned he wanted to get me more involved, I said I didn't mind reviewing, and in a few minutes I was reviewing a pull request for the first time. A while later I had push access.

This doesn't change my own workflow while contributing to Servo; since everyone still goes through pull requests and reviews. But it gives a much greater sense of belonging to a project. Which is saying something, since Mozilla projects already give one a sense of being "part of the team" rather early on, with the ability to attend meetings, take part in decision-making, and whatnot.

I also now get to review others' code, which is a rather interesting exercise. I haven't done much reviewing before. Pull requests to my own repos don't count much since they're not too frequent and if there are small issues I tend to just merge and fix. I do give feedback for patches on Firefox (mostly for the ones I mentor or if asked on IRC), but in this situation I'm not saying that the code is worthy to be merged; I'm just pointing out any issues and/or saying "Looks good to me".

With Servo, code I review and mark as OK is ready for merging. Which is a far bigger responsibility. I make mistakes (and style blunders) in my own code, so marking someone else's code as mistake free is a bit intimidating at first. Yes, everyone makes mistakes and yet we have code being reviewed properly, but right now I'm new to all this, so I'm allowed a little uncertainty ;) Hopefully in a few weeks I'll be able to review code without overthinking things too much.

---

In other GitHub-ish news, a freshman of my department submitted a very useful pull request to one of my repos. This makes me happy for multiple reasons: I have a special fondness for student programmers who are not from CS (not that I don't like CS students), being one myself. Such students face an extra set of challenges of finding a community, learning the hard stuff without a professor, and juggling their hobby with normal coursework (though to be fair for most CS students their hobby programming rarely intersects with coursework either).

Additionally, the culture of improving tools that you use is one that should be spread, and it's great that at least one of the new students is a part of this culture. Finally, it means that people use my code enough to want to add more features to it :)

^{1. I probably won't count this as part of my streak and make more commits later today. Reviewing is hard, but it doesn't exactly take the place of writing actual code so I may not count merge commits as part of my personal commit streak rules.}

http://inpursuitoflaziness.blogspot.com/2014/07/200-and-more.html

Mozilla's Operations Security team (OpSec) protects the networks, systems, services and data that power the Mozilla project. The nature of the job forces us to keep a lot of our activity behind closed doors. But we thrive to do as much as possible in the open, with projects like MIG, Mozdef, Cipherscan, OpenVPN-Netfilter, Duo-Unix or Audisp-Json.

Opening up security discussions to the community, and to the public, has been a goal for some time, and today we are making a step forward with the OpSec mailing list at

https://lists.mozilla.org/listinfo/opsec

This mailing list is a public place for discussing general security matters among operational teams, such as public vulnerabilities, security news, best practices discussions and tools. We hope that people from inside and outside of Mozilla will join the discussions, and help us keep Mozilla secure.

So join in, and post some cool stuff!

https://jve.linuxwall.info/blog/index.php?post/2014/07/23/OpSec-s-public-mailing-list

http://gittup.org/blog/2014/07/9-moving-automation-steps-in-tree/

If you haven't seen the release notes WebVTT has finally been released in Firefox 31. I'm super excited about this as it's the culmination of a lot of my own and countless others' work over the last two years. Especially since it has been delayed for releases 29 and 30.

That being said, there are still a few known major bugs with WebVTT in Firefox 31:

• TextTrackCue enter, exit, and change events do not work yet. I'm working on getting them done now.
• WebVTT subtitles do not show on audio only elements yet. This will probably be what is tackled after the TextTrackCue events (EDIT: To clarify, I meant audio only video elements).
• There is no support for any in-band TextTrack WebVTT data yet. If your a video or audio codec developer that wants in-band WebVTT to work in Firefox, please help out :-).
• Oh, and there is no UI on the HTML5 Video element to control subtitles... not the most convenient, but it's currently being worked on as well.

http://rickeyre.ca/2014/07/23/webvtt-released.html

Things have to be scheduled when there’s so much to ‘ship’ at an organization like Mozilla. So we’re still a couple of weeks away from a landing page for all of the badges at webmaker.org. This post has a link to all of the Web Literacy badges now available.

We’ve just finished testing the 15 Web Literacy ‘maker’ badges I mentioned in a previous post. Each badge corresponds to the ‘Make’ part of the resources page for the relevant Web Literacy Map competency. We’re not currently badging ‘Discover’ and ‘Teach’. If this sounds confusing, you see what I mean by viewing, as an example, the resources page for the Privacy competency.

Below is a list of the Web Literacy badges that can apply for right now. Note that you might want to follow this guidance if and when you do!

EXPLORING

• Navigation: Maker
• Web Mechanics: Maker
• Search: Maker
• Credibility: Maker
• Security: Maker

BUILDING

• Composing for the Web: Maker
• Remixing: Maker
• Design and Accessibility: Maker
• Coding / Scripting: Maker
• Infrastructure: Maker

CONNECTING

• Sharing: Maker
• Collaborating: Maker
• Community Participation: Maker
• Privacy: Maker
• Open Practices: Maker

Why not set yourself a challenge? Can you:

1. Collect one from each strand?
2. Collect all the badges within a given strand?
3. Collect ALL THE BADGES?

Comments? Questions? I’m @dajbelshaw or you can email me: doug@mozillafoundation.org

http://literaci.es/web-literacy-maker-badges-list

A friend of a friend asked this morning:

Hmmm trying to upload a CC0 public domain presentation from #OKFest14 by @punkish and @SlideShare don’t have public domain license option :(

— Jenny Molloy (@jenny_molloy) July 22, 2014

I suggested Wikimedia Commons, but it turns out she wanted something like Slideshare’s embedding. So here’s a test of how that works (timely, since soon Wikimanians will be uploading dozens of slide decks!)

This is what happens when you use the default Commons “Use this file on the web -> HTML/BBCode” option on a slide deck pdf:

Not the worst outcome – clicking gets you to a clickable deck. No controls inline in the embed, though. And importantly nothing to show that it is clickable :/

Compare with the same deck, uploaded to Slideshare:

Some work to be done if we want to encourage people to upload to Commons and share later.

Update: a commenter points me at viewer.js, which conveniently includes a wordpress plugin! The plugin is slightly busted (I had to move some files around to get it to work in my install) but here’s a demo:

http://lu.is/blog/2014/07/22/slide-embedding-from-commons/

https://blog.mozilla.org/privacy/2014/07/22/prefersafe-making-online-safety-simpler-in-firefox/

Los navegadores hoy en d'ia son parte esencial de nuestra vida, con ellos podemos navegar en Internet, jugar, hacer compras, o'ir m'usica, ver videos, etc. Un video puede estar grabado en un idioma que no entendemos y necesitamos subt'itulos para entender lo que se dice. Para la web, estos archivos est'an regidos por el formato para mostrar texto en pistas WebVTT a trav'es del elemento y ser utilizados en para a~nadir subt'itulos. De ahora en adelante los usuarios de Firefox podremos disfrutar de subt'itulos en los videos de la web  y los desarrolladores podr'an emplearlos.

Una nueva librer'ia para verificar la veracidad de los certificados e incrementar la seguridad de los usuarios finales est'a siendo usada por esta nueva versi'on de Firefox. mozilla::pkix — como es llamada,  es m'as robusta, f'acil de mantener y mejora el consumo de memoria. Su c'odigo puede ser visto por cualquier persona desde aqu'i.

Para realizar b'usquedas m'as f'acil se agreg'o el campo de b'usqueda en la p'agina Nueva pesta~na, desde all'i puedes elegir el motor de b'usqueda a utilizar en Firefox.

Los complementos son una de las caracter'isticas de Firefox que m'as te gustan, con ellos puedes agregar funcionalidades que no se encuentran por defecto en el navegador y personalizarlo a tu modo. Por esa raz'on, se ha implementado un depurador para complementos que permitir'a a los desarrolladores contar con una herramienta que les ayude a localizar errores y probar sus creaciones.

Las Firefox Hub APIs permiten a los desarrolladores de complementos que sus creaciones incorporen contenidos propios a la p'agina de inicio — donde los usuarios pueden encontrar marcadores, sitios m'as visitados, etc — e incrementar la interacci'on de los usuarios con estos. Para m'as detalles puedes visitar la documentaci'on en MDN y ver algunos complementos de ejemplos.

Tambi'en se suman las mejoras de estabilidad y rendimiento de la APK Factory, las cuales proveen una mejor “experiencia nativa” para aplicaciones Web en Android. Usando APK Factory los desarrolladores de aplicaciones para Firefox OS pueden portar a millones de usuarios de Android sus desarrollos sin tener que cambiar una l'inea de c'odigo. El APK Factory tambi'en asegura que las aplicaciones corran en un ambiente de ejecuci'on actualizado, por lo que no presentar'an problemas de degradaci'on o compatibilidad.

Para Android

• Se ha a~nadido la posibilidad de reordenar los paneles existentes en about:home.
• Soporte para m'as lenguajes: Asam'es [as], Bengali [bn-IN], Gujarati [gu-IN], Hindi [hi-IN], Kannada [kn], Maithili [mai], Malayalam [ml], Marathi [mr], Oriya [or], Panjabi [pa-IN], Tamil [ta], Telugu [te].
• Bot'on para actualizar manualmente en la p'agina de pesta~nas sincronizadas.

Otras novedades

• Preferencia navigator.sendBeacon habilitada por defecto.
• Los archivos .PDF y .OGG son manejados por Firefox sino se especifica una aplicaci'on para hacerlo.
• Mejoras en el editor de c'odigo (Herramientas para desarrollo).
• Implementaci'on parcial de las tablas matem'aticas OpenType (ver documentaci'on).
• Implementadas y habilitadas las variables CSS3.
• Nueva herramienta “Eyedropper“ para obtener el color f'acilmente (Herramientas para desarrollo).
• Modelo de caja editable al analizar los elementos HTML (Herramientas para desarrollo).
• Un depurador para Canvas (Herramientas para desarrollo).
• Muchos cambios m'as.

Si deseas conocer m'as, puedes leer las notas de lanzamiento.

Puedes obtener esta versi'on desde nuestra zona de Descargas en espa~nol e ingl'es para Linux, Mac, Windows y Android. Recuerda que para navegar a trav'es de servidores proxy debes modificar la preferencia network.negotiate-auth.allow-insecure-ntlm-v1 a true desde about:config.

http://firefoxmania.uci.cu/nueva-verificacion-de-certificados-depuradores-y-funcionalidades-para-firefox/

the following changes have been pushed to bugzilla.mozilla.org:

• [1039198] Field name is still “Bug #” for the Bug Created field
• [922482] Change all bugs with general@js.bugs assignee to nobody@mozilla.org
• [713307] Please add FlagTypeComments for tracking/approval flags
• [1037571] Change Several Bugs at Once Does Not Allow Modification of the QA Whiteboard
• [1032883] update FlagDefaultRequestee extension to use object hooks
• [1040580] Bugzilla detects Firefox OS device as Hardware:Other, OS:Other
• [1026416] “blocks” field is present as empty string when empty, rather than null or []
• [1040841] Provide good error message when people can’t use form.legal
• [1041538] A few more “Bugmail filtering” fields need to be excluded from the prefs UI
• [1041559] “Please wait while your bugs are retrieved” shown above menu header for search error pages
• [936468] Move OS: Windows 8 Metro to Windows 8.1

discuss these changes on mozilla.tools.bmo.

http://globau.wordpress.com/2014/07/22/happy-bmo-push-day-105/

I recently had a bad experience at a programming workshop where I was the only woman in attendance and eventually had to leave early out of concern for my safety.

Having to repeatedly explain the situation to a group of men who promised me that “they were working on fixing this community” was not only degrading, but also unnecessary. I was shuttled to three separate people, eventually receiving some of my money back approximately a month later (which was all I asked for) along with promises and placating statements about “improvement.”

What happened could have been prevented: each participant signed a “Code of Conduct” that was buried in the payment for the workshop, but there was no method of enforcement and nowhere to turn when issues arose.

At one point while I was attempting to resolve the issue, this community’s Project Manager told me, “Three other women signed up, but they dropped out at the last minute because they had to work. It was very strange and unexpected that you were the only woman.” I felt immediately silenced. The issue is not numbers, but instead inviting people to safe spaces and building supportive structures where people feel welcomed and not marginalized. Increasing the variety of people involved in an event is certainly a step, but it is only part of the picture. I realize now that the board members of this organization were largely embarrassed, but they could have handled my feelings in a way where I didn’t feel like their “future improvements” were silencing my very real current concerns.

Similarly, I’ve been thinking a lot about a conversation I had with some members of the German Python community a few months ago. Someone told me that Codes of Conduct are an American hegemonic device and that introducing the idea of abuse opens the community up for it, particularly in places that do not define “diversity” in the same way as Americans. This was my first exposure to this argument, and it definitely gave me a lot of food for thought, though I adamantly disagree.

In my opinion, the open-source tech community is a multicultural community and organizers and contributors have the responsibility to set their rules for participation. Mainstream Western society, which unfortunately dictates many of the social rules on the Internet, does a bad job teaching people how to interact with one another in a positive and genuine way, and going beyond “be excellent to one another, we’re all friends here!” argument helps us participate in a way in which people feel safe both on and off the Web.

At a session at the Open Knowledge Festival this week, we were discussing accessibility and realized that the Code of Conduct (called a “User Guide”) was not easily located and many participants were probably not aware of its existence. The User Guide is quite good: it points to other codes of conduct, provides clear enforcement, and emphasizes collaboration and diversity.

At the festival, accessibility was not addressed in any kind of cohesive manner: the one gender-neutral bathroom in the huge space was difficult to find, sessions were loud and noisy and often up stairs, making it impossible for anyone with any kind of hearing or mobility issue to participate, and finally, the conference organizers did not inform participants that food would not be free, causing the conference’s ticket price to increase dramatically in an expensive neighborhood in Berlin.

In many ways, I’m conflating two separate issues here (accessibility and behavior of participants at an event.) I would counter that creating a safe space is not only about behavior on the part of the participants, but also on the part of the conference organizers. Thinking about how participants interact at your event not only has to do with how people interact with one another, but also how people interact with the space. A commitment to accessibility and “diversity” hinges upon more than words and takes concerted and long term action. It may mean choosing a smaller venue or limiting the size of the conference, but it’s not impossible, and incredibly important. It also doesn’t have to be expensive!  A small hack that I appreciated at Ada Camp and Open Source Bridge was a quiet chill out room. Being able to escape from the hectic buzz was super appreciated.

Ashe Dryden writes compellingly about the need for better Codes of Conduct and the impetus to not only have events be a reflection of what a community looks like, but also where they want to see them go. As she writes,

I worry about the conferences that are adopting codes of conduct without understanding that their responsibility doesn’t end after copy/pasting it onto their site. Organizers and volunteers need to be trained about how to respond, need to educate themselves about the issues facing marginalized people attending their events, and need to more thoughtfully consider their actions when responding to reports.

Dryden’s  Code of Conduct 101 and FAQ should be required reading for all event organizers and Community Managers. Codes of Conduct remove the grey areas surrounding appropriate and inappropriate behavior and allow groups to set the boundaries for what they want to see happening in their communities. In my opinion, there should not only be a Code of Conduct, but also an accessibility statement that collaboratively outlines what the organizers are doing to make the space accessible and inclusive and addresses and invites concerns and edits.  In her talk at the OKFestival, Penny pointed out that accessibility and inclusion actually makes things better for everyone involved in an event. As she said, “No one wants to sit in a noisy room! For you, it may be annoying, but for me it’s impossible.”

Diversity is not only about getting more women in the room, it is about thinking intersectionally and educating oneself so that all people feel welcome regardless of class, race, physicality, or level of education. I’ve had the remarkable opportunity to go to conferences all over the world this year, and the spaces that have made an obvious effort to think beyond “We have 50% women speakers!” are almost immediately obvious. I felt safe and welcomed at Open Source Bridge and Ada Camp. From food I could actually eat to lanyards that indicated comfort with photography to accessibility lanes, the conference organizers were thoughtful, available, and also kind enough that I could approach them if I needed anything or wanted to talk.

From now on, unless I’m presented a Code of Conduct that is explicit in its enforcement, defines harassment in a comprehensive manner, makes accessibility a priority, and provides trained facilitators to respond to issues, you can count me out of your event.

We can do better in protecting our friends and communities, but change can only begin internally. I am a Community Manager because we get together to educate ourselves and each other as a collaborative community of people from around the world. We should feel safe in the communities of practice that we choose, whether that community is the international Python community, or a local soccer league, or a university. We have the power to change our surroundings and our by extension our future, but it will take a solid commitment from each of us.

Events will never be perfect, but I believe that at least in this respect, we can come damn close.

http://jennierosehalperin.me/codes-of-conduct/