Saying goodbye to Demo Studio

When the Demo Studio area of MDN launched in 2011, it was a great new place for developers to show off the then-cutting-edge technologies of HTML5 and CSS3. In the years since then, more than 1,100 demos have been uploaded, making it one of the largest demo sites focused on cross-browser web technology demos. Demo Studio also served as the basis for the long-running Dev Derby contest, which offered prizes for the best demos using a different technology each month.

In the last few years, quite a number of code-sharing sites have become very popular, as they are solely focused on code-sharing functionality, for example, Github Pages, CodePen, and JSFiddle.

Given the variety of alternative sites, and the technical and logistical costs of maintaining Demo Studio, we at MDN have made the decision to remove the Demo Studio after January 15, 2016. After that date, demos will no longer be available from MDN via Demo Studio.

We encourage demo authors to move your demo to an alternate site, such as your own website, if you have one, or one of the popular code-sharing sites. In case you no longer have a copy of your demo code, you will be able to download your demo code from Demo Studio until 23:59, Pacific Standard Time, on January 15, 2016. If you’re looking for a place to share your demo, check out our guide to Using Github pages.

After January 15, 2016, you will be able to request a copy of your demo code by submitting a bug in Bugzilla. Please be sure to include the name of your demo(s) and an email address at which you can receive the source code. Demos will be available via this process until April 8, 2016.

Key Dates

2016-01-15
Demo Studio will be removed; deadline to download your code.
2016-04-08
Deadline to request a copy of your demo code manually, if you didn’t download it.

You are welcome to link to the new location of your demo from your MDN profile page. No automatic redirects will be provided.

Thanks again to all the demo authors who have contributed to Demo Studio!

Leadership Summit Planning

With a successful Mozlando for the Participation Cohort still in our rear-view mirror, we are excited to begin the launch process for the Leadership Summit, happening next month in Singapore.

20860542330_2a562ee801_k

What is the Leadership Summit?

 

As part of the Participation Team’s Global Gatherings application process for this event,  we asked people to commit to developing and being accountable to recruit and organize contributors in order grow the size and impact of their community in 2016.  We ran also ran a second application process this month, to identify new and emerging leaders – bringing our invited total to 136.

Participation at Mozlando

The Leadership Summit will bring together this group for two days of sessions and experiences that will:

Help Participation Leaders will feel prepared (skills, mindsets, network) and understand their role as leaders/mobilizers who can unleash a wave of growth in our communities, in impact and in numbers.

Help Participation Leaders leave with action plans and commitments, specific to growing/evolving their communities and having impact on Connected Devices and a Global Campus Campaign.

Help everyone leave feeling that “we’re doing this together.” Everyone attending (volunteer and staff Mozillians) will feel like a community that is aligned with Mozilla’s overall direction, and who now trust one another and have each others back.

“You mentioned Connected Devices and a Global Campus Campaign?  Say more…”

Sure! In setting goals for 2016, we realized that focusing on one or two truly impactful initiatives, will bring us closer to unleashing the Participation Mozilla needs, while providing opportunity for individuals to connect their ideas, energy and skills in the way that feels valued and rewarding.

To that end, we are currently developing a list of sessions and experiences for the Leadership Summit that will set us up for success in 2016 as community leaders, and on each of our three focus areas:

  • Connected Devices
  • Campus Campaign
  • Regional / Local / Grassroots

We will say more about each as we get closer to the Summit, as well as including the opportunity to connect personal goals through 1:1 coaching for all attending.

“What about Reps and other functional areas?”

Fear not!  Sessions and experiences will include:

Alignment for Reps around changes in the program, what’s expected of them, and what they can expect from Council and staff in 2016

Opportunity for volunteers in specific functional areas to build relationships with staff in those areas

CWAGxUaW4AEZxRi

This event will complete the process of merging participants from three events into one activated cohort – this is our beginning, and I am excited, I hope you are too!


 

Feature Image by ‘Singapore’ CC by 2.0 David Russo

