user should be able to add multiple accounts with repo to get the information.
eg. bugzilla [email protected]
github [email protected] etc..

It takes some time for the BZ API requests to be completed. A loading animation would be great for that time.

It looks like http://dev.mozillaindia.org/leaderboard/ is not active any more. I understand it has been a while since anyone made any changes to the repo. Are there plans to bring this back up?

New projects like Rust, Servo, Persona are on GitHub. Use the GitHub API to access them as well.

issues reported to Mozilla can also be displayed, make sure only valid reports are displayed. i.e. those got the status as New (bugzilla terminology)

Discuss, what bare minimum info needs to be there in the collapsed view, and what else on the expanded view.

for a new user to add his name in the list.

Anybody with L1 access can grab the L1/L2/L3 data from
https://ldap.mozilla.org/contributors/. It might be easiest to have a script that fetches it and updates the leaderboard data.

The assigned bug's link is not working for each entry. By looking at the app.js it seems that its linking the bugzilla's search query through email id and so it must work for each entry.

Adding a footnote - "It tracks Mozilla's project which are patched through BugZilla only."

Instead of making 2 calls (1 for assigned bugs and 1 for fixed) per user for bugzilla stats, we can club both calls for all (or batch of) users into one single call.

We will still need to make 1 call per user for getting the component information though.

We can even go further ahead and calculate the fixed numbers by summing up the numbers obtained from the components call. This will make the first batch call faster.

The https://bugzilla.mozilla.org/user_profile?login=username%40email.tld can provide some more* useful insights about one's BMO activities.

Especially if someone is involved more with locked/private bugs.

Sankha was talking about some mozilla-b2g repos. Maybe even this repo too ? ;)

and thus remove the unused and now-non-functional GA tracking that was inherited from Sankha

Currently bug numbers are displayed by RESOLVED keyword, considering using the FIXED as well.

Right now, the limit is 60 calls per hour. If we switch to auth api calls, we can have 5000/hr. I think Sankha has an idea on how to do this..

What's the point showing the people with zero bugs fixed?
Catch a hobo off the street & he also has fixed zero bugs.

No hobo/bugs were harmed during drafting the comment.

• Move the components into separate directories
• Use GitModules, to keep the component reusable & un-coupled
• Cleanup JS, use closures and scope the methods under a namespace
• Use web-components ( Mozilla Bricks? ) for most of the templating works

Sorting Order of the display list.
We can choose either by number of bugs fixed, by nicks etc.

Add a "has patch" boolean check to the query to have a more reliable # of bugs fixed.

We already have info on existing number and new number as they are coming in. It would be a nice icing on the cake if we show in green (with possibly an arrow) the numbers which increases/changed (possible in red if it decreased)