Connecting Baloo with areweamillionyet.org

It was only a matter of time to connect the dots. As we saw in a previous post, we have been working with Adam Lofting on publishing a public dashboard for contribution activity metrics. The data we had were based on one-off exports from Github for demo purposes. The intention was to feed the dashboard with data from Baloo, our single source of truth about contribution activity in Mozilla.

Thanks to the hard work of Sheeri Carbal, Anurag Phadke and community builders on various contribution areas across Mozilla, this connection is now live.areweamillion_balooNavigating to areweamillionyet.org you can see the total counts of Active Contributors in Mozilla with drill-downs to specific teams and systems.

The data flow can be briefly described as this: Databases for integrated systems (Github, Bugzilla, SuMo for now) are scrapped for activity info based on our Schema, resulting in a formatted database full of raw contribution data. Then we apply aggregations per system and per area as defined by Community Builders in our Conversion Points tables to create active contributor counts while de-duplicating them across projects. Aggregations are then exported and captured by a nodejs app feeding info to our public dashboard.

More systems are in the pipeline to be integrated (Reps, MDN, Location Services and others) really soon. You can track the progress (and request integrations) through the Baloo wiki page.

Mozilla Location Services – A story of intentionality and growth

Since the start of this year I joined the Community Building team with a task (among others) to abstract community building best practices and apply them to teams that haven’t had any dedicated community building resource, forming a strategy around community with them.

Over 7 months ago the Services team of Mozilla announced a new project. The Mozilla Location Service (MLS for short). Given the priority of the project, community excitement and my passion about geo-related projects I was assigned as a community builder in a supportive function.

Since it started, over 4 thousand people have been contributing to the project. What is interesting about this contribution activity is that although engagement of potential contributors was relatively low, and the call to action was not widely advertised, the influx of people was steady and global. Though we can speculate in general about the source those contributions, we can also safely say that the vision behind the project and the low barrier to entry contributed a lot towards this influx of people.

As the months went by, location services team wanted to understand better the contribution that was happening, assess it, and act based on a community building strategy. The immediate need was the definition of a contribution path. Given the structure of the program that was fairly straightforward. A contributor downloads MozStumbler, installs it and then starts walking around. The next step for a contributor would be to opt-in for a nickname associated to his/her contributions so that he/she participate on the leaderboard and for us to have more meaningful contribution activity data. Articulating a pathway also helps on identifying bottlenecks and the overall health of the community, and we are now in the process of defining the active contribution thresholds.

At that point onwards, the question that was raised within our community building meetings for MLS was around the “intentionality” of the community building. It is one thing to have a program open for contributions and a totally different one to facilitate and encourage contributions, assessing the community health in parallel. The shift towards intentionality for community building, requires a significant resource commitment that any team within an organization would naturally be reluctant to make. As a supportive community builder I proposed a community building pilot approach to evaluate the community engagement and contribution possibilities.

Quoting Erin Lancaster, one of the key drivers of this effort:

A community builder is essential in order to connect the technical team directly to the very people who care enough about the project in order to devote their free time to helping us out. [A community builder is] also key to ensuring that the community is empowered with the details so they can hit the ground running and contribute while being able to distill information back to the dev team.

Our fantastic community in India was selected as the host for the first pilot. For our first event we would try to get people together for a stumbling-party in Bangalore and assess the contribution rates, spikes and ripples that the event would create, against our investment towards the event. Deb, Vineel and Galaxy, our awesome local leaders organized the event and by tweaking existing event-in-a-box templates from older Mozilla projects and using Mozilla Reps for supporting the event set the date for 26th of April.

14167122357_37c2ff0e53_bThe event was really successful. 30 people showed up and started stumbling and the local team made some slight twists on the event structure to facilitate better community engagement. (extended stumbling period, assigned areas for stumbling etc). What was really important for our pilot was to evaluate the contribution activity that we got from this small scale, low on resource event, and the result was stunning. We saw a 10x spike in our contribution rates in India for the following 2 weeks, and once the spike was over we were already 3x from the rates before the event (contribution activity ripples).hanno_data_2There were some concrete learnings from our first pilot, especially regarding the format, structure and communications needed before and after the event. In order to fortify our learnings and fine-tune the event format (for larger scale implementation) we decided to run a second pilot in three Indian cities (8th of June) in parallel with the same core team. Our first pilot clearly showcased the value of community contributions in MLS and based on the combined results of those two events we will be forming a community building growth strategy for MLS team transitioning towards a fully intentional approach.

