software – Adam Lofting

Working on CRM

I’m writing a couple of blog posts today. This first is a belated note about my work on CRM for MoFo, and how I ended up doing this.

Slides from my presentation to MoFo on our All Staff call in June.

In the second quarter of the year, my Metrics work was pretty quiet while we were prototyping the new Webmaker Android App, and the Learning Networks team was in planning mode for Mozilla Clubs. There was some strategic work to do, but at this stage in the product life-cycle, data-driven decision making isn’t a useful tool. I never actually ran out of things to do, but was keen to spend my time on things that had the most impact.

So I was looking around for projects to help with. Talking to David Ascher, I explained that the projects that engaged me most were the complex ones that combined the needs and views of many different teams. This was also a moment of realisation for me that this was true of every job I’ve held. I like connecting things, including differing points of view.

The MoFo CRM project has been on the table(s) for a while now, but it never gained momentum for legitimate organisational reasons. All our teams needed some form of CRM, but even those with the biggest requirements didn’t have spare capacity to supply CRM tools to the rest of the teams. The more a team tried to coordinate with others, the more complex it was to solve for their own use case. It was everyone’s problem, and no-one’s problem.

So my proposal was to have a ‘product manager’ to look after CRM as an internal service to the org; Centralise ownership of the complexity rather than making it everyone’s problem. That way teams can think about the benefits of using the CRM rather than the complexity of building it. And after reviewing the plan with our Ops leadership, I picked up this task.

It’s been a couple of month’s since then, and I’ve had hundreds of hours of conversations with people across Mozilla about CRM. The project is living up to my request of ‘complex’, but I’m also pleased we’ve started doing the work. Although CRM includes more than it’s fair share of ‘Enterprise IT’, we’re keeping our workflow inline with the agile methods we apply to our own products and projects.

But it’s a difficult project to track, with many plates that need to keep spinning. I noticed this most after being offline with my family for two weeks then coming back to work. It took me a few days to get up to speed on each of the CRM pieces. So this week I’ve been working on documentation that’s easier to follow.

The project is now split into seven projects, and the current status of each, and the next steps with links to github issues for tracking and discussion can now all be found in one place. Building on Matt Thomson’s hard work organizing many Mozilla things, I’m using this wiki/etherpad combo as my working doc: CRM Plan of Record.

MoFo Contributor Dashboard(s) – switching to Plan A

tl;dr:

We’re wrapping up work on the MoFo Interim Dashboard
- The only other data source we’ll add is the badge counts for webmaker mentors & hive community members
- This is still our MoFo working document for the time being
Then, we’ll switch our development efforts into integrating with Project Baloo
- Baloo is where we will de-dupe contributors across teams/tools etc.
- areweamillionyet.org will become our working document in time (‘time’ is TBC)

Switching to Plan A

The MoFo contributor dashboard we’ve been working with this year is our *interim* counting solution, and just as we’re “completing” it we’re now in a position to switch from an interim solution to a fully integrated system which is properly integrated with MoCo. This is pretty good timing, but it’s a change in scope for our immediate work so is worth a status update.

Within MoFo we’ve deliberately been working on a Plan B solution. This is a relatively crude, not de-duped, not a single-source-of-truth dashboard, to give us the quickest visibility we could get into contributor trends. But as we’ve noted from the start, this solution keeps in mind Plan A so that we can transition to it when we’re ready.

We started our work with this Plan B because two existing projects were underway that could be our Plan A and we didn’t want to duplicate these efforts and/or sit around idle as we didn’t know for sure when either of these could be used ‘in anger’.

Project Baloo (formerly Wormhole/Blackhole) was the most closely aligned piece of work, but there was also work to issue contributor badges which was another possible place to count the number of people contributing. Both of these projects are complex because they span many teams and systems and the philosophically-quicksand-like question “what counts as contribution?”. So we didn’t know exactly when we could use either of these as our data-store.

As of last week, Baloo is a functioning data-warehouse with working aggregations setup for a number of MoCo teams. Which means we can begin our switch from Plan B to Plan A (or more accurately our *transition* to Plan A, as this will take time).

The dashboard at areweamillionyet.org which was being demo’d with purely github data when we launched it a couple of weeks ago, is now using data from Baloo’s de-duped aggregations across Github, Bugzilla and SUMO activity. For now, the output of this work is sitting in this Google Doc, and graphed with the help of a little node app.