Firefox 43 new contributors

With the release of Firefox 43, we are pleased to welcome the 46 developers who contributed their first code change to Firefox in this release, 35 of whom were brand new volunteers! Please join us in thanking each of these diligent and enthusiastic individuals, and take a look at their contributions:

Participation, yes and, community

The "Foxy" mascot is held aloft by attendees of the Mozilla 2013 Summit in Brussels

Photo by Marcia Knous


I’ve noticed that the terms “participation” and “community” have become more or less interchangeable in the context of Mozilla. I’ve even had a conversation with a Mozilla executive who said “I thought they were the same.”

It seems that the term “community” has been somewhat deprecated within Mozilla because it is ambiguous, in that it can mean different things to different people, which can lead to miscommunication. For example, some people use “community” as a shorthand for “volunteers” while others very intentionally use it to mean all Mozillians, paid and non-paid.

I see “participation” and “community” as related but distinct concepts, both of which are essential to Mozilla. Let’s start with definitions (sorry, I’m a word nerd). The Participation Team’s wiki page says:

Participation is when people can freely contribute their energies, time and ideas to support Mozilla’s mission.

So far, so good.

Here’s my generic definition of “community”:

A community is a group of people who interact and develop a network of relationships around a common factor.

The “common factor” is the wild card that leads to a wide variety of types of communities. If the common factor is physical location, the community can be a traditional geographic community. Some other types of communities include:

So, what kind of community is Mozilla? I consider Mozilla to be a community of action united by the Mozilla mission, which is the shared goal. Members of the Mozilla community take action (that is, participate) in order to realize that mission. However, Mozilla is really a constellation of overlapping sub-communities based on geography, interest, or practice. The nature of the sub-community determines the type of action that its members typically do. For example, a localization community shares a particular language, such as French, and its members take action by localizing software, websites, or documentation. A community for a functional area, such as QA, has some characteristics of a community of practice, but members focus on the practice of their skills on behalf of Mozilla.

Other key concepts in my definition of “community” are interaction and relationships. People who share a common factor, but don’t interact about it or have relationships with one another as a result, are not, for the purposes of this discussion, a community. (I know this excludes another widespread use of the word. That’s why I gave my definition.)

So, to bring the concepts together:

Participation is the “what” of the Mozilla community; community is the “how” of Mozilla participation.

Or rather, community, in my opinion, should be the “how” of participation. If people simply participate, but don’t interact and build relationships with others (that is, become part of a community), they are unlikely to sustain interest in participating over a more than, say, a few months. Therefore, when creating opportunities for participation, one needs to build-in opportunities for interaction, in order for the set of participants to develop into a community. When participants have relationships with one another, they are more likely to keep coming back to participate, making the group sustainable, that is, retaining more people than it loses.

Participation and community don’t necessarily go hand in hand; ensuring that they do requires careful design of participation opportunities.

The canonical example of participation in open source software is contributing a code patch. A programmer finds something that needs fixing, gets a copy of the codebase, fixes the bug, submits a patch for review, and ideally has the patch accepted into the main codebase. At the very least, this programmer has to interact with a reviewer. Ideally, she interacts with other members of the project earlier and more extensively than just at review time, through mentorship and discussion of the bug. She might also subscribe and post to a relevant mailing list, and read and comment on other bugs. Through these interactions, repeated over time, she becomes part of the community for the open source project.

However, not all participation opportunities have interaction built-in. For example, Mozilla Developer Network (MDN) is a wiki of developer documentation. Because it uses a pure wiki model, no review is needed for a change to go live on the site. It’s quite possible for someone to create an account and make many edits to the site without ever interacting with another human being. Such contributors are participating, but are not engaged with the MDN community. As community manager for MDN, one of my challenges is to draw contributors like that into communication channels such as mailing lists or IRC, and encourage them to interact with other members of the MDN community.

