For some time now the Mozilla Wiki has been significant amounts of spam. To give you an idea of the magnitude of the problem: hundreds of spam accounts are created every week and a handful of admins each spend upwards of 4 hours per week identifying and deleting spam content and accounts.
To combat this problem, we have have implemented a change to the way user accounts are created.
Prior to this change, anyone could create an account and immediately start editing pages. After a short interval, a new user was then able to create pages as well.
Now, all new users are required to request an account and have that request approved prior to logging in and editing or creating pages.
We expect the impact of this change to valid users to be minimal. During a typical week, only a handful of legitimate user accounts are created. The rest are spam.
Below you’ll find a list of questions and answers to help aid in this transition. If you have any questions that we have not answered, please let us know.
Thank you to everyone who helped implement this change, including: Jake Maul, Jason Crowe, AlisonW, KaiRo, and Gordon Hemsley, as well as all those who agreed to help approve accounts.
What is the work-flow for new users?
The new work-flow for new users is as follows:
A user visits the Mozilla Wiki and clicks Log in / create account
Users that don’t already have an account will click request one
On the request account page, the user will enter their preferred username, email address, name, bio, and additional information about themselves (optional).
After the user submits their request, they will receive an email asking them to confirm their email via a link. The user clicks on that link and their email is then confirmed.
Once the user’s request is approved, they will receive an email notification that includes a temporary password. They will be required to change their password the first time they log in to the wiki
Is the work-flow different for users who have accounts already?
No, those users will login as they always have.
What is the new work-flow for bureaucrats?
Once the user has confirmed their email, a notice of the request is sent to designated wiki users (a notice is also included on the RecentChanges and Watchlist pages for users who have the ability to approve).
The bureaucrat reviews the user’s account request and takes one of the following actions: approves, holds, or denies. Bureaucrats are instructed to approve all users they can reasonable verify are people with legitimate reason to edit the wiki (that is, not spammers or bots).
What should I do if my request has not been approved withing 24-48 hours?
Please email email@example.com or find us on IRC in #wiki.
What should I do if I am involved in a Mozilla-related event which is likely to generate many timely user account requests?
Please email firstname.lastname@example.org or find us on IRC in #wiki to let us know. We’ll do our best to have someone on hand during your event to approve requests.
Alternatively, we can create accounts for users ahead of time.
Why am I still encountering spam on the wiki?
The volume of spam received by the Mozilla Wiki has been such that we’ve not always be able to keep up with it. The change we have made to new user account creation affects the creation of new spam, but does not address preexisting spam content. We will continue to work on identifying and removing content. If you see a page that is clearly spam, let us know via IRC in #wiki.
How can I get involved with improving the Wiki?
The best way to get involved with improving the wiki is to join the Wiki Working Group (and we’d love to have you!).
Recently I’ve been thinking a lot about how to make more time for meaningful project work as well as for rest. One way to free up time has been to significantly reduce the number of meetings I attend and facilitate, and to make those meetings as efficient as possible when I do attend.
Idea 1: Only schedule meetings when there are no other effective options.
Meetings take up a lot of time. An hour long meeting doesn’t just take an hour, it takes an hour per person who attends the meeting. There’s also an opportunity cost associated with meetings. When you’re in meetings, you aren’t getting any other work done. The opportunity cost is multiplied if you have work that that requires long blocks of uninterrupted time. On days where I an hour of free time interspersed between meetings are days where I completed nothing but superficial tasks.
In general, always aim for fewer meetings. Before scheduling a meeting, ask yourself what the goal of the meeting is, and can that goal be accomplished in another, preferably asynchronous way.
There’s a caveat to this idea, however. If while discussing a topic in an asynchronous channel and you realize going round and round without progress or are otherwise not making progress, it’s time to move to a synchronous channel. This might be a video or telephone call or an IRC chat.
Idea 2: Schedule the shortest meeting possible.
Think about your goal, the number of people attending and then pick a meeting length accordingly. Many people default to hour long meetings for no other reason than it’s the default of many calendaring tools, and we’re used to thinking in full-hour increments. Take a look at your agenda. Do you need a full hour to get through it? Would 30 or 45 minutes work instead? Treat people’s time as the valuable and finite thing that it is and only ask for what you absolutely need.
Idea 3: Use a calendar tool to create and send a meeting invite.
Zimbra, Thunderbird via Lightning, iCal, Google Calendar, Outlook. Most email clients have this built in, so you shouldn’t have to think too hard and nor should your recipients. If you’re self-hosting email or on an otherwise non-mainstream hosted email, you probably have enough technical savvy to figure out how to send a calendar invite. Why? For those of us who live and die by our calendars, if something is not on there, it isn’t happening. Or it is, but I don’t need to know about it. Sending a calendar invite bypasses my often overwhelmed email queue and gives me the opportunity to respond in a routinized way without having to get to inbox zero.
Idea 4: Only invite those who really need to attend.
Call out attendees who are truly optional (many calendar tools have this feature, if not, use the invite body). Your agenda should give an good indication to invited attendees why they need to attend. Keep an eye out for acceptances and declines and follow-up accordingly. Don’t wait until the meeting has started to try and track down a necessary participant who didn’t respond to your meeting invite.
Idea 5: Manage large, group meetings using shared calendars instead of individual invites.
In the case of large, group meetings, I recommend using shared calendars instead of sending invitations to individuals or even groups of individuals. These work best for meetings where attendance is medium to very large, attendance is optional and variable, and the content of the meetings are largely updates with room for discussion. Using shared calendars allows people to subscribe to the calendars of events or groups for which they are interested in participating and gives them control over how to manage that information in their own calendars. With a shared calendar, a person can toggle visibility and choose whether or not those appointments will affect their free/busy status without having to respond to individual invites.
Idea 6: Share your own calendar whenever possible
Sharing your own calendar allows others to initiate meetings with you without having to go back and forth via email asking ‘what time is good.’ Doodle and other websites accomplish similar things, but take time to setup. If you share your calendar publicly and let people know about it, they can compare it with their own schedules and send an invite for a time that seems to work for both of you. If the time doesn’t actually work for you, you can decline or respond suggesting a new time. You won’t necessarily eliminate the back-and-forth with this method, but at least you’re a step closer. When someone sends you an invite, your time is blocked as tentative and there’s less of a chance you’ll be booked for something just after you’ve told someone via email you were free at that time.
What about privacy? Most calendars allow you to set not only the visibility of individual appointments (private vs public), but also to what extent you share the details of your calendar. Here’s what my public calendar , which is a combination of my personal and work calendars, looks like:
I’ve chosen to share only the free/busy status of my calendar, so all you see are blocks of time say ‘busy’ and ‘tentative’ depending on how I’ve responded to appointments. For me, this is a good mix of privacy vs the convenience of easier scheduling with other people.
Idea 7: Respond to meeting invites timely and accordingly
Whenever possible, respond to meeting invites timely and accordingly. This means accepting, declining or tentatively accepting invites that you receive. What constitutes ‘timely’ here is contextual. When I receive the initial invitation for a regular recurring meeting, I either accept all as tentative (thus blocking my schedule) or do nothing. Then at the beginning of each week, I look 2-3 weeks ahead and make sure I’ve either accepted or declined according to my availability. For meetings happening on the same day as I receive the invite, I try to accept or decline as soon as I see the invitation. For meetings happening within the week, I try to respond the same day I receive the invite. If I don’t know whether or not I can attend, I respond with a tentative acceptance and often provide the reason or a clarifying question: “I most likely have a conflict at this time, but could potentially move it. How important am I to this discussion?”
What are you strategies?
What strategies do you have to make scheduling easier, better, more productive? Leave them in the comments. Or tweet at me.
The community building curriculum subgroup had its first meeting (notes)! During the meeting we brainstormed what kind of community building curriculum could be possible to roll-out this year. We agreed that finding existing curriculum and adapting for Mozilla would be the best way to utilize our limited resources. Between this meeting and next, we’re going to make a list of possible resources to adapt
A community building skills question is prepared in Mozilla Moderator and after seeing with responses from the MozCamp design session in April, I’ll announce project-wide and ask for Mozillians to submit their ideas.
As always, you are welcome to join me in any of these projects. Look at my mozillians profile for the best way to get in touch with me.
One issue to emerge for last December’s Community Building meet-up was how important the Mozilla Wiki is to the project and also how neglected a resource it is. The Wiki Working Group was formed to address this issue. Since then, the Mozilla Wiki has become an official sub-module of Websites, we’ve fixed a handful of long-standing bugs, and we’re working on short- and long-term roadmaps for the wiki.
During our discussions about the wiki, we discovered the need for a clear statement about the purpose of the wiki, its role and importance to the project, what content belongs on the wiki (vs MDN, vs SUMO, etc.), and its governance structure. As such, we have drafted an About page that attempts to do those things.
We’d like for as many Mozillians as possible to read our draft and comment on it. When reviewing, we ask you to consider the following questions:
what about the content does or does not make sense to you?
what about the content does or does not resonate with you?
to what extent does the content match your vision for wiki.mozilla.org?
to what extent can you support the purpose, scope and governance structured described?
The comment period is open until 26 May 2014 at 14:00 UTC. Those comments will be considered and incorporated and this page adopted into the wiki by 15 June 2014.
Thank you to everyone from the Wiki Working Group who contributed to this document, especially: Lyre Calliope, Gordon Hemsley, Justin Crawford, Larissa Shapiro, Jennie Rose Halperin, Mark A. Hershberger, and Jason Crowe.
This is meant to be a quick reference, one that project leaders can read and understand quickly, and reference as they set up their projects.
Please take a look at the draft on WikiMo and let me know what you think. For best collaboration, leave your comments directly on that wiki page. Otherwise leave a comment here on the blog, or visit my Mozillians profile for the best way to get in touch.
This doesn’t fit specifically in either category below, but I still wanted to call attention to it: Last Tuesday we launched Firefox 29 “Australis,” our biggest redesign of Firefox since version 4!
Education & Culture Working Group
Further planning with Dino Anderson about diversity & inclusion efforts we’d like to roll out this year. I don’t have notes I can share, but will work on putting together some kind of update soon.
Drafted an open planning checklist (comments welcome!). This is geared towards all Mozilla teams (of paid and volunteer contributors) to help them adopt and maintain an open planning process.
Represented the E&C Working Group at the Grow Mozilla meeting.
Facilitated our regular Education & Culture working group meeting (notes).
Wiki Working Group
Triaged all open Websites::wiki.mozilla.org bugs. Closed 43 bugs (search).
Setup the wiki as a project in scrumbugs. Still updating bugs with user stories, so you won’t see a lot there, except in the backlog.
Worked, with Lyre and Larissa, on final drafts of wiki.mozilla.org and WWG purpose and scope documents. We’ll review as a group tomorrow and then I’ll post publicly.
I wrote a tiny, simple WordPress plugin called bz shortcode to help make generating individual bugzilla.mozilla.org links on this blog easier.
I’m trying to attend fewer meetings so that I have more time to work. My strategy so far is: If I receive a meeting invite without an agenda item making it clear why I’m a necessary participant, I’ve started declining with a note to the organizer asking if I really need to be there. The flip side of this is that I’m doing my best to have clear agendas a head of time for the meetings that I facilitate.
Priorities for this week
Finalize scope documents for both the wiki itself and the wiki working group.
On Tuesday of last week we help our twice-monthly Wiki Working Group meeting (notes). Key takeaways:
We celebrated becoming an official sub-module of websites.
We talked about planning an in-person meet-up and sprint at this year’s Wikimania in London.
We talked about the need to clarify our vision for the wiki as a prerequisite for creating the long-term roadmap, as well as the need start on a short-term roadmap to address critical needs.
During our next meeting we’ll continue work on both the short- and long-term roadmaps. If you’re interested in contributing, please get involved!
Later in the week, a few of us fixed the following bugs:
Bug 858844 – Sortable tables on wiki no longer sortable
Bug 1001710 – Recent changes to wiki.mozilla.org break bugzilla plugin
Bug 819708 – wiki.mozilla.org editor wont show rich text editor
MozCamp Planing Session
Last week a handful of contributors gathered at the San Francisco office to plan MozCamps 2014, the next phase of what we’re still calling “MozCamps” but which we plan to evolve into a new kind of event.
I’m still synthesizing everything we covered during the planning session, but the most relevant takeaway in terms of the education working group was this list of community building skills that the group generating during a brainstorming session about what content should be included in the new MozCamps. This week I’m working to integrate that list into the existing community building curriculum roadmap.
I’ve put this explanation together for those who want to understand the Heartbleed bug, how it fits into the bigger picture of secure internet browsing, and what you can do to mitigate its affects.
HTTPS vs HTTP (padlock vs no padlock)
When you are browsing a site securely, you use https and you see a padlock icon in the url bar. When you are browsing insecurely you use http and you do not see a padlock icon.
HTTPS relies on something called SSL/TLS.
SSL stands for Secure Sockets Layer and TLS stands for Transport Layer Security. TLS is the later version of the original, proprietary, SSL protocol developed by Netscape. Today, when people say SSL, they generally mean TLS, the current, standard version of the protocol.
Public and private keys
The TLS protocol relies heavily on public-key or asymmetric cryptography. In this kind of cryptography, two separate but paired keys are required: a public key and a private key. The public key is, as its name suggests, shared with the world and is used to encrypt plain-text data or to verify a digital signature. (A digital signature is a way to authenticate identity.) A matching private key, on the other hand, is used to decrypt data and to generate digital signatures. A private key should be safeguarded and never shared. Many private keys are protected by pass-phrases, but merely having access to the private key means you can likely use it.
Authentication and encryption
The purpose of SSL/TLS is to authenticate and encrypt web traffic.
Authenticate in this case means “verify that I am who I say I am.” This is very important because when you visit your bank’s website in your browser, you want to feel confident that you are visiting the web servers of — and thereby giving your information to — your actual bank and not another server claiming to be your bank. This authentication is achieved using something called certificates that are issued by Certificate Authorities (CA). Wikipedia explains thusly:
The digital certificate certifies the ownership of a public key by the named subject of the certificate. This allows others (relying parties) to rely upon signatures or assertions made by the private key that corresponds to the public key that is certified. In this model of trust relationships, a CA is a trusted third party that is trusted by both the subject (owner) of the certificate and the party relying upon the certificate.
In order to obtain a valid certificate from a CA, website owners must submit, at minimum, their server’s public key and demonstrate that they have access to the website (domain).
Encrypt in this case means “encode data such that only authorized parties may decode it.” Encrypting internet traffic is important for sensitive or otherwise private data because it is trivially easy eavesdrop on internet traffic. Information transmitted not using SSL is usually done so in plain-text and as such clearly readable by anyone. This might be acceptable for general internet broswing. After all, who cares who knows which NY Times article you are reading? But is not acceptable for a range of private data including user names, passwords and private messages.
Behind the scenes of an SSL/TLS connection
When you visit a website with HTTPs enabled, a multi-step process occurs so that a secure connection can be established. During this process, the sever and client (browser) send messages back and forth in order to a) authenticate the server’s (and sometimes the client’s) identity and, b) to negotiate what encryption scheme, including which cipher and which key, they will use for the session. Identities are authenticated using the digital certificates mentioned previously.
When all of that is complete, the secure connection is established and the server and client send traffic back and forth to each other.
All of this happens without you ever knowing about it. Once you see your bank’s login screen the process is complete, assuming you see the padlock icon in your browser’s url bar.
Keepalives and Heartbeats
Even though establishing an ssl connection happens almost imperceptibly to you, it does have an overhead in terms of computer and network resources. To minimize this overhead, network connections are often kept open and active until a given timeout threshold is exceed. When that happens, the connection is closed. If the client and server wish to communicate again, they need to re-negotiate the connection and re-incur the overhead of that negotiation.
One way to forestall a connection being closed is via keepalives. A keepalive message is used to tell a server “Hey, I know I haven’t used this connection in a little while, but I’m still here and I’m planning to use it again really soon.”
Keepalive functionality was added to the TLS protocol specification via the Heartbeat Extension. Instead of “Keepalives,” they’re called “Heartbeats,” but they do basically the same thing.
Specification vs Implementation
Let’s pause for a moment to talk about specifications vs implementations. A protocol is a defined way of doing something. In this case of TLS, that something is encrypted network communications. When a protocol is standardized, it means that a lot of people have agreed upon the exact way that protocol should work and this way is outlined in a specification.The specification for TLS is collaboratively developed, maintained and promoted by the standards body Internet Engineering Task Force (IETF). A specification in and of itself does not do anything. It is a set of documents, not a program. In order for a specifications to do something, they must be implemented by programmers.
OpenSSL implementation of TLS
OpenSSL is one implementation of the TLS protocol. There are others, including the open source GnuTLS as well as proprietary implementations. OpenSSL is a library, meaning that it is not a standalone software package, but one that is used by other software packages. These include the very popular webserver Apache.
The Heartbleed bug only applies to webservers with SSL/TLS enabled, and only those using specific versions of the open source OpenSSL library because the bug relates to an error in the code of that library, specifically the heartbeat extension code. It is not related to any errors in the TLS specification or and in any of the underlying ciper suites.
Usually this would be good news. However, because OpenSSL is so widely used, particularly the affected version, this simple bug has tremendously reach in terms of the number of servers and therefor the number of users it potentially affects.
What the heartbeat extension is supposed to do
The heartbeat extension is supposed to work as follows:
A client sends a heartbeat message to the server.
The message contains two pieces of data: a payload and the size of that payload. The payload can by anything up to 64kb.
When the server receives the heartbeat message, it is to add a bit of extra data to it (padding) and send it right back to the client.
Pretty simple, right? Heartbeat isn’t supposed to do anything other than let the server and client know they are each still there and accepting connections.
What the heartbeat code actually does
In the code for affected versions (1.0.1-1.0.1f) of the OpenSSL heartbeat extension, the programmer(s) made a simple but horrible mistake: They failed to verify the size of the received payload. Instead, they accepted what the client said was the size of the payload and returned this amount of data from memory, thinking it should be returning the same data it had received. Therefore, a client could send a payload of 1KB, say it was 64KB and receive that amount of data back, all from server memory.
If that’s confusing, try this analogy: Imagine you are my bank. I show up and make a deposit. I say the deposit is $64, but you don’t actually verify this amount. Moments later I request a withdrawal of the $64 I say I deposited. In fact, I really only deposited $1, but since you never checked, you have no choice but to give me $64, $63 of which doesn’t actually belong to me.
And, this is exactly how a someone could exploit this vulnerability. What comes back from memory doesn’t belong to the client that sent the heartbeat message, but it’s given a copy of it anyway. The data returned is random, but would be data that the OpenSSL library had been storing in memory. This should be pre-encryption (plain-text) data, including your user names and passwords. It could also technically be your server’s private key (because that is used in the securing process) and/or your server’s certificate (which is also not something you should share).
The ability to retrieve a server’s private key is very bad because that private key could be used to decrypt all past, present and future traffic to the sever. The ability to retreive a server’s certificate is also bad because it gives the ability to impersonate that server.
This, coupled with the widespread use of OpenSSL, is why this bug is so terribly bad. Oh, and it gets worse…
Taking advantage of this vulnerability leaves no trace
What’s worse is that logging isn’t part of the Heartbeat extension. Why would it be? Keepalives happen all the time and generally do not represent transmission of any significant data. There’s no reason to take up value time accessing the physical disk or taking up storage space to record that kind of information.
Because there is no logging, there is no trace left when someone takes advantage of this vulnerability.
The code that introduced this bug has been part of OpenSSl for 2+ years. This means that any data you’ve communicated to servers with this bug since then has the potential to be compromised, but there’s no way to determine definitively if it was.
This is why most of the internet is collectively freaking out.
What do server administrators need to do?
Server (website) administrators need to, if they haven’t already:
Determine whether or not their systems are affected by the bug. (test)
Patch and/or upgrade affected systems. (This will require a restart)
Revoke and reissue keys and certificates for affected systems.
Furthermore, I strongly recommend you enable Perfect forward secrecy to safeguard data in the event that a private key is compromised:
When an encrypted connection uses perfect forward secrecy, that means that the session keys the server generates are truly ephemeral, and even somebody with access to the secret key can’t later derive the relevant session key that would allow her to decrypt any particular HTTPS session. So intercepted encrypted data is protected from prying eyes long into the future, even if the website’s secret key is later compromised.
What do users (like me) need to do?
The most important thing regular users need to do is change your passwords on critical sites that were vulnerable (but only after they’ve been patched). Do you need to change all of your passwords everywhere? Probably not. Read You don’t need to change all your passwords for some good tips.
Additionally, if you’re not already using a password manager, I highly recommend LastPass, which is cross-platform and works on pretty much every device. Yesterday LastPass announced they are helping users to know which passwords they need to update and when it is safe to do so.
As a single employee of Mozilla, I am not sure I can definitively determine Brendan’s suitability. I can, however, give insight as to what I experience at Mozilla as a queer woman and how I feel about the appointment.
Mozilla is a very unique organization in that it operates in a strange hybrid space between tech company and non-profit. There simply aren’t a lot of models for what we do. Wikimedia Foundation is always the one that comes closest to mind for me, but remains a very different thing. As such, people with experience relevant Mozilla, relevant enough to lead Mozilla well, are in very short supply. An organization can always choose to make an external hire and hope the person comes to understand the culture, but that is a risky bet. Internal candidates who have demonstrated they get the culture, the big picture of where we need to go and have demonstrated they can effectively lead large business units, on the other hand, present as very strong options.
And, from my limited vantage point, that’s what I see in Brendan.
Like a lot of people, I was disappointed when I found out that Brendan had donated to the anti-marriage equality Prop. 8 campaign in California. It’s hard for me to think of a scenario where someone could donate to that campaign without feeling that queer folks are less deserving of basic rights. It frustrates me when people use their economic power to further enshrine and institutionalize discrimination. (If you haven’t seen it, here’s Brendan’s response to the issue.)
However, during the intervening years, I’ve spent a lot of time navigating communities like Mozilla and figuring out how to get things done. I’ve learned that it’s hard working with people but that you have to do it anyway. I’ve learned that it can be even harder to work with someone when you think you don’t share your fundamental beliefs, or when you think they hold opposing or contradictory beliefs, but you have to do that sometimes, too.
The key is to figure out when it’s important to walk away from interacting with a person or community because of a mis-alignment in beliefs and when you need to set aside the disagreement and commit to working together in service of the shared goal. Context is really important here. What is the purpose or mission of the community? Who is its audience? What are its guiding principles?
Mozilla’s mission is “to promote openness, innovation & opportunity on the Web.” Our audience is the global community of people connecting to the internet. Our guiding principles are numerous, but include protecting the internet as a public resource and upholding user privacy, security and choice.
At the same time, many Mozillians are themselves advocates for human rights, animal rights, prison abolition, marriage equality, racial equality, etc. As much as some of those causes might overlap with the cause of a free and open internet, they are separate causes and none of them are the focus of Mozilla the organization. Focus is important because we live in a world of limited resources. Mozilla needs to stay focused on the mission we have all come together to support and move forward.
Another factor to consider: What is their behavior within the community, where we have agreed to come together and work towards a specific mission? How much does a person’s behavior outside the scope of community affect the community itself? Does the external behavior conflict directly with the core mission of the organization?
To be clear, I’m personally disappointed about Brendan’s donation. However, aside from how it affected me emotionally, I have nothing to indicate that it’s materially hurt my work within the Mozilla community or as a Mozilla employee. Mozilla offers the best benefits I have ever had and goes out of its way to offer benefits to its employees in same-sex marriages or domestic partnerships on par with those in heterosexual marriages. Last year we finally got trans-inclusive healthcare. We didn’t have an explicit code of conduct when I started, but adopted the guidelines for participation within my first year. Progress might be slow, but it’s being made. And I don’t see Brendan standing in the way of that.
Certainly it would be problematic if Brendan’s behavior within Mozilla was explicitly discriminatory, or implicitly so in the form of repeated microagressions. I haven’t personally seen this (although to be clear, I was not part of Brendan’s reporting structure until today). To the contrary, over the years I have watched Brendan be an ally in many areas and bring clarity and leadership when needed. Furthermore, I trust the oversight Mozilla has in place in the form of our chairperson, Mitchell Baker, and our board of directors.
It’s true there might be a kind of collateral damage from Brendan’s actions in the form of some people withdrawing from participation in Mozilla or never joining in the first place. There’s a lot I could say about people’s responses to things that happen at Mozilla, but I’ll save those for another time.
For now, I’ll just say that if you’re queer and don’t feel comfortable at Mozilla, that saddens me and I’m sorry. I understand where you’re coming from, at least in part, because I had a rocky start at Mozilla and often questioned my fit in the community. That’s why I’m putting considerable effort into changing how we interact with and support contributors from marginal groups. If you want to join me, look at what we’re doing with the Education Working Group and then get in touch.
To conclude, what I offer to my fellow Mozillians, including Brendan, is this:
I respect that you have a private life, including interactions in other communities, that may not match my beliefs or may even conflict with them.
I recognize that despite possible differences in our personal beliefs, you are just as committed as I am to Mozilla’s mission and have a lot to offer the community.
I agree, and ask you to do the same, to set aside those differences to create a shared space in which we can work together on the Mozilla mission.
In that space, we’ll treat each other as human beings, following the participation guidelines, even if doing so will stretch our skills and make us slightly uncomfortable.
We agree to communicate with honesty and empathy and to find ways to support each other’s work in the project.
Update 28 March 2014 8:30 PDT:
Since Monday, Brendan and Mitchell have both published responses, which I’ve included below. I’ve also included posts from some colleagues.
The purpose of the CBT is to empower contributors to join us in furthering Mozilla’s mission. We strive to create meaningful and clear contribution pathways, to collect and make available useful data about the contribution life-cycle, to provide relevant and necessary educational resources and to help build meaningful recognition systems.
As Education Lead, I’ll drive efforts to: 1) identify the education and culture-related needs common across Mozilla, and b) to develop and implement strategies for creating and maintaining these needs. Another part of my role as Education Lead will be to organize the Education and Culture Working Group as well as the Wiki Working Group.