This summer we hope to unleash a new wave of webmakers on the Elm City. For the first time our 11th grade Gear Up students will take college level credit bearing classes. We will start with EDU 106: New Literacies for Life Long Learning.
The hybrid class will focus on telling the story of us. I have a syllabus, but I am not a fan. I want our learning to unfold in real-time…to be user driven. In July we will have three days a week together for three and a half hours a day. The other two days students will attend college visits and arts based field trips. They will have to choose some digital documentation tools.
I want to create and curate curriculum with the class. Last fall in our Gear Up Academy we focused on Beyonce and Formation. Students learned about the local history of the Black Panther Party in New Haven and wrote letters to the Miami Fraternal Order of Police who called for a boycott of Beyonce.
The readings will be based on what I have chosen but I hope to add , or better yet have the class upvote, a reading each module. I am toying with just picking something from Medium each week.
I want to tell the story of us. More importantly I want our GearUp stories to share their story. Last year we worked on college essays for the common app. Each story was unique. A tail of trials and triumphs. Many shared stories of being first generation college students, or of trying to make it through high school while being the primary breadwinner and caregiver to their siblings. There were stories of surviving abuse and the horrors of growing up in the system.
Yet everyone endured. They have made it this far. They have taught me so much.
We will be using our new collaborative learning space at Southern. Our Dean Stephen Hegedus, came to campus and immediatley ripped out the computer lab. He replaced it with individual networked stations and a state of the art 360 camera system.
I also purchased a Tricaster mini and a few black magic cameras. Be awesome to get some podcasting going.
Every student will maintain a domain of their own. We have used Known as our basic platform. I think I will stick with the tool.
Elm City Webmakers
Leveling up the digital skills of the youth in New Haven is a passion of mine. If diversity in tech is an HR problem it is already too late. We have been learning basic html/css skills for the past three years as a Mozilla Club.
I recognize not everyone is a maker, especially a webmaker (Students can also choose a music production class to fill the technology fluency component). So the tech doesn’t really matter. I want the web to be the paintbrush students can use to paint their world.
If anyone in tech in the Greater New Haven area would like to get involved please reach out. Urban education is not a school thing. It is not a parent thing. It belongs to the community. We must work to make the city our campus.
As part of the work I’m doing with London CLC, their Director, Sarah Horrocks, asked me to write something on what it means to be a digitally literate school leader. I’d like to thank her for agreeing to me writing this for public consumption.
Before I start, I think it’s important to say why I might be in a good position to be able to answer this question. First off, I’m a former teacher and senior leader. I used to be Director of E-Learning of a large (3,000 student), all-age, multi-site Academy. I worked for Jisc on their digital literacies programme, writing my thesis on the same topic. I’ve written a book entitled The Essential Elements of Digital Literacies. I also worked for the Mozilla Foundation on their Web Literacy Map, taking it from preliminary work through to version 1.5. I now consult with clients around identifying, developing, and credentialing digital skills.
That being said, it’s now been a little over six years since I last worked in a school, and literacy practices change quickly. So I’d appreciate comments and pushback on what follows.
Let me begin by saying that, as Allan Martin (2006) pointed out, “Digital literacy is a condition, not a threshold.” That’s why, as I pointed out in my 2012 TEDx talk, we shouldn’t talk about ‘digital literacy’ as a binary. People are not either digitally literate or digitally illiterate - instead literacy practices in a given domain exist on a spectrum.
In the context of a school and other educational institutions, we should be aware that that there are several cultures at play. As a result, there are multiple, overlapping literacy practices. For this reason we should talk of digital literacies in their plurality. As I found in the years spent researching my thesis, there is no one, single, definition of digital literacy that is adequate in capturing the complexity of human experience when using digital devices.
In addition, I think that it’s important to note that digital literacies are highly context dependent. This is perhaps most evident when addressing the dangerous myth of the 'digital native’. We see young people confidently using smartphones, tablets, and other devices and therefore we assume that their skillsets in one domain are matched by the requisite mindsets from another.
So to recap so far, I think it’s important to note that digital literacies are plural and context-dependent. Although it’s tempting to attempt to do so, it’s impossible to impose a one-size-fits-all digital literacy programme on students, teachers, or leaders and meet with success. Instead, and this is the third 'pillar’ one which my approach rests, I’d suggest that definitions of digital literacies need to be co-created.
By 'co-created’ I mean that there are so many ways in which one can understand both the 'digital’ and 'literacies’ aspects of the term 'digital literacies’ that it can be unproductively ambiguous. Instead, a dialogic approach to teasing out what this means in your particular context is much more useful. In my thesis and book I came up with eight elements of digital literacies from the research literature which prove useful to scaffold these conversations:
In order not to make this post any longer than it needs to be, I’ll encourage you to look at my book and thesis for more details on this. Suffice to say, it’s important both to collaboratively define the above eight terms and define then what you mean by 'digital literacies’ in a particular context.
All of this means that the job of the school leader is not to reach a predetermined threshold laid down by a governing body or professional body. Instead, the role of the school leader is to be always learning, questioning their practice, and encouraging colleagues and students in all eight of the 'essential elements’ listed above.
As with any area of interest and focus, school leaders should model the kinds of knowledge, skills, and behaviours they want to see develop in those around them. Just as we help people learn that being punctual is important by always turning up on time ourselves, so the importance of developing digital literacies can be demonstrated by sharing learning experiences and revelations.
There is much more on this in my thesis, book, and presentations but I’ll finish with some recommendations as to what school leaders can do to ensure they are constantly improving their practices around digital literacies:
Seek out new people: it’s easy for us to become trapped in what are known as filter bubbles, either through the choices we make as a result of confirmation bias, or algorithmically-curated newsfeeds. Why not find people and organisations who you wouldn’t usually follow, and add them to your daily reading habits?
Share what you learn: why not create a regular way to update those in your school community about issues relating to the considered use of technology? This could be a discussion forum, a newsletter pointing to the work of people like the Electronic Frontier Foundation or Common Sense Media, or 'clubs’ that help staff and students get to grips with new technologies.
Find other ways: the danger of 'best practices’ or established workflows is that they can make you blind to new, better ways of doing things. As Clay Shirky notes in this interview it can be liberating to jettison existing working practices in favour of new ones. What other ways can you find to write documents, collaborate with others, be creative, and/or keep people informed?
Our network is full of stories, impact and qualitative data. Colleagues and community members discover and use these narratives daily across a broad range — from communications and social media, to metrics and evaluation, to grant-writing, curriculum case studies, and grist for new outlets like the State of the Web.
Our challenge is: how do we capture and analyze these stories and qualitative data in a more systematic and rigorous way?
Can we design a unified “Story Engine” that serves multiple customers and use cases simultaneously — in ways that knit together much of our existing work? That’s the challenge we undertook in our first “Story Engine 0.1” sprint: document the goals, interview colleagues, a develop personae. Then design a process, ship a baby prototype, and test it out using some real data.
Designing a network story Engine
Here’s what we shipped in our first 3-day sprint:
A prototype web site. With a “file a story tip” intake process.
A draft business plan / workflow
A successful test around turning network survey data into story leads
Some early pattern-matching / ways to code and tag evidence narratives
Documented our key learnings and next steps
1) A prototype web site
http://mzl.la/story is now a thing! It packages what we’ve done so far. Plus a work-bench for ongoing work. It includes:
“File a story” tip sheet — A quick, easy intake form for filing potential story leads to follow up on. Goal: make it fast and easy for anyone to file the “minimum viable info” we’d need to then triage and follow up. http://mzl.la/tip
See stories — See story tips submitted via the tip sheet. (Requires password for now, as it contains member emails.) Just a spreadsheet at this point — it will eventually become a Git Hub repo for easier tasking, routing and follow-up. And maybe: a “story garden” with a prettier, more usable interface for humans to browse through and see the people and stories inside our network. http://mzl.la/leads
Personas — Who does this work need to serve? Who are the humans at the center of the design? We interviewed colleagues and documented their context, jobs, pains, and gains. Plus the claims they’d want to make and how they might use our findings. Focused on generating quick wins for the Mozilla Foundation grants, State of the Web, communications and metrics teams. http://mzl.la/customers
How-To Guides — (Coming soon.) Will eventually become: interview templates, guidance and training on how to conduct effective interviews, our methodology, and coding structure.
2) A draft business process / workflow
What happens when a story tip gets filed? Who does what? Where are the decision points? We mapped some of this initial process, including things like: assess the lead, notify the right staff, conduct follow-up interviews, generate writing/ artefacts, share via social, code and analyze the story, then package and use findings.
3) Turning network survey data into stories
Our colleagues in the “Insights and Impact” team recently conducted their first survey of the network. These survey responses are rich in potential stories, evidence narratives, and qualitative data that can help test and refine our value proposition.
We tested the first piece of our baby story engine by pulling from the network survey and mapping data we just gathered.
This proved to be rich. It proved that our network surveys are not only great ways to gather quantitative data and map network relationships — they also provide rich leads for our grants / comms / M&E / strategy teams to follow up on.
Sample story leads
(Anonymous for privacy reasons):
“The network helps us form connections to small organizations that offer digital media and learning programs. We learn from their practices and are able to share them out to our broader network of over 1600 Afterschool providers in NYC. It also expands our staff capacity to teach Digital Media and Learning activities.”
“My passion is youth advocacy and fighting in solidarity with them in their corner. Being part of the network helps me do more with them like working with libraries in the UK to develop ‘Open source library days; lead by our youths who have so much to share with us all.”
“The collaboration has allowed the local community to learn about the Internet and be able to contribute to it. The greatest joy is seeing young community girls being a part of this revolution through clubs. Through the process of learning they also meet local girls who share the same passion as they do.”
These are examples of leads that may be worth following up on to help flesh out theory of change, analyze trends, and tell a story about impact. Some of the leads we gathered also include critique or ways we need to do better — combined with explicit offers to help.
4) Early Pattern-matching / coding AND tagging
One of our goals is to combine the power of both qualitative and quantitative data. Out of this can come tagging and codes around the benefit / value the network is providing to members. Some early patterns in the benefits network members are reporting:
Support — advice, links to resources, financial support, partners (“matchmaking”)
Connections — professional, social
Credibility / legitimacy of being associated with Mozilla
Belongingness — being part of a group and drawing strength from that
Skills / practises / knowhow
Employability / “Helped me get a job”
Educational opportunity / “Helped me get into school”
Entrepreneurship & innovation / developing new models, products, services
Imagine these as simple tags we could apply to story tickets in a repo. This will help colleagues sift, sort and follow up on specific evidence narratives that matter to them. Plus allow us to spot patterns, develop claims, and test assumptions over time.
5) Key Learnings
Some of our “a ha!” moments from this first sprint:
Increased empathy and understanding is key. Increasing our empathy and understanding of network members is a key goal for this work.
This is a key muscle we want to strengthen in MoFo’s culture and systems: the ability to empathize with our members’ aspirations, challenges and benefits.
Regularly exposing staff and community to these stories from our network can ground our strategy, boost motivation, aid our change management process, and regularly spark “a ha” moments.
We are rich in qualitative data. We sometimes fall into a trap of assuming that what we observe, hear about and help facilitate is too ephemeral and anecdotal to be useful. In reality, it’s a rich source of data that needs to be systematically aggregated, analyzed, and fed back to teams and partners. Working on processes and frameworks to improve that was illuminating in terms of the quality of what we already have.
The network mapping survey is already full of great stories. Our early review and testing proved this thesis — there’s greater fodder for evidence narratives / human impact in that data.
Connect the dots between existing work. This “story engine” work is not about creating another standalone initiative; the opportunity is to provide some process and connective tissue to good work that is already ongoing.
We can start to see patterns emerging. In terms of: the value members are seeing in the network. We can turn these into a recurring set of themes / tags / codes that can inform our research and feedback loops.
Feedback on the network survey process:
Open-ended questions like: “what’s the value or benefit you get from the network” generate great material.
This survey question was a rich vein. (Mozilla Science Lab did not ask this open-ended question about value, which meant we lost an opportunity to gather great stories there — we can’t get story tips when people are selecting from a list of benefits.)
Criticism / suggestions for improvement are great. We’re logging people who will likely also have good critiques, not just ra-ra success stories. And (importantly) some of these critiques come with explicit offers to help.
Consider adding an open-ended “link or artefact field” to the survey next time. e.g., “Got a link to something cool that you made or documented as part of your interaction with the network?” This could be blog posts, videos, tweets, etc. These can generate easy wins and rich media.
We’ve documented our next steps here. Over the last three days, we’ve dug into how to better capture the impact of what we do. We’ve launched the first discovery phase of a design thinking process centred around: “How might we create stories that are also data?”
We’re listening, reviewing existing thinking, digging into people’s needs and context — asking “what if?” Based on the Mozilla Foundation strategy, we’ve created personas, thought about claims they might want to make, pulled from the results of a first round of surveys on network impacts (New York Hive, Open Science Lab, Mozilla Clubs), and created a prototype workflow and tip sheet. Next up: more digging, listening, and prototyping.
What would you focus on next?
If we consider what we’ve done above as version 0.1, what would you prioritize or focus on for version 0.2? Let us know!
Our network is full of stories. Correctly applied, they can help us illustrate how the Mozilla Leadership Network acts as a magnet, training ground and recharge station for innovators and leaders protecting the web.
The challenge: right now, these stories are not captured in a systematic way across the network. That makes them hard to gather, understand and use to inform strategy. So…
How can we systematically aggregate, analyze and act on this qualitative data and raw material?
Our goal for this sprint:
Design a prototype story engine
Essentially: an MVP system to collect evidence narratives. These structured stories can serve as qualitative data, raw material for outreach and fundraising, feed into our various comms channels, and strengthen our network.
First step: do a 3-day design sprint. Build a quick and dirty prototype. Then test it with a handful of key customer segments.
Why? To increase and measure our network strength. And continually highlight the human stories behind it.
Quantitative + Qualitative
We want the best of both worlds: the human power of stories combined with methodological rigour. Learning from other organizations (Greenpeace, Upwell) and building on tested approaches (Utilization Focused Evaluation, Outcome Mapping, Most Significant Change).
Who? In this initial sprint the team is my colleague Chris Lawrence, longtime Mozilla contributor Christine Prefontaine and OpenMatt. This was an intentionally small group to help us get to some MVP process and prototype to discuss and test with provide a surface area for further iteration and conversation.
Inspiring Story Examples
Suchita’s story. A mini case study around leadership development for women’s digital literacy
Iltimas Doha’s story. A video college application one of our Hive members used to get into Parsons Design School
This project will touch on and potentially serve a bunch of different projects and initiatives already underway:
Network mapping & surveys. We’re making “Network Strength” our core KPI. Gathering qualitative data through network surveys. Sub-KPIs:
Alignment. How aligned are network members on our core issues?
Connection. How connected are they to each other?
Influence. Size, reach, etc.
Membership. “The Mozilla Leadership Network” is a new concept. What do network members want? What are their motivations? What are the right incentives to offer based on. We’re testing and refining our value proposition / motivation. (Rizwan, a consultant, is helping w. this work here.)
Curriculum. We’re building a curriculum around working open / open leadership. Some of the stories we collect can serve as mini-case studies / interviews / color for that curriculum. (Examples.)
Insights group. Our “Insights” group helps identify what our core issue priorities are, and gathers research around what other leading orgs are doing / thinking on those topics. (e.g., Right now our core issue priorities are: web literacy, privacy, inclusion.)
State of the Web. The Insights group publishes an annual report called “State of the Web.” It outlines how Mozilla / the world are doing on our core issues. Network member stories can provide ideal color and sidebars for this. It shows Mozilla as part of a network / movement, can provide quotes and pull-outs / sidebars for the report, and helps us keep our ear close to the ground. (Design brief.)
Kinds of data and stories we may want to collect:
1) What / Why
Alignment around our issues. What are network members doing / planning / thinking about our core issues? (e.g., web literacy, privacy / security / inclusion). And: why it matters. Inspire us and others about why these issues matter. maps to: network alignment, communications
Alignment around working open / open leadership / tech-savvy collaboration. How are you working on those issues? Open leadership / working open in action. Emerging best practises / inspiring examples of collaboration / lifehacker for work. maps to: curriculum
3) Motivation / Customer Service
Testing and refining our Value Proposition. How can we serve our members better? How do we learn more about what network members / customers want? How do we get better market / customer data? Stories and data they help us make our programs and inititaives / products better. maps to: Membership / value proposition
4) Celebrating successes
What does distributed winning look like? maps to: Network Influence, communications
As someone who has spent years understanding how to take community curated content like media, data and events and share them publicly (re: mapping community videos at My City Lives, events for Maker Party, club locations for Mozilla Clubs), I’ve learned some valuable lessons. Here’s just a few:
A map can be a powerful representation of the scale of your data and the local or global diversity. That being said, it’s actually quite hard as a user to navigate data on a map, find items and get a good grasp of the content.
There is power in the numbers. There’s no doubt that when a community member uploads a video or piece of data there is valuable information the organization receives such as how many people have shared a piece of data, who they are, where they are based and what they did. In the past, this was always the data we would store in the backend or share within the organization but so rarely do we use these numbers in a forward-facing way to motivate community members to continue sharing.
Short and sweet. I’ll keep this short, you want to provide just the right amount of information and not loose people in the details. For every question, media or data being inputted by a community member there should be a reason as to why that piece of information is valuable (to the organization and onlookers).
Easy to navigate and sort. I can’t stress this enough. When it gets hard to find events then people will stop using the product. Make it easy to navigate and allow for sorting functions that help an onlooker get to what they will find interesting quickly.
As the Mozilla Clubs program grows we know there are many clubs running regular events but we didn’t have proper mechanisms to capture what they were doing and show it in a public way. Creating an event reporting system was critical for us to gather event data, reward community members, share stories and show the impact of the global community. After months of scoping a plan to create an event report system, I was quickly reminded how much harder this is than it looks. You can get caught in the weeds of capturing and displaying user data trying too hard to make something visually appealing, or filled with information, or used by a global audience etc.
So when Matthew and Luke, Mozilla design superstars, came to us with an idea to break down the project and create a simple but efficient way to collect data I was weary that they thought it could be that easy. We sat down and identified the minimum number of questions we should ask and the value of the data we would capture. Within two weeks, TWO WEEKS!!!!!, they had a working prototype that we started testing with a couple community members. We did a quick review of our testing and one week later had a completed Mozilla Clubs Event Report system. It was quick, like really quick. And it was filled with features that I loved:
It was a Google Form (seriously, how simple and easy is that) for submitting events, which were then moderated by our team. The data is shared with us in a google spreadsheet and the staging site is on github.
At the top it shows how many events have been added, how many cities are represented and how many people have attended events. I find it personally encouraging, but I know it will also be motivating to our community members.
It’s simple which makes it easy to use but it’s fully branded so feels like it fits within our other products.
The searching works great. And as we curate more event reports, we will be adding sorting lists on the side for location, Web Literacy skills etc.
Thanks to Hannah, Matthew, Luke and all of those that helped in this exciting process of creating a lean, quick and effective reporting system that still blows me away. It’s now time to put this into the communities hands.
Firefox and Thunderbird have reached a fork in the road: it’s now the right time for them to part ways on both a technical and organizational level.
In line with the process we started in 2012, today we’re taking another step towards the independence of Thunderbird. We’re posting a report authored by open source leader Simon Phipps that explores options for a future organizational home for Thunderbird. We’ve also started the process of helping the Thunderbird Council chart a course forward for Thunderbird’s future technical direction, by posting a job specification for a technical architect.
In this post, I want to take the time to go over the origins of Thunderbird and Firefox, the process for Thunderbird’s independence and update you on where we are taking this next. For those close to Mozilla, both the setting and the current process may already be clear. For those who haven’t been following the process, I wanted to write a longer post with all the context. If you are interested in that context, read on.
Much of Mozilla, including the leadership team, believes that focusing on the web through Firefox offers a vastly better chance of moving the Internet industry to a more open place than investing further in Thunderbird—or continuing to attend to both products.
Many of us remain committed Thunderbird users and want to see Thunderbird remain a healthy community and product. But both Firefox and Thunderbird face different challenges, have different goals and different measures of success. Our actions regarding Thunderbird should be viewed in this light.
Success for Firefox means continued relevance in the mass consumer market as a way for people to access, shape and feel safe across many devices. With hundreds of millions of users on both desktop and mobile, we have the raw material for this success. However, if we want Firefox to continue to have an impact on how developers and consumers interact with the Internet, we need to move much more quickly to innovate on mobile and in the cloud. Mozilla is putting the majority of its human and financial resources into Firefox product innovation.
On a technical level, Firefox and Thunderbird have common roots, emerging from the browser and email components of the Mozilla Application Suite nearly 15 years ago. When they were turned into separate products, they also maintained a common set of underlying software components, as well as a shared build and release infrastructure. Both products continue to be intertwined in this manner today.
Firefox and Thunderbird also share common organizational roots. Both were incorporated by the Mozilla Foundation in 2003, and from the beginning, the Foundation aimed to make these products successful in the mainstream consumer Internet market. We believed—and still believe—mass-market open source products are our biggest lever in our efforts to ensure the Internet remains a public resource, open and accessible to all.
Based on this belief, we set up Mozilla Corporation (MoCo) and Mozilla Messaging (MoMo) as commercial subsidiaries of the Mozilla Foundation. These organizations were each charged with innovating and growing a market: one in web access, the other in messaging. We succeeded in making the browser a mass market success, but we were not able to grow the same kind of market for email or messaging.
In 2012, we shut down Mozilla Messaging. That’s when Thunderbird became a purely volunteer-run project.
Since 2012, we have been doggedly focused on how to take Mozilla’s mission into the future.
In the Mozilla Corporation, we have tried to innovate and sustain Firefox’s relevance in the browser market while breaking into new product categories—first with smartphones, and now in a variety of connected devices.
These are hard and important things to do—and we have not yet succeeded at them to the level that we need to.
During these shifts, we invested less and less of Mozilla’s resources in Thunderbird, with the volunteer community developing and sustaining the product. MoCo continues to provide the underlying code and build and release infrastructure, but there are no dedicated staff focused on Thunderbird.
Many people who work on Firefox care about Thunderbird and do everything they can to accommodate Thunderbird as they evolve the code base, which slows down Firefox development when it needs to be speeding up. People in the Thunderbird community also remain committed to building on the Firefox codebase. This puts pressure on a small, dedicated group of volunteer coders who struggle to keep up. And people in the Mozilla Foundation feel similar pressure to help the Thunderbird community with donations and community management, which distracts them from the education and advocacy work that’s needed to grow the open internet movement on a global level.
Everyone has the right motivations, and yet everyone is stretched thin and frustrated. And Mozilla’s strategic priorities are elsewhere.
In late 2015, Mozilla leadership and the Thunderbird Council jointly agreed to:
a) take a new approach to release engineering, as a first step towards putting Thunderbird on the path towards technical independence from Firefox; and
b) identify the organizational home that will best allow Thunderbird to thrive as a volunteer-run project.
Mozilla has already posted a proposal for separating Thunderbird from Firefox release engineering infrastructure. In order to move the technical part of this plan further ahead and address some of the other challenges Thunderbird faces, we agreed to contract for a short period of time with a technical architect who can support the Thunderbird community as they decide what path Thunderbird should take. We have a request for proposals for this position here.
On the organizational front, we hired open source leader Simon Phipps to look at different long-term options for a home for Thunderbird, including: The Document Foundation, Gnome, Mozilla Foundation, and The Software Freedom Conservancy. Simon’s initial report will be posted today in the Thunderbird Planning online forum and is currently being reviewed by both Mozilla and the Thunderbird Council.
With the right technical and organizational paths forward, both Firefox and Thunderbird will have a better chance at success. We believe Firefox will evolve into something consumers need and love for a long time—a way to take the browser into experiences across all devices. But we need to move fast to be effective.
We also believe there’s still a place for stable desktop email, especially if it includes encryption. The Thunderbird community will attract new volunteers and funders, and we’re digging in to help make that happen. We will provide more updates as things progress further.
At our last staff meeting we were asked to share practices, projects or initiatives that promote diversity and inclusion in an individual or team’s current work. The list was great benchmark on how to embed diversity and inclusion tools into the work environment so I wanted to share a list of examples as told by Mozilla Foundation employees.
Practices and Ideas
Building inclusion in team meetings by starting and ending with “openings and closings” that allow participants to name what they need from others, what they want to work on, and how each person did. Another idea is doing an “around the horn” moment during a meeting where everyone speaks so that all participants have a chance to make their voice heard.
Introduce Code of Conducts or Ground Rules at the beginning of convening’s and large group gatherings. It’s a great way to set the context, expectations, and identify good/bad behaviours.
Jointly drafting and agreeing upon ground rules, team expectations, decision-making and working through conflict are essential so more than being heard, people act together
Reach out to and engage potential partners outside of the organizations comfort zone that allows us to bring new faces and people into our work, who wouldn’t have been otherwise.
Identify what diversity at events mean to us and how we can purposely work to engage those diverse audiences at events like Mozfest.
Be intentional about clarifying roles & expectations, and reaching out to people for feedback.
Understand how to engage all voices, including those of introverts. See Susan Cain’s Ted Talk about “The Power of Introverts”.
Actively and/or intentionally reach out to invite people to invite them to things (meetings, demos, etc.) instead of a general “everyone’s invited” approach.
“Silent Etherpadding”. Also known as silent working and collectively adding to a document at the same time. It allows for diverse communication and interaction styles to be integrated into a meeting. In this practice you get ideas and perspective from all people.
Incorporating user research and testing as essential steps when building prototypes. It means you challenge your assumptions about what solutions people want, how they’ll use it, etc.
The Open Web Fellowship recently had 443 from 91 countries. The team enlisted a group of cross-programs reviewers who underwent a blind audition process with the applications where they would review applications without knowing names, genders etc. and list their top submissions.
The Open News team invited a small group of community members to review session proposals for the upcoming SRCCON event. They intentionally built a volunteer group to fill in gaps we might have as a team and help us consider diversity along a lot of axes, not just gender and ethnicity, but also professional background and organization size, for example.
Hive Chicago went through a Request for Proposal strategy project using a Human Centered Designframework: used stakeholder input to frame the design challenges and running over 30 interviews with a diverse spectrum of stakeholders based on inquiry questions (starting with a survey to see if these lines of inquiry are even valuable to other as a check on our understanding) to get unbiased input on best practices, etc. rather than specific suggestions for what we should change.
The Coral Project worked hard for a diversity of voices in the Beyond Comments event last month – and that meant not just in terms of race and gender but also in background and experience. They wanted to make voices that aren’t usually part of the conversations feel welcome – they had activists, community organizers, commenters talking to technologists and newsroom staff, and made a clear code of conduct for the event to make people feel safe. They also made sure to include a diversity of faces and experiences in the personas.
This Code of Conduct exercise developed by the Mozilla Science Lab at the Working Open Workshop helps anyone create a code of conduct that they can use at any event.
Use chat systems that make it easy for all contributors (staff, community, volunteers etc.) to join, even if they are less technical. Mozilla Foundation has implemented Mattermost as a recent tool to allow our chat to be more inclusive.
Using Github to coordinate projects and tasks in the open and encourage a healthy discourse.
Engage in fellowship programs, like Kairos Fellowship, which is a six month on-the-job training program for emerging digital campaigners of color.
The crowd beamed with pleasure as each team crossed the stage. One by one, cheering on each other, they took the microphone to share their projects. Four teams of young women at our first annual #femhack had two minutes to explain the problem they were trying to solve and how they would solve it.
We had twelve participants from around Connecticut.
We began the day with an icebreaker. It was one I poached from the We Are LRNG conference. You basically ask people to draw their social media profile on a post it note. It works and can be fun. Plus you get a sly little name tag next to participants.
Only one of the teams had any previous coding experience.
A few of the young women attended our YouthZone sessions the previous day where we used Mozilla’s X-Ray Goggles to “hack” school websites and Mozilla’s Thimble to make memes. Students learned about different HTML tags as they remixed the the images, headings, and paragraphs on he pages. During Youth Zone one participant remixed an animal shelter website where her parents used to work. She made them the world’s best animal rescuers.
The other participants had never peaked behind the curtains before so we started Saturday with Thimble and the Letters#2nextprez campaign. The participants all shared their ideas on how to get more women into tech.
They then had the rest of the day to work on their projects:
Diversity in tech will not happen at Google, Twitter, and Facebook. We will not solve this issue in Silicon Valley. The work must happen in our cities , schools, and community colleges. Our networks grown in churches and Girl Scouts. In programs like Gear Up. Once diversity is an HR issue its already too late.
We must remember that America NEVER scored the highest on any international assessments of learning. Expansion through genocide and centuries of slavery leaves long lasting scars…but the United States of America WAS always the place the best and the brightest wanted to be. We must preserve this uniquely American advantage. Yet the xenophobia rhetoric in todays’ politics is a direct threat to our economic future.
Most importantly they lit a path for the young women to see a future in tech where no voices are silenced or lost.
Campaign Core- This team created a place for students who want to get involved in different social justice campaigns. It is a database of social media accounts . The goal is to connect users to topics that matter. There are also lessons on running effective social media campaigns for change.
EZCode– This project is designed to teach kids basic HTML. There are flash cards that have questions one one side and directions on the other. There is also a directory of places you can learn to code.
RPGgeniuses- This was a role playing game that had kids learn HTML and CSS. Students were given a guide, completed scenarios where they learned lessons, and then would complete a quiz.
Danbury Girls Who Code– The Danbury Branch of “Girls Who Code” designed a website for their club to recruit members,