There are many more teams and systems to integrate into Baloo going forward (across MoCo and MoFo), and there’s a fair bit of automation to work out, but this dashboard is a real example of how this can work. This is Plan A in action, and where we can focus our efforts next.

So, for MoFo colleagues, what does this mean in practical terms?:

We should:

Continue using the existing dashboard as our working document
Continue using the adhoc logger for counting contributions that don’t have a record anywhere else

I will limit the open work on the Interim Dashboard to:

Minimal update to the interface
Adding in numbers for Webmaker Mentors and Hive members via badges data
“Won’t-fixing-ing” some bugs where the effort is now better spent on Plan A

I will file bugs and start working on:

Getting raw contribution data into Project Baloo
Documenting the conversion points in a way that’s more consistent with MoCo’s
Joining up the documentation for this with MoCo’s existing info

What I see in these graphs of Github contribution

Context: Last week I shared a few graphs (1, 2, 3, 4) looking at data from our repositories on Github, extracted using this Gitribution app thing, as part of our work to dashboard contributor numbers for the Mozilla Foundation.

I didn’t comment on the graphs at the time because I wanted time for others to look at them without my opinions skewing what they might see. This follow up post is a walk-through of some things I see in the graphs/data.

The real value in looking at data is finding ways to make things better by challenging ourselves, and being honest about what the numbers show, so this will be as much about questions as answers…

Also, publishing this last week flagged up some missing repositories and identified some other members of staff so these graphs are based on the latest version of the data (there was no impact on shapes, but some numbers will be different).

What time of day do people contribute (UTC)?

Our paid staff who are committing code are mostly in US/Canadian timezones and it make sense that most of their commits are during these hours (graphed by UTC). But, what caught my attention here is that the volunteer contribution times follow the same shape.

Questions to ask:

Do volunteer contributions follow the same shape because contributing code has a dependency on being able to talk in real time with staff? For example in IRC. If so, is this a bottleneck for contributing code?
If not, what is creating this shape for volunteer contributors? Perhaps it’s biased to timezones where more people are interested in the things we are building, and potentially biased by language? But looking at support for Maker Party and other activities there is a global audience for our tools.
What does a code contribution pathway look like for people in the 0300-1300UTC times? Is there anything we can do to make things easier or more appealing?

The shape of volunteer contributions

The shape of this graph is pretty typical for any kind of volunteering or activity involving human interactions. It’s close to a power law graph with a long-tail.

If you’ve not looked at a data set like this before, don’t panic that so many people only make a single contribution. At the same time, don’t use the knowledge that this is typical not to ask questions about how we can be better.

Lots of people want to get involved in volunteering projects but often their good intentions don’t align with their actual available free time. I say this as someone who signs up for more things than fit into my available hours for personal projects.

The two questions I want to ask of this graph are:

Where could our efforts to support contributors best influence the overall shape?
What does this look like at 10 x scale?

So, starting with where we could influence shape… my opinion (no data here) says to think about people in this range. Shape Highlight To the left of this highlighted area people are already making code contributions over and above even many staff. Shower them in endless gratitude! But I don’t think they don’t need practical help from us. To the right of this highlighted area is the natural long tail. Supporting that bigger group of people for single-touch interactions is about clear documentation and easy to follow processes. But I think the group of people roughly highlighted in that graph are people we can reach out to. These people potentially have capacity to do more. We should find out what they are interested in, what they want to get out of contribution and build relationships with them. In practical terms, we have finite time to invest in direct relationships with contributors. I think this is an effective place to invest some of that time.

I think the second question is more challenging. What does this look like at 10 x scale?

In 2013, ~50 people made a one-time contribution.

What do we need in place for 500 people to make a one-time code contribution?
Do we have 500 suitable ‘first’ bugs for 2014?
Is the amount of setup work required to contribute to our tools appropriate for people making a single contribution?
If not, is that a blocker to growing contributor numbers?

In 2013, there were ~1,500 code commits by volunteers.

What do we need in place for 15,000 activities on top of planned staff activity?
How does this much activity align towards a common product roadmap?
How is it scheduled, allocated, reviewed and shipped?

When planning to work with 10 x contributor numbers, possibly the biggest shift to consider is the ratio of staff to volunteers:

ContributorRatio

How does impact on time allocated for code reviews?
How do we write bugs?
How we prioritize bugs? Etc.
Even, what does an IRC channel or a dev maling list look like after this change?