All this would not be possible without the help of the fantastic people in MLS team (Vishy Krishnamoorthy, Erin Lancaster, Asa Dotzler, Richard Barnes, Hanno Schlichting, Ravikumar Dandu, Doug Turner) that have been really supportive since the early discussions around MLS community. A huge thanks, to all of you and onwards we go!

Contribution Activity Metrics – Early attempts and fails

As we examined with the intro post, the need for contribution activity metrics for different contribution areas in Mozilla has been high. It was only logical that many attempts were made to address this issue, mainly on the area-level (and not in Mozilla-wide level). Almost all of them had zero interaction between each other, and there was a general lack of vision for an holistic approach to the problem.

After one of our initial gatherings as the (then meta-) Community Building Team, a couple of people brainstormed together a possible solution to our problem. Together with Josh Matthews, Giorgos Logiotatidis, Ricky Rosario and Liz Henry a new approach was born. Enter project Blackhole!

Project Blackhole was a collaborative effort to develop and maintain an infrastructure of gathering and serving raw contribution data within Mozilla. We created a data architecture and flow together with a data Schema and specification to describe contribution activities for the first time in Mozilla. The project went far enough (thanks to Josh) to create a working prototype for back-end and front-end.

What went right:

Having a single project to drive multiple metrics efforts forward got people engaged. Everyone saw the value of de-duplicating efforts and tapping into that as a resource. Also during the process of designing and testing it we were able to self-identify as a group of people that share interest and commitment towards a common goal. Most of those people went on to become active members of the Systems and Data Working Group. Finally, we ended up with a common language and descriptions around contribution activities, a really valuable asset to have for the future of cross-project tracking.

What went wrong:

Building *anything* from scratch can be hard. Really hard. First, everyone (rightfully) questions the need to build something instead of re-using what is out there. Once you get everyone on board, development and deployment resources are hard to find especially on a short notice. On top of that Blackhole’s architecture *seemed* logical enough in theory, but was never tested in scale so everyone involved was not 100% sure that our architecture would survive stress tests and the scale of Mozilla’s contribution ecosystem.

PRO TIP: Changing the project name does not help. We went from “Blackhole” to “Wormhole” (and back to “Blackhole”?), to better reflect the proposed data flow (data would not disappear forever!) and people got confused. Really confused. Which is obviously something that is not helpful during conversations. Pick a name, and stick to it!

Lack of a team dedicated to it and inability to get the project listed as a personal goal of people (or teams), halted any progress leading us to a fearsome dead-end.

What we learned:

As with most failures, this one was also really valuable. We learned that:

  • we need to be a top line goal for people and teams
  • we need to examine really well what is out there (internally or externally to Mozilla) and investigate the possibility of re-using it.
  • we need a clear and common language to make communications as effective as possible
  • we need to be inclusive in all our procedures as a working group, with volunteers as well as all paid staff.
  • and in true Mozilla fashion: we need to start small, test and iterate with a focus on modularity.

A way forward?

Having those lessons learned from the process, we sat down last December as a group and re-aligned. We addressed all 5 issues and now we are ready to move forward. And the name of it? Baloo. Stay tuned for more info on our next detailed post :)

 

Tracking features of FirefoxOS

FirefoxOS grew quickly to be a super active project under constant global development by hundreds of people around the world (employees and volunteers in Mozilla). Over the past two years we developed a fully fledged open source mobile operating system based on web technologies. Naturally the least thing you could do as a Mozilla contributor is to try to keep track of what is happening, and arguably this has been really difficult from the start.

On one hand this is understandable. The pace the project is moving is lighting-fast, with requirements and dates changing constantly. On top of that, our partnership with companies of the industry (OEMs, OBs, chipset manufacturers etc) has made the tracking of things even more complex.

