Here’s the plan:

• The task board will scrape data from an empty github repository’s issues list
• These issues will be tagged in broad, useful ways (marketing, design, writing, mozilla hispano, whatever)
• New contributors with skills other than writing code will be able to browse the tasks available and get involved easier and quicker than ever before!

The main work that needs to be done falls into two categories:

• Authenticating with github (please help, my brain just falls apart when I try to read about OAuth)
• Creating a page that allows creating new tasks/modifying existing ones through the Github API

We want to avoid any need for users of the task board (both task creators and browsers) to ever visit Github; it’s just serving as a convenient backend to store the data. I’m snowed under with too many projects right now and can’t focus on this right now, but I would be thrilled to work with someone (or several someones!) to get it done. This is going to be a very useful tool when it’s finished, we just need some elbow grease to crank out a prototype. If you have experience with Javascript and/or Python, please get in touch! You can find the source on github.

Measuring the size of a whole community is hard, so I’m not tackling that problem yet. Instead, I’ve focused on the problem of making first-time contributions more visible, and measuring the rate of incoming new contributors in a methodical way. I decided to extract the commit data of mozilla-central into a database which I could query in useful ways; in particular I store a table of committers that includes a name, email address, number of commits, date of first commit, and date of last commit. You can see the raw results of my work at my github repository, where I’m banging away at multiple tools that use this data in different ways.

Tool the first – the Firefox coding community health report:

This measures the number of first patches that are committed in any given month. This graph allows us to see how effective we are at shepherding new contributors through the process of shipping their first change to the code.

Tool the second – the first-time contributor awareness raiser:

This tool lists the contributors whose first patch was committed in a given period of time. With this, we can create reports that will allow us to take actions that celebrate this accomplishment (blog posts, swag, announcements in meetings, submissions for about:credits, etc.). This will allow us to take the burden of these tasks off of the engineers who can’t see beyond the patch, and place it in the hands of people who have a broader vision of building community effectively.

I’m not finished yet! I’m also really interested in measuring how many contributors drop off in a given month – by combining this with the incoming contributor data, we can get rough data about churn in the community, and compare how many people are leaving vs. how many newcomers we have. There are many more interesting measurements to be taken here, and I’m excited to be digging into this data. Feel free to join me! The github repo contains the script to create the database from the git mozilla-central repository, and you’re welcome to explore the data with me.

Take some time every day to clear your disk cache, then put your browser into private browsing mode. If you want to use it for traditionally-private things, that’s cool, it just may be slightly more embarrassing to thoroughly report bugs you encounter. What would be very helpful is if you could spend some time using your browser for regular, non-private things, and every so often open up about:cache and look through the entries in your disk cache. If you see any entry that looks like it came from one of the sites you were visiting, file a bug and CC :jdm and :ehsan. In fact, I will even accept comments on this post, or IRC pings, or emails, or whatever – these are important privacy failures that need to be addressed before FF 18 goes out the door. Do your part to make it unremarkable!

All I ask is that you link to a document that has some kind of instruction for how to get involved. That’s it!

I sing in the an all-male university a capella group called The Water Boys. Our end of term concert is happening on Sunday, and the overall club EOT concert just occurred last weekend:

I also sing in a barbershop quartet called the Bearded Baritones, which doesn’t allow me to hide in the background nearly as much as the 17 person group does (third from right, if curious):

Having just attended my last class of my university career (assuming exams go well), I have to say that this is one aspect of the past five years that I will miss dearly when I move to Toronto this summer.

You are not alone.

I released my smartmake tool last year to allow people to specify then directories they’ve changed, and in return the tool would perform a correct incremental build. No hassle, no sweat. The name was deceptive; it was a pretty dumb tool, but it got the job done with a little help from the user. However, there is a rule that any build system tool eventually reimplements the functionality of make, and so I am proud to release smartmake v2, which requires less work than ever before to produce correct incremental builds.

Thanks to the hard work of the illustrious Till Schneidereit (till on IRC), smartmake now finds every source file modified since the last time you performed an incremental build, and performs a (mostly) minimal rebuild. It will also complain if it comes across any modified files for which it doesn’t have any dependency information, and suggest you perform a full build instead.

Go ahead, give it a shot! Tell me (or Till) what goes wrong so that we can fix it. I recommend doing a full build, then making a small change and running smartmake.py '5 minutes ago' to kick it off and get the timestamp caching happening.

The question: how do I determine if a given URI pointing to an RSS feed is subscribed as a live bookmark?