As your Mozilla team sets goals for 2016, with an eye towards inviting participation, I encourage you to also look for ways to invite and encourage interaction among participants, especially if open participation is new for your team. This could be as simple as creating a category on the Mozilla Community Discourse site, and encouraging participants to post there via welcome emails. Of course, make sure that existing team members initiate and respond to discussions there as well; they are part of the community, too. Communities don’t happen overnight, and they require (repeated, sustained) help in order to grow. The payoff is in sustained participation, as well as in the intangible benefits of relationships with fantastic Mozilla contributors.

Firefox 42 new contributors

With the release of Firefox 42, we are pleased to welcome the 41 developers who contributed their first code change to Firefox in this release, 26 of whom were brand new volunteers! Please join us in thanking each of these diligent and enthusiastic individuals, and take a look at their contributions:

Participation Lab Notes: Volunteer vrs Contributor

4773973784_8e249c98e7_z

As part of the Participation Lab’s efforts we recently began conducting  experiments on the Get Involved Page seeking to better understand how people navigate and connect (or fail to connect) to contribution opportunities. In preparation for this experiment we looked at some of the research that the Mozilla.org team had conducted in recent years, and a number of their  key learnings led us to a deeper conversation about the language and labels we use to invite contribution to Mozilla. Some of the those learnings were:

  • People need to understand what, and why before they’ll be interested in understanding how they can contribute to Mozilla.
  • We must make it immediately apparent that the Get Involved  page is seeking volunteers and not employees.
  • We need to set clear expectation of investment/journey needed to get involved or become a Mozillian.

This matched some other feedback,  and as a result we decided to conduct a series of interviews to discover more ideas and prejudices that exist around the terms volunteer and contributor. Eighteen interviews covering diverse perspectives were conducted, these included core contributors, project leaders, alumni, community project leads, those working in open science, advocacy and randomly selected people in my life who had never contributed to Mozilla.  We discovered four interesting insights shared below.

Project preference is ‘Contributor’

 

Overall, people working in, or already volunteering with Mozilla were more comfortable with ‘contributor’, but agreed that unless your background was working in a field like software engineering, or science where the term is already part of the language ecosystem, it might be challenging to grasp.  I also noticed  a trend in feedback that acknowledged  once you’re regularly involved  in a project you might no longer be objective, and that we may, in fact, be skewing even the most common understanding of these terms. One example given was the use of  ‘paid contributor’ and ‘volunteer contributor’, which made no sense for most people outside of Mozilla.

The term ‘Volunteering’ is more universally  associated with lending time and skills but…

 

While people seemed to generally understand that volunteering was about lending time and skills, I encountered sensitivities that the word ‘volunteer’ which invoked feelings of being ‘charitable’ vs the more empowered feeling of being a ‘contributor’ .  I heard that ‘contribution’ lends to a feeling we’re part ‘part of something ’ while ‘volunteering felt more detached.  One core contributor felt very, very strongly, that volunteering was not the term for what they do at Mozilla.

‘Contribution’ feels more like giving a gift or donation

 

Feedback from non-technical contributors ,and those I spoke with outside the Mozilla community indicated that  the term “contribution” was easy to misinterpret as being about donating funds or something of greater significance than some people felt they could offer.  When asked, a couple of people cited political campaigns, and fundraisers as the most common association they with the word ‘contribution’.

What’s in a Name?

 

It was also suggested that at Mozilla we should stop labouring over generalized terms like volunteer and contributor,  and instead focus  energies on clarifying ways people can help – One person felt that such opportunity  exists in more explicit ‘role titles’  i.e. Android Community Ambassador’.   The hypothesis is, that by providing role titles we can help people connect to opportunities that are resume-worthy with recognition that contribution is an opportunity.  Of course, there are already examples of success with role names demonstrated by the Mozilla Reps program and most recently Club Captains and Regional Leads in Webmaker Clubs.

Also..

We had an interesting suggestion that  we make up our own name!  Create a Mozilla-fied name for volunteers that makes volunteering at Mozilla a unique version of both terms.  An inspiring example was the London Olympics which called volunteers ‘Games Makers’, what a Mozilli-fied version would be remained unclear 🙂  but I’m sure we could come up with something.  What do you think?

