MozillaWiki team update, call for new leadership

From July 14-20th, I was in Mexico City for Wikimania 2015 with the MozillaWiki team. I’d been disengaged for a number of months and was excited to re-engage that week to help figure out our long-term plan.

Mozilla-wiki-logo-revThe work done by the MozillaWiki Team this past year and a half has been a labor of love, but like so many things at Mozilla, love alone unfortunately isn’t enough to sustain forward momentum. The MozillaWiki is currently at a crossroads, and we want to ensure it has a chance at a strong future. Before I get into the details of what’s next, I’d like to share some recent history.

For a number of years, the MozillaWiki lacked stewardship. It fell into disrepair. Spam was rampant, the deployed version of MediaWiki was rapidly approaching end-of-life, integrations were beginning to break, and wiki gardening best practices around metadata and namespacing were non-existent. And yet it remained one of the most accessible comprehensive records of work at every level of Mozilla and a significant entry point for contributor participation.

While the former Community Building Team seems to have been swept under the historical rug as a failed effort, it did have a number of successes. The MozillaWiki is one of them. As the lead of CBT’s Education Working Group, Christie Koehler recognized that the MozillaWiki was a critical piece of participation infrastructure needing some serious TLC. In the past year and a half, she built a team of Mozilla staff and volunteers, established a product roadmap emphasizing collaboration and participation features, and brought the MozillaWiki into modern times.

Last year in August, the MozillaWiki team had a work week in London that coincided with Wikimania 2014. In attendance was Jennie Halperin, Joelle F, Gordon P. Hemsley, C Liang, Christie Koehler, and myself. We created and deployed a new sidebar nav and main page, planned and tested the upgrade from Mediawiki 1.19 to 1.23 (without any downtime!), and planned our roadmap through the beginning of 2015. This week was a major milestone because we were finally able to get past a lot of technical debt enabling us to concentrate on adding new features.

In the year since, the MozillaWiki team has: streamlined the deployment process, closed all open security bugs, audited and adjusted user group rights to improve security and usability, deployed widget capabilities which enable Google Doc embeds, added flowchart and diagram creation capabilities via the GraphViz extension, and added the ability to create pages from Etherpads.

In November 2014, Christie wrote a blog post celebrating the 10th year anniversary of MozillaWiki with screenshots showing its evolution.

At the outset of 2015, the following executive summary slide deck was created outlining MozillaWiki’s usage statistics across the org as well as the MozillaWiki Team’s accomplishments and long-term goals.

Fast forward to this year’s Wikimania. MozillaWiki team members in attendance were Christie Koehler, Gordon Hemsley, Jason Crowe, Janet Swisher, and myself.

Recently, life changes have made continued progress difficult. Gordon Hemsley and I, both module peers for the Mozilla wiki, have been disengaged for a number of months as he found demanding work and I’ve been focused on personal development projects. Christie Koehler, module owner for MozillaWiki, joined the MDN team and has new staff responsibilities that don’t include stewardship of MozillaWiki. Other team members have had similar developments. We find ourselves facing the fact that there is no one able to commit to actively push things forward, nor passively maintain responsiveness.

Given the lack of resources and firm commitment on the part of staff and volunteers, the MozillaWiki team has decided it makes more sense to dissolve its current form and prepare for future stewards to take ownership of the MozillaWiki.

For our last hurrah in Mexico City, we launched a mobile interface for MozillaWiki! We also began taking steps to freeze active development, maintenance, and administration of the wiki. We are preparing a transition document so the next team of people, whoever they might be, can build upon the foundation we’ve established without having to start from scratch like we did.

We also visited the Teotihuacan pyramids outside of Mexico City.

DSC_0601

I hope this development can help fuel discussion on the role of critical participation infrastructure (such as MozillaWiki, Mozillians, the Heartbeat dashboard, the Reps portal, etc) in Mozilla’s future and the critical need for it to be resourced and aligned/integrated with other Mozilla infrastructure.

