Mozillians.org Profile Edit refresh

Since the start of this year, Participation Infrastructure team has a renewed focus on making mozillians.org a modern community directory to meet Mozilla’s growing needs. This will not be an one-time effort. We need to invest technically and programmatically in order to deliver a first-class product that will be the foundation for identity management across the Mozilla ecosystem.

Mozillians.org is full of functionality as it is today, but is paying the debt of being developed by 5 different teams over the past 5 years. We started simple this time. Updated all core technology pieces, did privacy and security reviews, and started the process of consolidating and modernizing many of the things we do in the site.

Our first target was Profile Edit. We chose it due to relatively self-contained nature of it, and cause many people were not happy with the current UX. After research of existing tools and applying latest best practices, we designed, coded and deployed a new profile edit interface (which by the way is renamed to Settings now) that we are happy to deliver to all Mozillians.

new-profileHave a look for yourself and don’t miss the chance to update your profile while you do it!

Nikos (on the front-end), Tasos and Nemo (on the back-end) worked hard to deliver this in a speedy manner (as they are used to), and the end result is a testament to what is coming next on Mozillians.org.

Our next target? Groups. Currently it is obscure and unclear what all those settings in groups are, what is the functionality and how teams within Mozilla will be using it. We will be tackling this soon. After that, search and stats will be our attention, in an ongoing effort to fortify mozillians.org functionality. Stay tuned, and as always feel free to file bugs and contribute in the process.

KPI Dashboard on reps.mozilla.org

Mozilla Reps as a program is full of activities. Reps around the world, do extraordinary  things everyday, promoting Mozilla’s mission and getting new contributors on board.

Moving forward, trying to identify how those activities align with top-tier initiatives, Mozilla Reps program wanted a way to visualize some Key Progress Indicators around the program.

We (the Participation Infrastructure team) sat down with the programmatic owners of Reps (Nuke & Rosana) and identified what numbers and metrics we would like to expose in a much more digestible way, so we can assess the progress of the program on many levels.

We identified 3 different KPIs:

  • Number of Reps (and growth rates)
  • Number of Events (and growth rates)
  • Number of Reports (and growth rates)

… and also 3 different filters you can apply on those numbers:

  • Country
  • Functional Area (of Mozilla)
  • Initiative (associated with Rep, Event or Report)

You can find the spec for this initial iteration here.

We decided to have the filters as drop-downs, applied on the whole page (in combination or one-by-one). Then for each KPI group we would have a time graph for the past 6 weeks (fixed for now) with a HUD of basic numbers and growth rates.

Screenshot from 2015-04-24 13:39:29Technology-wise, we tied the coding of this new dashboard to the delivery of a proper API for the Reps Portal (more info on that soon). The new API enabled us to easily create custom endpoints to calculate the numbers needed for our Reps KPI graphs (based on the existing Conversion Points). Nemo and Tasos did a fantastic work to deliver the new API and the custom endpoints, while making sure that this is not heavy on our DB.

Nikos then worked on the front-end using D3.js as the visualization library to create the graphs dynamically (each time you access the page or you filter using Country, Area or Initiative).

Screenshot from 2015-04-24 13:37:05The overall result is smooth and easily helps you assess progress of various Areas and Initiatives on specific Countries, for Reps, Events and Reports.

You can check out the dashboard here.

Next step would be to introduce a time-slider for customizing the time range you want to be displayed.

Multiple emails on mozillians.org

tl;dr version: You can now associate multiple emails to your mozillians.org profile

Background

Since the start, users of mozillians.org were able to associate only one email per profile. This was used both as email displayed on your profile (depending on your privacy settings) but most importantly as the email used to login using Persona.

Rationale

Most of us own and use multiple emails everyday. Personal, business, alias and any combo in between. Even within various Mozilla properties people have associated different profiles with different emails (eg. SuMo account vs. Bugzilla email). Although we need to recognize and respect the will of some people to use different emails as different (separate) online personas, we also need to find ways to make identity management and consolidation easier for people that choose to use multiple emails, under the same name.
Being able to associate multiple emails under one mozillians.org profile, presents us with really interesting advantages. For once, you can login on websites that check for your mozillians.org account using any email associated with your Persona account. Also other mozillians would be able to look you up using any of your emails. Finally, from a metrics standpoint we will be able to effectively deduplicate accounts and metrics/statistics across different systems of Mozilla.

Implementation

  • Main email is being used for communication with mozillians in Mozillians.org
  • Alternate emails are mostly being used for identity deduplication
  • API v2 exposes alternate emails

What should I do?

  • Login to mozillians.org
  • Click “Edit your profile”
  • Click “Edit E-mail addresses”
There we provide all the functionality to manage your profile’s emails.
  • Add/delete alternate email address
  • Change your primary email address
  • Manage email visibility

Multiple Accounts?