Additional lure of a Mozilla-fied name is a chance to help people recognize the amazingness of the community they would be joining which MDN reported to be a factor in repeat contribution in their area  – and similar to how an Olympic volunteerism resonated with a name describing their impact.

So where from here?

 

There is the opportunity for continued experimentation and testing using the Get Involved Page, and  we would love to hear from you – contributor volunteer, Mozillia-fied name?

What experiment  do you think the Participation Lab should design  next with these new insights?

 


 

Image: “Mozilla Summit Day 2” by Roland Tanglaois licensed under CC BY 2.0

Meet an MDN contributor: klez

Photo of Frederico klez Culloca

Federico klez Culloca made his first few edits to MDN in 2013, but started contributing in earnest in 2014, as a localizer for Mozilla Italia. After a couple of months, he started attending the bi-weekly MDN Community meeting, and later the Learning Area meetings. After that, he concentrated his efforts on the Learning Area of MDN, especially the Glossary.

He says that working on MDN gives him a good idea of how an organization as big as Mozilla actually works, bringing together paid staff and volunteers.

His advice for MDN newcomers?

Don’t be afraid to make mistakes in good faith. Someone is always able and willing to correct them and help you learn from your errors. It’s a wiki, after all 🙂

Thanks, klez, for all your contributions to MDN!

Participation Lab Notes: The Power of Swag

It doesn’t take long, once you’ve entered the Mozilla community before you notice that swag is a big part of Mozilla. Stickers, t-shirts, lanyards are everywhere and for many Mozillians these things have become a kind of currency with emotional and physical value.

Photo by: Doug Belshaw on Flickr

Photo by DougBelshaw/CC BY 2.0

In 2014, Mozilla spent over $150,000 on swag to engage contributors across four major initiatives: Maker Party, MozFest, Mozilla Reps, and Firefox Student Ambassadors (FSAs).

However we rarely stop to examine what we are learning about the results, benefits and challenges of this investment.

In order to surface and capture these insights the Participation Team interviewed four groups at Mozilla, for whom swag is a core part of their activities, and identified the most interesting insights and challenges faced by each group.

As a result, we discovered that many of the groups face similar challenges but have found distinct solutions and strategies for managing them. The two major insights were that by encouraging local production of swag, and creating swag that is tailored specifically to the needs of the community, costs can be minimized and value to the community increased.

Maker Party

Although in the past year, swag has become a much smaller part of Maker Party as the campaign has become shorter (17 days vs. the previous 2 months) and more contained. In 2014 thousands of people spent the summer throwing events, and swag was an integral part of growing and motivating the Maker Party community.

Insight : Swag Legitimizes Hosts & Events

Much more than a form of recognition for event hosts, in many communities swag is perceived as a vote of confidence from Mozilla that legitimizes both the host and the event. Many communities feel that if we are willing to support an event host and their event through physical things, and it marks them as “officially sanctioned” by Mozilla and this alignment with the brand dramatically increases the influence and reputation of the contributor and the event.

For example, in South America, a Maker Party host created Mozilla branded mouse pads to legitimize their events in the eyes of local internet cafe owners who let them use the space for free in exchange for Mozilla branded mouse pads.

Challenge: Cost of Shipping

For Maker Party, shipping swag across the world, often to extremely remote areas, was very expensive and problematic. Certain countries charge enormous taxes on clothing and have been known to detain parcels with t-shirts – to the detriment of volunteers who often cannot pay the high customs fees.

MozFest

While MozFest, as a short-term festival is a bit different from the other examples,  it identifies another way in which we use swag to build and support community.

Insight: Swag is Key to Partnerships

Every year MozFest partners with other like-minded organizations to put on the event. As part of this relationship, partners are offered the opportunity to distribute swag and some promotional material to attendees. As a result Mozilla can produce a small amount of swag like a tote bag and water bottle, and have partners add their swag to create fun gifts for participants that also act as promotional pieces for partners and Mozilla.