There is so much opportunity for continued work on the MozillaWiki that would make it a better tool for participation and cross-team collaboration at Mozilla. Things like a mobile interface, real-time collaborative editing, and tighter integration with other Mozilla infrastructure are realistic opportunities for a small technical team. Additionally, there’s also plenty of work left undone that aligns with emerging Mozilla Participation and Learning strategies in the areas of leadership development, curricula+workshop dev, and building collaborative bridges between volunteers and staff.

This wiki page has a section, ‘How is the Wiki a critical resource to the Mozilla Project?‘ which succinctly explains what motivated my participation on the Wiki Team. My personal story with Mozilla started with years of lurking on MozillaWiki, and I know others feel as strongly about it as I. It holds so much of our history, and this is an active living history with a great many people relying upon it as their primary resource for understanding Mozilla, where it’s going, and how to get involved.

There are outstanding questions regarding who will do daily maintenance including handling account requests and content related tasks, as well as long-term upkeep so MozillaWiki doesn’t again fall into disrepair. If you’re interested in helping to steward the wiki, check out our in progress transition document and get in touch.

a new participation infrastructure project: Gossamer

I have a confession to make.

I’ve been a volunteer contributor at Mozilla for a number of years now.. and during this time, I haven’t even begun to do the work that motivated me to join to Mozilla in the first place. I’ve made all sorts of excuses like needing to cultivate new skills, or thinking that Mozilla’s organizational culture needs to change somehow.. and then I can finally do the real work I’m here to do.

Well, I’ve been working to level up my skills and in the past year Mozilla has shown strong signs of becoming the organization I’ve been dreaming it could be! All the excuses I give myself are disappearing, and yet I still don’t feel ready to participate where I think I can make the biggest difference.

Maybe I’ve been looking a this all wrong. Maybe what’s missing isn’t something intrinsic to Mozilla as a whole, nor something within myself. Maybe what’s missing is a process, a clear contribution pathway for me to participate in the work I’d like to do within Mozilla.

The work I’ve long felt driven to participate in is facilitating the design of new architectures for personal data ownership and sovereignty. I want to help find answers to questions around what the web looks and feels like when your user agent is no longer a browser running on top of an operating system, but a networked ecosystem of devices, data services, physical objects, and contextual identities all tied together securely by open infrastructure you can choose to delegate to companies like Google and Microsoft, or completely host under your bed without loss of functionality or experience.

Like so many of the technical challenges facing Mozilla right now, working towards such a vision requires figuring out whether the chicken or the egg comes first. In Firefox, this often translates to Platform or UX. I see a path towards the web I want that begins with UX, but Mozilla doesn’t really have a viable contribution pathway for volunteers (especially non-coding volunteers) to participate in proposing ambitious new browser features.. especially features tied to a longer-term vision. Rapid prototyping is difficult because not only would I have to recruit a developer, but technical overhead is also a barrier (the dev environment, learning how to create browser extensions which often means learning some XUL, etc) for whomever I recruit. And don’t forget the step of sharing an experiment with Mozilla UX to vet the idea and make the case for getting it into Mozilla’s bloodstream.

Provided a volunteer-driven project could get to that point, would the UX team even have the bandwidth to engage volunteers let alone vet and possibly champion their ideas? For my own efforts, I’m confident I could make this happen. I could totally recruit a team, build some prototypes together, and essentially create my own process for pipelining new experimental features into Firefox. But something about this pathway just doesn’t sit right with me. Other people should be able to participate through such a pipeline, but the process I could surgically create for myself definitely wouldn’t scale. Is there a more Mozilla way to do this that paves a viable path for others to follow?

There are many parts of Mozilla that face challenges like this where by increasing volunteer participation, staff would be stuck with the crippling administrative burden of processes meant to drive innovation. What’s needed is trailblazing participation infrastructure that empowers volunteers to largely self-administer their participation while at the same time transforming how Mozilla staff gets work done day to day. An integration of new processes and tooling that unlocks creative possibilities for volunteers and staff alike.