On the other hand, the successful end result (and engagement of new people) is a hint (or a proof?) that there might be a way to track things for us mere mortals. With this post I will try to describe the discovery and tracking procedure I am using to keep myself engaged and updated about FirefoxOS. The info I am looking for are one or all of those: dates, owners, projected ETA, code, specs, mockups.

Disclaimer: This is by no means an official guide to feature-tracking but rather a documentation of my personal experience and definitely tailored to my tracking needs. Hopefully this can be proven useful to other people and I will get some suggestions in comments, so comment away!

Let’s start with the basics. Bugzilla is your central source of information about everything happening in Mozilla-verse. But we will need more than that to be successful. We need to be able to understand how things are tracked within Bugzilla. My focus has been Gaia (as the most FxOS-unique part of FxOS stack) so let’s say for the sake of this guide that we are looking for more info on a Gaia feature. (e.g. Custom ringtones)

Our first stop is Gaia wiki. Wiki.mozilla.org is used for all high-level tracking of FxOS features (and pretty much for all other Mozilla projects too)

gaia_wiki

Navigate through the page and you can find all different major areas of Gaia (Apps, System and their sub-parts) Once you locate the section that your feature is under (in our case System>Sound) click through to land in the wikipage specific to the area of the project. Although the Gaia (and generally FxOS) team has done a fantastic job of updating the wiki with status of features and roadmap you might end up in a not-so-helpful wiki page (like in our example).

Stepping back a bit, our goal is to find more info about a feature. For every feature you might think of there are three different scenarios:

Scenario 1: Feature is a planned, detailed and committed one.
If the feature is something that the Gaia team is committed to deliver (approved in meetings) then one of the following can happen:

  • The easiest case is that all the info you need is on the wikipage we just explained how to find. Boom you are done!
  • A slightly trickier case is that the info is not yet on the wiki so you need to search bugzilla for it. Before you do that make sure to check out the UX specs making sure that your feature is part of the committed ones. (Bonus: get lost in the fantastic work that UX team has done!) Searching bugzilla you should use “Advanced Search” with “Boot2Gecko” as the Product and make sure you search for both NEW-ASSIGNED(generally open) *and* RESOLVED status. FxOS team is delivering like crazy and your feature might be already delivered! You can easily identify the “official” commited bugs by their title ([User Story] something_here) and/or their priority/severity (P1/blocking etc)

Once you find the bug you are looking for you can get all the info you want or cc your self to get more info as they come (m0Ar bugmail please!)

Scenario 2: Feature is a proposed one.
In this scenario the feature is something already proposed by someone and there is an active (or not!) discussion around it. Bugzilla is your only help here. Follow the instructions above on Bugzilla search. Most of those bugs will be UNCONFIRMED or NEW (definitely not ASSIGNED and hardly RESOLVED as INVALID or WONTFIX) so tweak the bugzilla search accordingly. Make sure to be constructively involved in the discussion around the feature (based on your expertise) so you can make sure that your lovely FxOS device will soon have your killer feature!

Scenario 3: Feature is not even a proposed one. (It’s all in your head!)
You know the story… File a BUG! But wait! Before you go ahead and file a bug, opening the flood-gates of bugmail, make sure to do the following: Check with UX guidelines to see if you missed something. There might be a case that something is already spec’ed out in UX designs but not translated to a bug. In that case ping UX people on IRC channel #gaia for follow-ups. If UX designs prove to be unaware of your awesome idea you might want to have a look at project Haida. Project Haida is the UX project for proposed features and designs for future versions of Gaia.
If everything fails and you are the sole person in the world thinking about this cool feature, you might as well go ahead and file a bug (following bugzilla guidelines and etiquette) under Boot2Gecko Product and the Component that fits your proposed feature category.

Extra channels: As always make sure to drop by Mozilla IRC on #gaia (or #b2g if that’s suitable) and ask for help if you are stuck. Mozillians there as *awesome* and super responsive.