We dont expect many people to have multiple profiles in mozillians.org. We cannot know for sure, only anecdotally. People with multiple accounts should contact us ( #commtools on IRC or open a bug here) for help merging, or they can choose to use one of them and delete the others.

What is next?

Mozillians.org dev team is working tirelessly on new features and enhancements that would make mozillians.org even easier to use and more robust as a source of truth about all things mozillians. You can check our our roadmap here, follow our development and contribute on github and join our discussions here.

FOSDEM 2015 Bug sprint tool

“Reclama” Experiment report

Intro

FOSDEM 2015 is a premier open source developers’ event in Europe. Mozilla is heavily participating in the event for over 10 years now, with booths and dev-rooms. This year the Community Development team decided to run an experimental approach on recruiting new contributors by promoting good-first bugs.

Scope

Given the highly technical nature of the audience in FOSDEM 2015, the approach decided has a straight-forward promotion of bugs and prizes for them, for people to track and get involved.

Following sign-off meeting with the stakeholders (William Quiviger, Francisco Piccolini and Brian King) the specifications agreed for the first iteration of the experiment were as follows:

  1. A straight-forward interface displaying hand-selected good first bugs, ready to be worked on
  2. Next to bugs, prizes should be displayed.
  3. Viewing from mobile devices should be also accounted for.
  4. Public access to all content. Ability to edit and add events on selected accounts (hardcoded for v1)
  5. The interface has to be properly Mozilla branded (high visibility and promotion in an event)
  6. It needs to be future-proof for event to come (easily add new events and/or bugs after deployment)
  7. Solution URL should be short and easily memorable and digestible.
  8. It needs to be delivered before the start of FOSDEM 2015 😉
  9. A report should be compiled with usage statistics and impact analysis for the experiment

Development

Given the extremely short timeframe (less than 3 days), ready, quick or off-the-shelf solutions were evaluated like:

  • An online spreadsheet (gdocs)
    • Not meeting requirements #3, #5, #6, #7
  • A bugzilla query
    • Not meeting requirements #2, #7, #6
  • A scrappy HTML plain coded solution
    • Not meeting requirements #4, #6

Thus, given the expertise of the group it was decided to create a django application to meet all requirements in time.

Following 2 days of non-stop development (fantastic work from Nikos and Nemo!), testing and iteration we met all requirements by developing the app which is codenamed “reclama” (Italian -shortof-  for claim).

Code can be found here: https://github.com/mozilla/reclama

Screen Shot 2015-02-27 at 14.57.26Deployment

In order to meet requirement #7 (short and memorable URL) and given the timeframe, we decided to acquire a URL quickly ( mozbugsprints.org ) and deploy the application.

For usage statistics, awstats was deployed on top of the app to track incoming traffic.

Usage statistics

During the weekend of FOSDEM 2015, 500 people with almost 5000 hits visited the website. That’s almost 10% of the event participants.mozbugsprint-stats

Saturday 31-Jan-2015 traffic analysis

mozbugsprint-saturdayBooths and promotion of the experiment started at 9:00 as expected. With mid-day (noon) pick which is consistent with increased traffic in booths area of the event.

Traffic continues to flow in steadily even after the end of the event, which indicates that people keep the URL and interact with our experiment substantial time after the face to face interaction with our booth. Browsing continues through the night, and help might be needed (on call people/mentors ?) during that too.

Sunday 1-Feb-2015 traffic analysis

mozbugsprint-sundaySecond day in FOSDEM 2015 included a Mozilla dedicated dev-room. The assumption that promotion through the dev-room would increase the traffic in our experiment proved to be false, as the traffic continued on the same levels for day 2.
As expected there was a sharp cut-off after 16:00 (when the final keynote starts) and also people seem to not come back after the event. Thus the importance of hyper-specific event-focused (and branded) challenge seems to be high, as people relate to that understanding the one-off nature of it.

Impact

32 coding bugs from different product areas were presented to people. 9 of them were edited (assigned, commented, worked on) during or immediately (one day) after FOSDEM 2015. Out of those 9 , 4 ended up on first patch submission (new contributors) and 3 received no response (blocked contributor) from mozilla staff (or core contributors).

Recommendations

  • Re-do experiment in a different cultural environment, but still with related audience, so we can cross-compare.
  • Continue the experiment by implementing new functionality as suggested by the stakeholders (notes, descriptions etc).
  • Experiment random sorting of bugs, as current order seemed to affect what has been worked on.
  • Submission of bugs to be featured on an event should be coordinated by event owner and related to event theme and topics.
  • A/B test how prize allocation affects what bugs are worked on.
  • Expand promotional opportunities throughout the event. (booth ideas?)
  • On call developers on promoted bugs would eliminate the non-answered section of our bugs

PS. Special thanks to Elio for crafting an excellent visual identity and logo once again!