At the recent Mozilla Whistler Work Week, Mark Surman surreally illustrated the need for new tools by first coming on stage with an axe, and then later bringing a chainsaw on the stage. (Or at least, that’s what I think happened.. I was following #mozwww on Twitter and it basically looked like pure insanity. Never change, Mozilla.) To use Surman’s metaphor, the surgical process I described above is an axe I could build to personally accomplish my mission at Mozilla. (And no one should ever do surgery with an axe.)

For the past few weeks, I’ve been collaborating with Jonathan Wilde to build an experimental chainsaw!

Since the #Mozlandia work week last December, Jonathan and I have been talking about how the browser.html project could be used for more than just platform level research, but to bootstrap participation infrastructure that enables research and development in browser UX. A little over a month ago we began work on just that, and refer to it using the codename ‘Gossamer’. You can read more about the technical inspirations and details behind Gossamer on Jonathan’s blog.

We’re not quite ready to share a demo just yet, but we have enough momentum that we want to begin working in the open. We’re also trying to work via Heartbeat-style sprints pioneered by MoFo and recently adopted by the Participation Team.

We’d love your feedback as we work towards our first few rounds of demos! Join us on the irc.mozilla.org channel #gossamer, file some github issues located in the gossamer repo, and tweet at us via @CaptainCalliope and @hellojwilde!

Mozilla-wide Open Badge Systems and the Learning Organization

With an increasingly ambitious tech roadmap in motion, Mozilla has spent the past two years or so scaling up its organization with hundreds of new employees. As an organization that has traditionally been volunteer driven, this growth doesn’t come without growing pains. I’m not going to pick apart the theoretical nor specific challenges that come with this growth, but I will point out that for an organization as important as Mozilla, staying at the cutting edge of innovation requires perpetual change.

It is therefore imperative that Mozilla grow into an even greater ‘learning organization‘ than it has ever been.

In The Fifth Discipline, author Peter Senge identifies five characteristics of learning organizations that he describes as disciplines: personal mastery, mental models, shared vision, team learning, and system’s thinking.

If you’re unfamiliar with these concepts, the two Wikipedia links above provide pretty good overviews of the whole framework. I recommend reviewing them before continuing. (Protip: The second link is shorter!)

In a few mere days, the Mozilla Summit 2013 will be upon us. Many discussions will be had about Mozilla’s future, and I would like to share my thoughts on the central role Open Badges could play in it.

While the majority of the work thus far around badge system design has been geared toward personal learning, I believe the truly transformative potential of Open Badges will be unlocked when tools and best practices are established for organizational badge system design. In the future I’d like to discuss how this might play out in academia and civic society, but today I will focus specifically on Mozilla as ground zero (patient zero?) for the 21st century learning organization.

Here’s a breakdown of how I see Open Badge system design relating to each of Peter Senge’s five disciplines within the context of Mozilla. All quotes come from the Wikipedia article on the ‘learning organization’ linked above.

Personal mastery

“The commitment by an individual to the process of learning”

Right off the bat, Open Badges comes in strong as a system built around individual learners!

“Research shows that most learning in the workplace is incidental, rather than the product of formal training, therefore it is important to develop a culture where personal mastery is practiced in daily life. A learning organization has been described as the sum of individual learning, but there must be mechanisms for individual learning to be transferred into organizational learning.”

There are far too many organizations that don’t invest in the personal growth of their people. Organizations can use badges as a building block in building an internal culture of personal mastery by offering meaningful badges with pathways toward increasing personal agency. I think Mozilla is off to a great start here with fantastic teams prepared to deliver on this very promise!

Mental models

“The assumptions held by individuals and organizations are called mental models. To become a learning organization, these models must be challenged.”

This is where things start to get meta. I believe the process of creating badge systems within the context of an organization can help reveal hidden assumptions. Doing so might also help to entrench them, which would make the application of badges a double edged sword that amplifies both good and bad organizational habits. To mitigate such effects, internal badge systems should always be under review. New analytics tools can be built to facilitate these processes.. but even more important is keeping the community discussion going.

At this point, you might begin to suspect that organizational badge system design is not just a facilitated process, but a process of facilitation. Powerful stuff.

Shared vision

As a mission driven organization, this is where Mozilla shines. As an organization driving change within a rapid industry that actively drives some of the most unprecedentedly rapid change in the history of our civilization.. it’s easy to see how our shared vision might become misaligned from time to time. That’s ok! This provides opportunity for Mozilla to lead by example!

Shared vision (or lack thereof) informs mental models, and should therefore inform badge system design. Whereas there has (and continues to be) tons of awesome conversation around new processes for aligning badge systems to new or existing learning standards, alignment of badge systems to shared vision is a whole ‘nother level!

If there is one question for Open Badging Mozillians to take away from this post, it’s this: What are the processes we need to put in place to ensure our internal badge systems align with our shared vision?

That is of course assuming we do have shared vision. If we do not, this project could get a bit messy. And that’s a good thing! If our organization is misaligned, badges may serve as an indicator. A validation test of sorts for non-software processes within the organization.

Keep in mind that many of our internal badges can (and should!) also align with external learning standards. As badge ecosystems pick up in number and sophistication, we want to adopt badges internally that our community can meaningfully use in contexts outside of Mozilla.

I propose a rule of thumb: When possible, individual badges should always align as closely as possible with external learning standards, while badge pathways should be optimized for alignment with shared vision.

Team learning

“The accumulation of individual learning constitutes Team learning. The benefit of team or shared learning is that staff grow more quickly and the problem solving capacity of the organization is improved through better access to knowledge and expertise. Learning organizations have structures that facilitate team learning with features such as boundary crossing and openness. Team learning requires individuals to engage in dialogue and discussion; therefore team members must develop open communication, shared meaning, and shared understanding. Learning organizations typically have excellent knowledge management structures, allowing creation, acquisition, dissemination, and implementation of this knowledge in the organization.”

Another of Mozilla’s historical strengths! Now that staff is growing by near an order of magnitude, Mozilla’s larger community of volunteer contributors should theoretically be able scale up in kind. Open Badges have a clear role to play here in onboarding new contributors as well as new leadership development.

I propose that badge system work shouldn’t be the responsibility of a single group, but of the whole organization. While Open Badges inherently facilitates mentor relationships, it can also facilitate documentation processes as a form of documentation itself. Over time, badge pathways accumulate data that represents institutional memory. In the same way it should be everyone’s responsibility to maintain the organization’s documentation (and therefore history), it should be everyone’s responsibility to maintain badge pathways relevant to their ever-changing roles so others can either follow in their paths or deliberately tread new paths of achievement. Learning at every level of the organization thus becomes a tapestry of interwoven stories of birth and renewal that can be tangibly referenced.

Most importantly, defining badge pathways within the context of a learning organization is a governance activity. As the discussion around Mozilla’s governance processes evolves, I predict badge pathways will become central. This reason, more than any other, is why everyone involved with Mozilla (and especially staff!) should be perpetually involved in the evolution of organizational badge systems.

System’s thinking

“This is a conceptual framework that allows people to study businesses as bounded objects. Learning organizations use this method of thinking when assessing their company and have information systems that measure the performance of the organization as a whole and of its various components.”

System thinking is Peter Senge’s proverbial ‘fifth discipline’. As a mission driven organization, Mozilla’s success is often defined by non-quantitative measures. By applying badge systems and building tools to manage and analyze badge pathways, Mozilla will gain an unprecedented toolkit for transparent understanding of the organization as a whole.

Conclusion

General takeaways to consider!

  • The act of designing badge systems can help bring humanity to organizations!
  • Internal badge system design is not just a facilitated process, but a potentially core process of facilitation.
  • Badge system design is an act of organizational alignment around interlinked activities. Everyone should be involved.
  • Alignment of badge systems should happen along two dimensions: alignment with learning standards that benefit the individual, and alignment with shared vision that benefits the whole.
  • Badges and badge pathways can be a form of process documentation that accumulates data which forms a transparent landscape from which institutional memory can be engaged.
  • Badge systems stewardship is an act of organizational governance. Everyone should be involved.

I think Open Badges can play a major role in building 21st century learning organizations and Mozilla is well situated to break ground making this possible.

More importantly, Mozilla is in a critical transitional period with many challenges that I believe Open Badges, as a tool applied within larger facilitation processes, can help navigate. The concept of badge pathways may provide a framework for systemic alignment of personal, organizational, and technical roadmaps.