Hopefully this over-view of my workflow as a non-member of FxOS team will be useful to some other Mozillians out there :) Please go ahead and comment with ideas and enhancements (or corrections!) of the process. Special thanks to Fredy for his countless hours standing by me navigating through FxOS code, and asuth for his responsiveness on any Gaia related questions we had :)

1000 events and counting…

When we embarked on our journey with Mozilla Reps almost two years ago we knew that the Mozilla Community was a vibrant and energetic ecosystem of contributors, full of activities and events. We set ourselves the goal to further empower the community, to help Reps grow their local communities, to raise visibility of activities and to document their achievements thoroughly.
 

Last week we hit an important milestone. On 14th of April 2013 we hit the 1,000 mark.  One thousand events that Mozilla Reps organized or have participated in more than 80 countries.

 

The increasing amount of Firefox OS related events organized by Reps in recent months  reflects the incredible momentum that the project is gaining. Reps are ready to play a critical role in our launch markets later this year, actively raising awareness about the project and inspiring new contributors to get involved.

Some “damned lies” for all the statistic lovers out there:

Total events: 1154

Rate of events so far: 1.93 events per day

Rate of events last 3 months: 3.18 events per day

Total Reps: 407

Special thanks to the previous and current council members for all their hard day to day work on the program, and their visionary inputs for the ways forward.

Onwards we go, Jedis!

Leading

 

photo credits: ashish0105, bobreyes, deimidis

Sweet new functionality in reps.mozilla.org

Over the past 4 weeks, the Mozilla Reps Web Development team has been
focused on delivering new discoverability features to enhance our
portal. Last night we landed what we believe to be the most awesome
version of Mozilla Reps portal ever!New features include:New timeline vizualization of events
Having a map to visualize all our events and better document and
manage our events throughout Mozilla was a breakthrough 6 months ago,
on how we . But we wanted to take it one step further. We envisioned
and implemented a timeline visualization for events that works with
our search bar in events. You can now visually identify and scroll
through community events worldwide and through different time periods
(!)


Vouched mozillians login
In true spirit of pioneering the integration between Mozilla services,
you now have the ability to login into our portal if you are a vouched
Mozillian (with persona) even if you are not a Rep! You can then
customize a dashboard based on the interest areas of Mozilla you want
to track, and get activities and metrics from Reps that are working on
those areas.

This new functionality raises the awareness around the countless
activities that Reps are driving across all functional areas and
delivers easy discoverability of Reps working on those areas, so that
you can communicate with them. As always we already have in the
pipeline the enhancement of functionalities around this new feature,
like email abilities, unification of dashboards between Mozillians and
Reps and other cool new dashboard functionalities.

and many more features…
..including the ability to email all participants of an event via a
mail modal in event pages, ability to extract people info and emails
if logged in the site in /people page, ability to search in events
based on date range and enhancing the email notification
functionalities.

As those lines are written our web developers together with our webdev
volunteers are working on a Voting system and new commenting system
and categories for events. You can find all about what is in the works
in our current dev sprint.

Special thanks to our devs Tasos and Nemo, our code reviewer Giorgos,
our production manager Ben and all the Reps for the countless
countinous feedback and improvement pointers.

Updates on reps.mozilla.org – Mails please!

Over the past 6 weeks reps.mozilla.org went under a new development sprint!

I would like to take this opportunity and welcome our two new webdevs Tasos Katsoulas and Yiannis “Nemo”Giannelos both django-ninjas at day and beer lovers at night! An obvious fit to our team they worked tirelessly on imporving the functionality of the portal and adding new features. In particular:

Mailing enhancements

  • Implementing a new ‘Settings’ page for opting in and out mailing features (bug 818036)
  • Send an email to the owner of a report after each comment (bug 758603)
  • Enhancements in “mail my mentees” form (bug 763490)
  • Send email to mentor when a mentee files a new report (bug 762418)
  • Monthly reminder for new reps to mentors list (bug 774247)

The new mailing features will enable Reps to communicate more efficiently among their activities and streamline the reporting procedure more. Over the past 1.5 years Mozilla Reps have filled over 3000 reports! Feel free to browse through reps and check out their reports and activities!