My first instinct when looking for code I have never touched before is to start with the visible strings in the Firefox interface. In this case, I went to slashdot.org and clicked on the RSS feed button to take me to the RSS feed viewer. Under the options for possible subscriptions, there is the “Live Bookmarks” choice. I’m going to find the code that handles subscribing a live bookmark, which should lead me to the way to find out if a feed is currently subscribed.

So, off to MXR: http://mxr.mozilla.org/mozilla-central/search?string=Live+Bookmarks&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=mozilla-central

Strings are usually stored in special localized files, where the actual string is referred to by a unique name. In this case, we’re looking at subscribe.properties, which shows us that some code should be using the name liveBookmarks to show the localized string in the feed viewer window.

Let’s look that up: http://mxr.mozilla.org/mozilla-central/search?string=livebookmarks&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=mozilla-central

Out of the results, subscribe.xml sounds like something I want to read: http://mxr.mozilla.org/mozilla-central/source/browser/components/feeds/content/subscribe.xml#53

Unfortunately, that line turns out to be not very interesting. However, let’s see what we can find for liveBookmarksMenuItem, which sounds like it might be the item for the live bookmarks option in the dropdown: http://mxr.mozilla.org/mozilla-central/ident?i=liveBookmarksMenuItem

Let’s look at FeedWriter.js from the results: http://mxr.mozilla.org/mozilla-central/source/browser/components/feeds/src/FeedWriter.js

Woah, that’s a lot of code! Let’s take a step back – we care about the subscribing action right now. Going back to subscribe.xml (http://mxr.mozilla.org/mozilla-central/source/browser/components/feeds/content/subscribe.xml), notice that the button is called subscribeButton. That sounds really useful! Let’s look in feedwriter.js again for that (just a regular ctr+f operation): http://mxr.mozilla.org/mozilla-central/source/browser/components/feeds/src/FeedWriter.js#859

Now, let’s find the function subscribe (ctr+f for subscribe:, as that’s commonly how member functions are defined in the Firefox source): http://mxr.mozilla.org/mozilla-central/source/browser/components/feeds/src/FeedWriter.js#1241

Reading the source of subscribe(), we come to
http://mxr.mozilla.org/mozilla-central/ident?i=addToClientReader

We can see the definition of addToClientReader at http://mxr.mozilla.org/mozilla-central/source/browser/components/feeds/src/FeedConverter.js#390. Let’s look at what else is defined here – this seems to be implementing the nsIFeedResultService interface, so we can look up the nsIFeedResultService.idl file in MXR: http://mxr.mozilla.org/mozilla-central/source/browser/components/feeds/public/nsIFeedResultService.idl.

Unfortunately, the service seems to be dealing with actual feed contents, and it doesn’t look like there’s a direct function to help us – let’s step back and see how addToClientReader is implemented.

http://mxr.mozilla.org/mozilla-central/source/browser/components/feeds/src/FeedConverter.js#448 is an important line – let’s look at addLiveBookmark (I just clicked the name again): http://mxr.mozilla.org/mozilla-central/ident?i=addLiveBookmark

Take a look at http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser-places.js#457. This shows us how a bookmark dialog is created, but not the actual subscription process. However, the important part is line 471, which shows us the type "livemark". Let’s search for that string and see what other code uses it: http://mxr.mozilla.org/mozilla-central/search?string=livemark

Woah! There are a lot of results! Since I’m not certain what I’m looking for at this point, I find the best thing to do here is to scan all the results quickly, looking for interesting snippets or filenames before opening any particular file. Partway down, there’s a file called test_bug636917_isLivemark.js (http://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/PlacesUtils.jsm

Searching for livemarks in this file, we find line 2234 which defines the livemarks object as the nsILivemarkService service. Let’s look that up!

First the idl definition, to see if this service will be useful: http://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/nsILivemarkService.idl. There’s a method called getLivemarkIdForFeedURI (http://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/nsILivemarkService.idl#107), which looks to be exactly what we want – it gives us a -1 result for a non-registered feed and another number for a registered one.

So, to sum up – we have found a service that will take a URI and return a value that can be used to determine whether a given feed is a subscribed livemark, and we have learned that livemarks are the internal name for Live Bookmarks. The only bit remaining now is to get access to this service, but we can either use PlacesUtils.livemarks for that (if we import PlacesUtils.jsm), or just use a normal getService call. These are just details; the hard part of answering the original question is complete!