What do you think?

I’m only one set of eyes on this, so please challenge my observations and feel free to build on this too.

Also, as the data in here is publicly accessible already I think I can publish this Tableau view as an interactive tool you can play with, but I need to check the terms first.

The immediate value of working in the open

I’m both excited and a tiny bit nervous about how “open” Mozilla are about the way they work.

As I’m getting to know the Foundation, and the projects and priorities, and to make sense of what exactly I’ll be doing here I’ve been reading lots of Etherpads. If you don’t know what an Etherpad is, it’s a bit like a Google Doc (the ‘word doc’ variety) but less slick and more open. If you give someone a link to an Etherpad, the barrier to them contributing to the document is almost non-existent.

Anyway, the value of this open working process somewhat blew my mind today. While lots of these docs have been useful in a general sense, today I read the documents from the initial planning around MoFo metrics that led to recruiting for my role (so it was pretty relevant!). The final document is a fine and very useful thing, like most summary documents, but what was really useful was the option to ‘replay’ the creation of the doc.

As I watched it being outlined, revised and then shared for comment I was able to see many of my new colleagues jump in to add the points they care most about and to challenge and contribute to the rest of the document. Better than just seeing the final document is seeing how it started and where it changed direction and who was involved.

Even watching the hesitations and re-phrasing of particular sentences tells you something about where the subtleties and complications in the process exist.

I probably spent 15-20 minutes watching the replay of the writing of this document, and think I got more indirect information than I would otherwise pick up in even two-weeks of introduction meetings.

There is so much information in the history of that document that would be lost in any closed system. If for example, that document was a PDF on an intranet behind a password, the value I would have gotten from it as a new employee today would have be greatly reduced.

Evening coding

With lots of interesting client work on at the moment, I’ve decided to spend some evening time moving along the next version of Done by When. This is nothing too stressful, but the project is getting really interesting now. I think I’m over the initial conceptual learning curve and now I’m making proper progress.

Where the launch version of Done by When was primarily a working proof of concept, this next version is about attention to detail and responsiveness (that’s the speed of interactions as opposed to the adaptive layout stuff that’s already in place).

I feel like I’m properly upgrading something when I’m spending as much time removing code as I am writing it new.

More updates soon.

For a free and open internet, be quick

“On December 3rd, the world’s governments will meet to update a key treaty of a UN agency called the International Telecommunication Union (ITU). Some governments are proposing to extend ITU authority to Internet governance in ways that could threaten Internet openness and innovation, increase access costs, and erode human rights online.” – src: protectinternetfreedom.net

Here are a couple of places you can show your support for a free and open web right away:

If you have a bit more time, you can get creative with Mozilla’s Webmaker kit

https://webmaker.org/en-US/ITU/kit/

You can see who is speaking on your behalf here:

http://files.wcitleaks.org/public/S12-WCIT12-ADM-0004!!PDF-E_18Nov.pdf

And this article sums up the transparency issues:

https://www.cdt.org/blogs/cynthia-wong/1607...

Menu Planner: Sequence of user needs

Here’s the next instalment from my Coursera project notes:

This has been an interesting exercise but I’m looking forward to doing some actual design and prototyping work soon.

I’ve also been thinking about how much more flexible software design can be than physical product design; especially hosted auto-updating software like a web app.

Announcing ‘Done by When’

I promised to ship a new piece of software today but I haven’t quite made it.

Ironically it’s a tool for managing expectations, and visualizing likely delivery times for a given piece of work. It would have been useful!

I hate making excuses, but it’s been a crazy month with lots of good interruptions (lovely clients with interesting projects) and bad interruptions (family emergencies and so on).

So while it’s not ready for you to use today, I’ll have to settle with announcing the project title today, ‘Done by When‘.

A version of the tool, whether it’s ‘finished’ or not will ship by this time next week.

Thought I didn’t make the deadline this time, it’s been very helpful for focussing the mind.

I’ve set myself a challenge

I’ve had an idea for a piece of software I think would be really useful. And rather than spend months thinking about and scoping it, I’ve set myself a deadline (deadlines are magic).

The first version will ship by the end of this month.

If I’ve not announced this new project on this blog by 31 Aug 2012, feel free to send me abuse.

I’m also going to use this as a chance to learn some new skills. I think I may learn Python.

Tag: software