Challenges: The Right Swag

Finding swag that is re-usable and has value outside of the event is challenging, but water bottles and tote bags have proven popular and effective, and have the added benefit of reducing the event’s environmental footprint.

Mozilla Reps

Unlike Maker Party or MozFest, Mozilla Reps is a community where individuals participate in multiple ways over a sustained period of time. For this group, it is often the variety rather than quantity of swag that drives excitement.

Insight: Creating A Collectors Culture

Within Reps, swag is a great way to acknowledge contributors and support events. However, in some circumstances, swag can come to be seen as a symbol that represents value and status in the community. Therefore as more of a swag item is produced the value of each item diminishes, and collectors culture has developed. While rare swag is a very powerful tool for driving engagement and recognizing achievement in the Reps community, it is important to be aware of the number and variety of an item that is produced, and to carefully manage expectations to prevent swag becoming an end in and of itself.

Challenge: Mitigating Expectations

As swag is a large part of the Reps culture, it is important to be careful about the expectations that are set around the value of swag. Limiting the kinds of official swag that is produced to t-shirts, stickers, and posters and having clear value attached to each, may be one way to keep expectations low and guard against increasing expectations.

FSA

The Firefox Student Association has many parallels in it’s structure and its relationship to swag as the Mozilla Reps program. However by carefully controlling the value of swag, and encouraging local production, many of the challenges faced by other groups have been avoided.

Insight: Careful Curation & Local Production

The FSA’s have solved problems related to shipping swag, and reduced the “freebee” quality by having FSA’s create their own swag locally and then be reimbursed for the cost. Like the Reps program they also have a collectors culture but set formal expectations on the “value” of different kinds of swag ie. t-shirts are something you have to earn, stickers are freebees you can give away at your event, and posters are something you have to produce yourself.

Challenge: Tracking Designs

Because unique designs are a large part of what gives t-shirt swag it’s value, there is a struggle to find and keep track of the many ways t-shirts and designs are being used across Mozilla. In order to coordinate the FSA program suggested creating a central repository of t-shirt designs and what/when they should be distributed so that the use of swag can be better aligned across all of Mozilla.

Overall, across Mozilla there is a great deal being learned and experimented with around swag as well as many areas for growth and improvement. Our hope is that by surfacing these lessons and insights, we’ll spark new conversations and gain more insights into the swag processes and how it can be improved. If you have experience or thoughts around swag at Mozilla please share them in the comments here, or on the Participation Team Discourse page.

MDN Fellows: What They Did & What’s Next

It’s hard to believe our MDN Fellowship Pilot is winding down! Announced in May and oriented in June, our five Fellows and mentors have been heads’ down ever since.  Here’s a short summary of their accomplishments in the program and a taste of what’s next.

Curriculum (Steve Kinney, Fellow; Chris Mills, Mentor)

For the curriculum Fellowship we selected to write a full course on “Advanced beginning JavaScript.”  Steve and Chris considered this to be important because, while there are loads of resources looking at beginner-level stuff like variables and basic function usage + a load of discussion of really advanced techniques, there is very little to help a budding developer who has already mastered the basics and wants to level-up their skills.

Steve and Chris are still working on the course, and will be for weeks to come — see the repo, and read the index file for an idea of the content we’ll include.

If you want to dig in right away, you can already start working through some of the tutorials and demos.

Service Workers (Flaki Szmozsanszky, Fellow; Brittany Storoz + Anne Van Kesteren, Mentors)

With more widespread browser support for service workers fast approaching, we were aiming for creating a “baseline” service worker content kit. It was to cover the general, high-level “what are service workers and why should I care?” questions as well as being able to provide resources for interested parties. Take a test drive of the content kit here.

Beyond just collecting and completing the above baseline content kit, during the Fellowship Flaki had the chance to work closely not just with his service worker mentors Brittany Storoz and Anne van Kesteren but also with the content & platform teams at Mozilla who work hard on implementing service workers and related features in Firefox & Firefox OS.