Other features included:

  • Custom planning pad urls for events (bug 794008)
  • iCalendar export for single event (bug 761544)
  • Show rep of the month on their profile page (bug 784281)

And also some regular Bugfixes:

  • CSV export is now working fully(bug 815766)
  • Date reset when event save fails is fixed(bug 778865)
  • Fix duplicate results in API queries on “People” page (bug 824892)
  • General housekeeping and many minor improvements.

For our next 3 week sprint we will be working on adding cool new features on our portal with a focus on discoverability and vizualization! Timeline vizualization of the events, communication to event attendees, ability to login to our portal given a vouched mozillians.org account, are just some of the
things to come.

As always you can leave feedback in our etherpad, or subscribe to our reps-webdev list to help us out!

Special thanks to our tireless web productions manager Ben Sternthal and our new QA person, Ioana Chiorean (our well known Romanian Reps Mentor) :)

Onwards we go!

More metrics on events please!

On our year-long journey to deploy the Mozilla Reps program we have always been fascinated and driven by metrics.

Mozilla Reps have already organized over 700 events around the world and the current rate is 2.1 events per day (!). We need better ways to capture the momentum analyze it and evaluate the huge impact those events have.

One of the main focuses of Mozilla Reps is to get new contributors in Mozilla. The central way to do that is to get people to signup in http://mozilla.org/contribute/ page (which is now localizable!). So we needed a way to tell how many signups happened as a direct result of an event.

Giorgos Logiotatids (our webdev) worked closely with the awesome Bedrock team to deliver a Signup Counter for each event. This is how it works:

- Once a Rep is in an event, she logs in to our portal and goes to the event page.
- By clicking on the “Get Involved” button bottom right she gets a unique URL (per event) for the “Get Involved” page.
- She uses this page (or the link to it) to get people to sign up for
contributor opportunities in Mozilla.
- Once someone signs up, the counter next to the button will increase by one!
- By the end of the event we can see how many sign ups the event had :)

Moving forward we have plans to integrate more metrics around the signups like: How many people actually ended up being contributors, signups per region or functional area, total signups per Rep, signups Frequency (per type of events) etc..

Finally, special thanks to David Boswell and all the functional owners of the “Get Involved” page, for their fantastic long time effort to engage with new contributors and get them involved daily.

ps. We are working on a way for all Mozillians to log in our portal and have access to those metrics. Stay tuned! In the meantime check all our upcoming events :)

 

Mozilla Reps Documentation Sprint this weekend!

This weekend (in 2 days!) Mozilla Reps will be running a documentation sprint in a collaborative effort to make our Documents and SOPs even better!
We need your documentation, writing, wiki-ninja skills for 3 days starting this Friday 25th Nov till Sunday 27th Nov.

You don’t have to be a master in documentation, devote 3 full days or even be a Rep to join us.

We will be coordinating our efforts in #remo IRC channel and in this EtherPad
Finishing and polishing some SOPs will be our primary focus (more info on the EtherPad). We will make sure to have people on IRC all the time to coordinate efforts and we are expected to hold some calls and IRC chats.

If you plan on joining us, please write your name on the Etherpad and drop by IRC to discuss on what we should focus those 3 days!
We will shortly announce a kick-off 3 hours long call/meeting for Friday (afternoon for GMT)

Let’s write and shine!

OMG! Lets document!

"OMG! Let's document!"

ps. We will have gifts for all participants :)

How about some Antarctica?

If you have a question stuck in your head, you need to get an answer.

“Which is the place in the world with biggest Firefox share?”

Antarctica!

Antarctica has consistently Firefox share of 80+ % for years now! (Based on all stat/market share agencies that I could dig into). This could come as a surprise to some people, but think about it! It is totally logical. Antarctica is packed with scientists/pioneers/engineers/brilliant minds that can settle for nothing less that bleeding edge technology, and this is Firefox!

Now how about leveraging this power and recognizing this fact? How about a Mozilla Antarctica Community?

Let’s kick this off! Over the next weeks David Boswell, Robert Nyman, Anthony Ricaud and me will reach out to those people, establishing a community where no browser has gone before.