We also devised a proof-of-concept transparent image format polyfill that uses service workers, which, besides being a novel approach in using service workers, helped a lot in uncovering some lurking bugs in Firefox’s preliminary implementation. We especially want to thank Ben Kelly of the platform team who was invaluable in tracking down, reporting and fixing those issues.

See this blog post for more details on the content kit and the proof-of-concept polyfill.

Test The Web Forward (Ben Boyle, Fellow; James Graham and Josh Matthews, Mentors)

As Test the Web Forward already has great documentation on getting involved, we had two goals: (1) address the quality of the contributions, and (2) build confidence in new contributors.

We’ve focused on understanding web specifications in order to write accurate tests both in terms of coverage (understanding the detail in a simple specification) and in challenging assumptions so that tests are based on what the spec says (and not what we think it means).

We’ve set up a codepen to use the testing framework. This can be forked to write new tests to check behaviour and is useful for exploring a problem, or for accompanying bug reports. It’s a nice quick way to get started, before installing the Test the Web Forward repo to contribute directly.

We are also working on a couple of case studies (more to come) showing the experience after finding an interoperability issue including researching the specs and analysing the behaviour seen in browsers. Each journey is different, and a wonderful chance to learn more about the web.

Web App Performance (Vignesh Shanmugam, Fellow; Harald Kirschner, Mentor)

With the increase in average website size, we need to better access the web from varying levels of computing power devices and experiments to show the impact on revenue with the increased load times – particularly during development.

The content kit that we are building helps web developers and others understand basic techniques for their websites to load faster. The focus is heavily on the network side of the performance since 70% of the time is spent on the network. Our Content Kit also has various beginner and advanced tutorials, slides and demos.

The kit is not complete yet. We are also planning to include lots of deep dive tutorials on understanding packet level information on TCP stack, how to leverage modern capabilities in browser etc. Please feel free to pour in your ideas.

It was an amazing experience to work with the fellows and mentors who are all part of the MDN fellowship program. Thanks to Mozilla for making this happen 🙂

 

WebGL (Greg Tatum, Mentor; NIck Desaulniers, Mentor)

It has been really exciting being part of the first Mozilla Fellowship group. One of the big reasons for my involvement with the web and open source communities is the feedback from my peers and the quick sharing and collaboration on ideas. The fellowship has quick-started my involvement with MDN and their enthusiastic team of staff and contributors. One of the most valuable experiences was being able to write an article for MDN and get immediate in-person feedback from one of the staff writers. It was really empowering to know that the docs I use every day are so easily improved.

I had a blast diving into explanations of some of the fundamentals of how you go from abstract data to 3D-rendered images in the browser. It was really helpful for my own understanding to build out content kits and articles that step through matrix math fundamentals, the 3d projection process, and finally getting to taking that data and lighting it.

I’m very passionate about creative coding and the technologies surrounding it. It still feels like a niche genre with a community that is growing, especially with people moving from desktop applications to web projects. I only want this community to get larger and produce more and more interesting works that inspires me. I hope my time spent with the Mozilla Fellowship and other open source contributions can help to continue to grow people’s knowledge and interest in technologies like WebGL.

Content kits

Shared utility library for WebGL explanations:

MDN Articles based off of the content kits:

…with Lighting Models coming soon

What’s Next?

We’ll be evaluating the role that this type of program might make towards the goals of both MDN and Mozilla overall. You also might see more contributions on MDN from our Fellows. And rumor has it you may be seeing some of this great work – and even contributing to it – at our November MozFest event in London.
Can’t get to London? Nothing’s stopping you from diving into those repos.

Firefox 41 new contributors

With the release of Firefox 41, we are pleased to welcome the 62 developers who contributed their first code change to Firefox in this release, 51 of whom were brand new volunteers! Please join us in thanking each of these diligent and enthusiastic individuals, and take a look at their contributions: