Few days ago, I released a minor version of SlimerJS, my scriptable browser based on XulRunner: SlimerJS 0.9.2.

If you discover my project: this is a browser which is controlled by a script, not by a human. So it has no user interface. In fact this is a browser like PhantomJS, which proposes the same API as PhantomJS. But it is based on Gecko, not on Webkit. See my previous post about the start of the project.

This new version fixes some bugs and is now compatible with Gecko/Firefox/Xulrunner 31.

Next big work on SlimerJS:

• fix last issues that prevent GhostDriver to work well with SlimerJS
• support Marionette(https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette)
• try to implement remote debugging, to allow to debug your script from Firefox Dev Tools
• try to have a true headless browser (so to have a browser without visible windows)

Help is welcomed, See you on Github ;-)

http://ljouanneau.com/blog/post/2014/08/18/Release-of-SlimerJS-0.9.2

About 2 1/2 years ago I wrote a demo for Mozilla Hacks how to use Canvas to create thumbnails. Now I felt the itch to update this a bit and add more useful functionality. The result is:

http://makethumbnails.com

It is very easy to use: Drop images onto the square and the browser creates thumbnails for them and sends them to you as a zip.

You can set the size of the thumbnails, if you want them centered on a coloured background of your choice or cropped to their real size and you can set the quality. All of this has a live preview.

If you resize the browser to a very small size (or click the pin icon on the site and open a popup) you can use it as neat extra functionality for Finder:

All of your settings are stored locally, which means everything will be ready for you when you return.

As there is no server involved, you can also download the app and use it offline.

The source, of course, of course is available on GitHub.

To see it in action, you can also watch the a quick walkthrough of Makethumbnails on YouTube

Happy thumbing!

Chris

http://christianheilmann.com/2014/08/18/makethumbnails-com-drop-images-into-the-browser-get-a-zip-of-thumbnails/

August 18, 2014 we will carry out the webmaker event we’ve scheduled previously, the event held at SMK ITACO Bekasi, this is a vocational school for children who are less economic conditions. We only...

The post Webmaker with SMK ITACO appeared first on oonlab.

http://oonlab.com/webmaker-smk-itaco.onto?utm_source=rss&utm_medium=rss&utm_campaign=webmaker-smk-itaco

There’s been a couple of developments with the social networks Facebook and Twitter that fit together quite nicely this week. The first is the news that Facebook likes make a huge difference in terms of what you see while browsing your news feed:

Wired writer Mat Honan found out what happens when you like every single thing that shows up in your Facebook feed. The results were dramatic: Instead of his friends’ updates, he saw more and more updates from brands and publishers. And, based on what he had liked most recently, Facebook’s algorithm made striking judgements about his political leanings, giving him huge numbers extremely right-wing or extremely left-wing posts. What’s more, all that liking made Honan’s own posts show up far more in his friends’ feeds — distorting their view of the world, too.

But Medium writer Elan Morgan tried the opposite experiment: Not liking anything on Facebook. Instead of pressing like, she wrote a few thoughtful words whenever she felt the need to express appreciation: “What a gorgeous shock of hair” or “Remember how we hid from your grandmother in the gazebo and smoked cigarettes?” The result, as you might guess, is just the opposite of Honan’s experience: Brand messages dwindled away and Facebook became a more relaxed, conversational place for Morgan.

The second piece of news is that Twitter is experimenting with changes to the way that ‘Favorites’ work:

Favorites have also been pseudo-private; while you can view a list of favorited tweets from an account’s profile page or on a tweet’s detail page, typically only the “favoriter” and the “favoritee” ever know about it. If Twitter starts surfacing favorited tweets in timelines, they’ve suddenly become far more public. The change — and the backlash — is somewhat similar to Facebook’s attempts to share just about everything “friends” did with Open Graph.

[…]

For those who have used Twitter for years, the change is so shocking it can seem like the company is completely ignorant to how its customers use the service. But even seasoned Twitter veterans should admit that the service’s core functionality is fairly arcane — it’s far from accessible to new users, and that’s a problem for Twitter.

What I find interesting is that most sites allow you to ‘love’, ‘like’, ‘favourite’, ‘+1’ or otherwise show your appreciation towards content. You can do this with Mozilla Webmaker too, when browsing the gallery. The trouble is that this is extremely limiting when it comes to data mining. If it’s used in conjunction with an algorithm to serve up content (not currently the case with Webmaker) then it’s a fairly blunt instrument.

There are some sites that have attempted to go beyond this. I’m thinking specifically of Bit.ly for Feelings, which allows you to share content that you don’t agree with. But there’s not a lot of great examples.

The trouble is, I guess, is that human emotions are complex, changeable and along three-dimensional analogue spectrum. Digital technologies, on the other hand - and particularly like/favorite buttons - are binary.

Update: after posting this I found that Yahoo! are planning to scan photos you publish on Tumblr to gauge brand sentiment. I’m not sure if that’s better or worse, to be honest!

Questions? Comments? I’m @dajbelshaw on Twitter, or you can email me at doug@mozillafoundation.org

http://literaci.es/like-favourite-binary

My colleague asked me to take a look at a logging issue on a server last week. He noticed that the error logs had way too little information about exceptions. In this particular instance, we had switched to Nginx + gunicorn instead of our usual Nginx + Apache + mod_wsgi (yeah, we’re weird). I took a quick look this morning and everything looked exactly like they should. I’ve read up more gunicorn docs today than I’ve ever done, I think.

Eventually, I asked my colleague Tryggvi for help. I needed a third person to tell me if I was making an obvious mistake. He asked me if I tried running gunicorn without supervisor, which I hadn’t. I tried that locally first, and it worked! I was all set to blame supervisor for my woes and tried it on production. Nope. No luck. As any good sysadmin would do, I checked if the versions matched and they did. CKAN itself has it’s dependencies frozen, this lead to more confusion in my brain. It didn’t make sense.

I started looking at the Exception in more detail, there was a note about email not working and the actual traceback. Well, since I didn’t actually have a mail server on my local machine, I commented those configs out, and now I just had the right Traceback. A few minutes later, it dawned on me. It’s a Pylons “feature”. The full traceback is printed to stdout if and only if there’s no email handling. Our default configs have an email configured and our servers have postfix installed on them and all the errors go to an email alias that’s way too noisy to be useful (Sentry. Soon). I went and commented out the relevant bits of configuration and voil`a, it works!

Image source: Unknown, but provided by Tryggvi :)

http://nigelb.me/2014-08-18-arrrrrgh-tracebacks-and-exceptions.html

I am excited to announce that WebIDE is now enabled by default in Nightly (Firefox 34)! Everyone on the App Tools team has been working hard to polish this new tool that we originally announced back in June.

Features

While the previous App Manager tool was great, that tool's UX held us back when trying support more complex workflows. With the redesign into WebIDE, we've already been able to add:

• Project Editing
  • Great for getting started without worrying about an external editor
• Project Templates
  • Easy to focus on content from the start by using a template
• Improved DevTools Toolbox integration
  • Many UX issues arose from the non-standard way that App Manager used the DevTools
• Monitor
  • Live memory graphs help diagnose performance issues

Transition

All projects you may have created previously in the App Manager are also available in WebIDE.

While the App Manager is now hidden, it's accessible for now at about:app-manager. We do intend to remove it entirely in the future, so it's best to start using WebIDE today. If you find any issues, please file bugs!

What's Next

Looking ahead, we have many more exciting things planned for WebIDE, such as:

• Command line integration
• Improved support for app frameworks like Cordova
• Validation that matches the Firefox Marketplace

If there are features you'd like to see added, file bugs or contact the team via various channels.

http://convolv.es/blog/2014/08/18/webide-enabled/

Mozilla has a number of source repositories under https://hg.mozilla.org/hgcustom/ that cumulatively define how version control works at Mozilla.

Back in February, I launched an effort to establish a unified Mercurial repository for all this code. That repository is version-control-tools and it has slowly grown.

The latest addition to this repository is the import of the hghooks repository. This now-defunct repository contained all the server-side Mercurial hooks that Mozilla has deployed on hg.mozilla.org.

Soon after that repository was imported into version-control-tools, we started executing the hooks tests as part of the existing test suite in version-control-tools. This means we get continuous integration, code coverage, and the ability to run tests against multiple versions of Mercurial (2.5.4 through 3.1) in one go.

This is new for Mozilla and is a big deal. For the first time, we have a somewhat robust testing environment for Mercurial that is testing things we run in production.

But we still have a long way to go. The ultimate goal is to get everything rolled into the version-control-tools repository and to write tests for everything people rely on. We also want the test environment to look as much like our production environment as possible. Once that's in place, most of the fear and uncertainty around upgrading or changing the server goes away. This will allow Mozilla to move faster and issues like our recent server problems can be diagnosed more quickly (Mercurial has added better logging in newer versions).

If you want to contribute to this effort, please write tests for behavior you rely on. We're now relying on Mercurial's test harness and test types rather than low-level unit tests. This means our tests are now running a Mercurial server and running actual Mercurial commands. The tests thus explicitly verify that client-seen behavior is exactly as you intend. For an example, see the WebIDL hook test.

So what are you waiting for? Find some gaps in code coverage and write some tests today!

http://gregoryszorc.com/blog/2014/08/18/mercurial-hooks-move-and-testing-mercurial

What are we learning? This post highlights new metrics and some early analysis from Adam, Amira, Geoff, Hannah and many others. The goal: turn our various sources of raw data into some high-level narrative headlines we can learn from.

Getting to 10K

Current contributor count: 5,529 (Aug 15)

• Are we on track to hit 10K? No, not yet. The statistical increase we’re seeing is based on good work to record past contribution. But our current growth-rate isn’t enough.
• Why is the 4-week trend-line up? Because of Maker Party + bulk capturing historical activity (especially Hive + MVP contribution badges).
• What can we do to grow faster? Short term, we can focus on (amongst other things):
  
  • 1) Maker Party partners. Convert more partner commitments into action, through a streamlined on-boarding process.
  • 2) Webmaker users. Try to convert more users into contributors. Ask them to do something more directly.
  • 3) Training. Net Neutrality teach-ins, train the trainer events, MozCamps, etc.
    • + …what else?

Webmaker users

Highlights:

• We now have about 120K Webmaker users. We’re seeing big recent increases, mostly thanks to the snippet.
• About 2% of those users are currently contributors.
• ~50% of users have published something.
  • Most of that publishing happens on the user’s first day. (Users who don’t make something on their first day tend not to make anything at all.)
  • There’s very little overlap between tools. Users tend to make with a single tool. (e.g., of the ~46K people who have made something, only 2K have made something with both Thimble and Popcorn.)
  • About 20% have opted in to receive email updates from us. (e.g., via BSD)

Owned media

• Snippet
  • Our top snippet performer: “The Web is your playground! See what you can build with Mozilla Webmaker and our global Maker Party.” (+ animated pug icon)
    • CTR = 0.58%. (Other MP variations: 0.15% – 0.49%)
    • The icon and animation have a big influence on CTR. Fun icons and playfulness are the hook.
    • “Teach and learn” language generally performs as well as more playful language.

• Landing pages
  • A “survey-based approach” is our top performer. Asking people *why* they’re interested in Webmaker. (vs straight email sign-up ask) (+4.7% conversion rate)
  • 80 / 20 split for learning vs. teaching. About 78% of survey respondents express interest in making / learning, with 22% wanting to teach / mentor.

• Language focused on teaching, learning and education performs well.
  • e.g., “Welcome to Webmaker, Mozilla’s open source education project, where you can teach and learn the web through making.” (+17%)
  • vs. “We believe anyone can be a tinkerer, creator, builder of the Web. Including you.”

• Mozilla.org referral traffic
  • “Webmaker” out-performs “Maker Party.” Our conversion rate dropped to half when we shifted from from “Learn the web” to “Join our Maker Party.”

“The further away we get from the Mozilla brand, the more work there is to get someone on board.” — Adam

Maker Party

• 1,796 events currently entered (Aug 15)
  • That means we’ve already surpassed last year’s total! 1,694 total Maker Party events last year, vs. same number in our first month this year.
  • But: we’ll still need a big event push in second half to hit our contributor target.
• Key takeaways:
  • Tracking partner activity. Automated tracking has been hard — we’re relying instead on one-to-one calls.
  • We’re gathering great data from those calls. e.g.,
    • Unreported success. Partners are participating in ways that aren’t showing up in our system. Manual badging is filling that gap.
    • Occasional confusion about the ask. Some think “Maker Party” is a “MozFest-level” commitment. They don’t realize the ask is simpler than that.
    • They need easier ways to get started. More simplification and hand-holding. Working on a simplified “Event Wizard” experience now.
    • Some partners see more value in Maker Party than others. Orgs with offerings similar to our own may perceive less value than those in adjacent spaces.
  • We haven’t cracked the earned media nut. Not much coverage. And little evidence of impact from the coverage we got.
  • We don’t have a good way for measuring participation from active Mozillians.
  • Second half. We should gear up for a second “back to school” wave to maximize contributors.

“There’s the ‘summer wave’ and ‘back to school’ waves. We need to have strategies and actions towards both.” –Hannah

Next steps

Short-term focus:

• 1) Partner conversion. This is probably our best immediate strategy for boosting contribution. Ship a simplified on-ramp for Maker Party partners. A new “Event Wizard,” simple start-up events, and user success support.
• 2) Convert Webmaker users to contributors. We’ve seen a *big* increase in user numbers. This opens an opportunity to focus on converting those users. Ask them to do something more directly. Try new low-bar CTAs, email optimization, re-activating dormant users, etc.
• 3) Training. Train the trainer events, MozCamps, MozFest, etc.

Longer-term questions

• Year-long engagement. How do we more evenly distribute event creation throughout the entire year?
  
• Match-making. How do we identify the teachers? How do we connect those who want to learn with those who want to teach? What are the pathways for teachers / learners?
• Impact. How many people are learning? How much are they learning? Should we make “number of people learning” Webmaker’s KPI in 2015?

http://openmatt.org/2014/08/18/data_tells_us/

• use the space in an interactive way to introduce the website visitor to web literacy skills
• acknowledge that the visitor may not have ever seen code before, and understand that we do not know what web literacy skills they are coming to this space with
• create something playful

http://jessicaklein.blogspot.com/2014/08/remix-hack-firefox-home-page-no-really.html

Completed work (resolution is 'FIXED'):

• Buildduty
• update bm-remote with new mobile_tp4.zip file
• Intermittent "Unable to remove C:\slave\test\build!"
• Linux64 non-unified builds aren't starting on mozilla-central
• upload a new mobile_tp4.zip pageset to the 3 headed remote talos server
• Something wrong with b-2008-ix-002x slaves ("LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt")
• General Automation
• enable os x l10n builds on oak
• Don't schedule non-unified B2G hazard analysis builds
• cope with signing server transition in buildbot configs
• You can't choose mochitest-N where N>8 for Android specific mochitests
• Self-serve should be able to request arbitrary builds on a push (not just retriggers or complete sets of dep/PGO/Nightly builds)
• Create Linux64 code coverage builds on Cedar
• Infrastructure for 3rd-party builds, tests to react to 'build events'
• repurpose a snow leopard machine for 10.9 mac signing
• bump dmg max filesize
• hg hook update for mozilla-b2g18
• When requesting spot instances, give up on an az the first time there is no slave name
• Clean up / handle case where spot request is active but instance has gone away
• make sure signing server works on 10.9 and with v2 signatures
• create signing servers for v2 mac signing
• Timeouts during pip install ("Error running install of package, /builds/slave/test/build/venv/bin/pip install --download-cache /builds/...", "Error running install of package, /builds/slave/talos-slave/test/build/venv/bin/pip install --download-cache...")
• There hasn't been a single successful Windows opt/nightly build off a b-2008-sm slave since the uplift
• Loan Requests
• Requesting a loaner machine b2g_ubuntu64_vm to diagnose bug 1017490
• Slave loan request for gbrown
• loan request to investigate bug 1026805
• Requesting a loaner machine to diagnose bug 1039739
• Mozharness
• Turn on blobber upload for Gaia Unit Tests
• Other
• abort: pretxnchangegroup.c_try_mandatory hook failed
• Rename all things Tryserver/MozillaTry to just Try in order to have uniform naming from repo-name on down
• Create bookmarklet to simplify the TBPL -> 'viewing job on the buildbot master' workflow
• Please create a Mobile1.1 tinderbox page
• Need read permissions to subnets
• Platform Support
• c3.xlarge instance types are expensive, let's test running those tests on a range of instance types that are cheaper
• Upload JDK1.7 on builders
• Update Android SDK and build tools to 20
• Change Android 2.2 builds to be called Android 2.3 builds
• update zip and unzip on mac os x build/test machines to 6.0
• Release Automation
• Have release automation support signing OSX builds
• update partner repack scripts to cope with new format after mac signing changes
• pymake hacks in release repacks drop all but one signing server from list
• Tree closure hooks for esr31
• Tree closure hooks for esr17
• Repos and Hooks
• push hooks should print out hg url for the changeset
• The order of reviewers matters for the webidl commit hook
• Enforce a set of allowed commit messages as hg precommit hooks on hg.m.o
• Reject changesets containing "[PATCH"
• Approval hook should not reject backout commits that do not contain an a=foo
• Make mercurial closure hooks fail closed once treestatus.mozilla.org proven reliable
• Allow pushing Instantbird-only changes on a closed c-c- tree
• Tree closure hook should be more robust
• Move hghooks repository into version-control-tools
• Make prevent_webidl_changes.py correctly deal with merges
• Roll local changes to treeclosure.py into repo (update treeclosure hook for mozilla-2.1, mobile-2.0, mozilla-2.0 trees)
• remove jhopkins and mihai from releng whitelist
• Give Treeherder URLs alongside TBPL ones in the hg.mozilla.org push response
• We should probably reset try to stop breaking hg.m.o
• treeclosure hook fetches 2MB of HTML to get at a few hundred bytes that are in TreeName/status.html
• Skip testTipDirRenameShouldFail on non-case sensitive filesystems
• Change user to emailuser in hg annotate web interface
• "sr=[DOM peer]" should be allowed as well as "r=[DOM peer]" for webidl changes
• fx-team branch of gecko-dev hasn't synced in 8 hours
• Tools
• Verify that trychooser's tryload is looking at the right names for pending jobs and adding them up into the correct buckets
• Add timeouts to buildapi's urllib.urlopen() requests
• Funsize should return correct MIME type
• Add linux64-mulet to trychooser
• Aggregate similar exceptions in emails from masters
• Runner dies before starting buildbot due to hg failures and leaves slave doing nothing
• Deploy newer slaverebooter
• Funsize returns errors out and returns an HTTP 500 when requested for a non-existent partial
• tree closure hooks for integration/b2g-inbound
• Allow filtering tests by b2g and Android
• Prune the allowed origins list for buildapi
• Update trychooser for Android again
• Slaverebooter should honor pep8 and where-applicable pylint

• Balrog: Backend
• add schema for h264 updates
• Balrog: Frontend
• balrog's rules page is excessively wide
• General Automation
• try emails should include commit messages from pushed commits
• [Tracking] Stand up Code Coverage build and test runs
• Thunderbird Linux and Mac MozMill builders are using the system python (fix bustage on Thunderbird Mac MozMill builders)
• Increase web-platform-tests to 4 chunks
• AWS region-local caches for https stuff
• Modify file structure of Firefox.app to allow for OSX v2 signing
• generate "flatfish" builds for B2G
• Port Runner cross-platform
• Splitting Gij and Gip tests in several chunks
• Run mock against repos other than puppetagain
• Add signing for firefox and org.mozilla.updater binaries on OSX
• Make runner responsible for buildbot startup on Ubuntu test
• Make some mozharness jobs easier to run outside of automation + allow for http authentication when running outside of the releng network
• Increase Android 2.3 mochitest chunks
• Create daily builds for Dolphin on all branches under active development
• Turn off Firefox desktop nightlies on the B2G release branches
• Tracking bug for 01-sep-2014 migration work
• Stop rebooting after every job
• FlatFish: Integrate boot.img and recovery.img into the build system
• Adjust cloudtrail related crojob times
• Add dependency management to Runner
• Split webgl tests into a separate mochitest-gl suite on desktop
• Add --disable-mock option to b2g_build.py
• port buildapi to relengapi
• stop jobs from hg'n mozharness/tools repos
• Loan Requests
• Requesting a loaner machine b2g_ubuntu64_vm to diagnose Bug 1043892
• Loan an ami-6a395a5a instance to Aaron Klotz
• Requesting Android 4.2 x86 emulator machine for jchen
• Mozharness
• Add crash log formatting to StructuredFormatter
• Make sure to mark jobs as failures when structured logger parsing fails
• Investigate switching Thunderbird comm-central xpcshell-tests to mozharness
• Move Firefox Desktop repacks to use mozharness
• Failures during install_module() are shown as ERRORs in the log even though the run succeeded
• Other
• figure out what to do with the n900s
• Upgrade ASan Clang to trunk r214699
• Make AWS node type available to graphite & build metadata
• Platform Support
• create HVM ami for Ubuntu64
• Deploy NSIS 3.0a2 or MozillaBuild 1.10 (includes NSIS 3.0a2) to buildslaves
• [mozpool-client] TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
• Upgrade Mercurial clients to 3.0.2+
• Run unittests/talos on OS X 10.9 Mavericks
• Release Automation
• release automation should update ship it at certain points
• pushing release builds to beta doesn't work in balrog
• Thunderbird ship-it notifications have wrong mozilla-beta revision
• Automatic filling of the branch field in ship-it
• make aus3 and aus4 responses consistent
• Add a standalone process that listens to pulse for release related buildbot messages
• Add REST API entry point to shipit that allows shipit-agent to enter release data into shipit database
• Add new table(s) to shipit database
• Releases
• tracking bug for build and release of Thunderbird 31.1.0
• tracking bug for build and release of Thunderbird 24.8.0
• tracking bug for build and release of Firefox and Fennec 32.0
• tracking bug for build and release of Firefox 24.8.0 ESR
• Repos and Hooks
• Commit message hook should enforce the bug number being in the first line
• Disallow "b=N" (instead of "Bug N") in commit message hook
• Tools
• Funsize requires file level diff caching for speedups in partial generation
• Make Funsize generated partials identical across platforms and environments
• slaverebooter should attempt reboot if graceful shutdown fails
• Funsize tool handling is broken and incorrect

http://jordan-lund.ghost.io/this-week-in-releng-aug-11th-2014/

tl;dr: I built a thing to see public graphs of hg.mozilla.org called hgstats.

Lately, we’ve had problems with Mercurial at Mozilla. The Developer Services Team added a bunch of instrumentation to the hg webheads to help us track what is going wrong and when, to give us somewhat an early indicator of when things get shot to hell. All of these are on the Mozilla Graphite instance which are behind employee-only LDAP. However, an interesting quirk is that the image rendering is actually available without authentication. As a community Sheriff, I’ve been keeping close watch on hg throughout my shift with images that releng folks or hwine gave me. This gave an indicator of when to close trees so that we don’t end up having everything turn red. On Thursday evening, I was watching the conversation in #vcs on irc.mozilla.org, when bkero mentioned he’d made a dashboard in graphite. It suddenly dawned on me that I could just embed those images onto a page and quickly have a public dashboard!

Armed with a bunch of images from Ben, I created a github pages repo with a lovely theme that’s available by default. I embedded the images onto a static HTML page and suddenly, we had a minimal dashboard. It wouldn’t auto-refresh or let you alter the duration of the graph, but hey, now we had one place for things! This first step took about 15 minutes.

There were two features I had in my mind as must-haves: a) the page must let me change the hours of the graphs (i.e. last 2 hours, last 4 hours, last 8 hours, etc), and b) it should auto-refresh. I’ve looked at backbone several times in the past and I figured this was a good time as any to get cracking on building a backbone.js app.

I started slowly, the first step was, get everything I have right now, rendered with backbone. I spent a lot of frustrating hours trying to get it to work, but couldn’t because of silly mistakes. I haven’t been coding in JS much and it shows :) I think I stayed up until 2 am trying to diagnose it, but I couldn’t. When I woke up in the morning, I spotted the trouble immediately and it was a tiny typo. Instead of

http://nigelb.me/2014-08-17-the-story-of-hgstats.html

Week 5!

tl;dr highlights of the week:

• Though we saw significant jumps in Wm accounts and events, our Contributor numbers did not increase accordingly
• We’re identifying many opportunities from the partner calls
• Hack the Snippet is coming soon, along with the next iteration of the snippet funnel
• The TweetChat created a temporary increase in Twitter engagement, but took attention away from press
  

Overall stats:

• Contributors: 5552 (2% increase from last week’s 5441)
• Webmaker accounts: 124K (17% increase from last week’s 106.3K)
• Events: 1799 (crazy 50% jump from last week’s 1199)
• Hosts: 493 (10% increase from last week’s 450)
• Expected attendees: 76,200  (23% increase from 61,910)
• Cities: 362 (40% increase from 260 – what caused this jump?)
• Traffic: here’s the last three weeks. We continue to see the major boost from the snippet.

http://hannahgrams.com/2014/08/17/maker-party-engagement-week-5/

The writeup of the OKFestival is very incomplete, because I haven’t mentioned the fringe events! I attended two fringe events and they both were very good.

First, I attended CKANCon right before OKFestival. It was informal and co-located with CSVConf. My best takeaway has been talking to people from the wider community around CKAN. I often feel blind-sided because we don’t have a good view of CKAN. I want to know how a user of a portal built on CKAN feels about the UX. After all, the actual users of open data portals are citizens who get data that they can do awesome things with. I had a good conversation with folks from DKAN about their work and I’ve been thinking about how we can make that better.

I finally met Max! (And I was disappointed he didn’t have a meatspace sticker :P

The other event I attended was Write the Docs. Ali and Florian came to Berlin to attend the event. It was total surprise running into them at the Mozilla Berlin office. The discussions at the event were spectacular. The talks by by Paul Adams and Jessica Rose were great and a huge learning experience. I missed parts of oncletom’s talk, but the bit I did catch sounded very different to my normal view of documentation.

We had a few discussions around localization and QA of docs which were pretty eye opening. At one of the sessions, Paul, Ali, Fabian and I discussed rules of documentation, which turned out pretty good! It was an exercise in patience narrowing them down!

I was nearly exhausted and unable to think clearly by the time Write the Docs started, but managed to face through it! Huge thanks to (among others ) Mikey and Kristof for organizing the event!

http://nigelb.me/2014-08-17-okfestival-fringe-events.html

Yet another update from my internship at Mozilla, as part of the OPW.

An online triage workshop

One of the most interesting thing I've done during the last weeks has been to held an online Bug Triage Workshop on the #testday channel at irc.mozilla.org.
That was a first time for me: I had been a moderator for a series of training sessions on IRC organized by Debian Women, but never a "speaker".
The experience turned out to be a good one: creating the material for the workshop had me basically summarize (not too much, I'm way too verbose!) all what I've learned in this past months about triaging in Mozilla, and speaking of it on IRC was a sort of challenge to my usual shyness.

And I was so very lucky that a participant was able to reproduce the bug I picked as example, thus confirming it! How cool is that? ;)

The workshop was about the very basics of triaging for Firefox, and we mostly focused on a simplified lifecycle of bugs, a guided tour of bugzilla (including the quicksearch and the advanced one, the list view, the individual bug view) and an explanation of the workflow of the triager. I still have my notes, and I plan to upload them to the wiki, sooner or later.

I'm pretty satisfied of the outcome: the only regret is that the promoting wasn't enough, so we have few participants.
Will try to promote it better next time! :)

about:crashes

Another thing that had me quite busy in the last weeks was to learn more about crashes and stability in general.
If you are unfortunate enough to experience a crash with Firefox, you're probably familiar with the Mozilla Crash Reporter dialog box asking you to submit the crash report.

But how does it works?

From the client-side, Mozilla uses Breakpad as set of libraries for crash reporting. The Mozilla specific implementation adds to that a crash-reporting UI, a server to collect and process crash reported data (and particularly to convert raw dumps into readable stack traces) and a web interface, Socorro to view and parse crash reports.

Curious about your crashes? The about:crashes page will show you a list of the submitted and unsubmitted crash reports. (And by the way, try to type about:about in the location bar, to find all the super-secret about pages!)

For the submitted ones clicking on the CrashID will take you to the crash report on crash-stats, the website where the reports are stored and analyzed. The individual crash report page on crash-stats is awesome: it shows you the reported bug numbers if any bug summaries match the crash signature, as well as many other information. If crash-stats does not show a bug number, you really should file one!

The CrashKill team works on these reports tracking the general stability of the various channels, triaging the top crashes, ensuring that the crash bugs have enough information and are reproducible and actionable by the devs.
The crash-stats site is a mine of information: take a look at the Top Crashes for Firefox 34.0a1.
If you click on a individual crash, you will see lots of details about it: just on the first tab ("Signature Summary") you can find a breakdown of the crashes by OS, by graphic vendors or chips or even by uptime range.
A very useful one is the number of crashes per install, so that you know how widespread is the crashing for that particular signature. You can also check the comments the users have submitted with the crash report, on the "Comments" tab.

One and Done tasks review

Last week I helped the awesome group of One and Done developers, doing some reviewing of the tasks pages.

One and Done is a brilliant idea to help people contribute to the QA Mozilla teams.
It's a website proposing the user a series of tasks of different difficulty and on different topics to contribute to Mozilla. Each task is self-contained and can last few minutes or be a bit more challenging. The team has worked hard on developing it and they have definitely done an awesome job! :)

I'm not a coding person, so I just know that they're using Django for it, but if you are interested in all the dirty details take a look at the project repository. My job has been only to check all the existent tasks and verify that the description and instruction are correct, that the task is properly tagged and so on. My impression is that this an awesome tool, well written and well thought with a lot of potential for helping people in their first steps into Mozilla. Something that other projects should definitely imitate (cough Debian cough).

What's next?

Next week I'll be back on working on bugs. I kind of love bugs, I have to admit it. And not squashing them: not being a coder make me less of a violent person toward digital insects. Herding them is enough for me. I'm feeling extremely non-violent toward bugs.

I'll try to help Liz with the Test Plan for Firefox 34, on the triaging/verifying bugs part.
I'll also try to triage/reproduce some accessibility bugs (thanks Mario for the suggestion!).

http://blog.zouish.org/posts/opw4/

This term has been very unfruitful. I picked up League of Legends after an abstinence streak from DotA that lasted 4 good years. This kinda makes me sad. I’ve also lost a lot of motivation, especially with books and academia. It really isn’t the gaming that’s causing this. It is more just a lack of willpower to carry on doing something that seems so pointless. There’s a whole new post graduation world out there, with new and relevant things to learn.

I’ve really taken a liking to software development. It’s funny because in first year I remember believing that I could never picture myself sitting in front of a computer all day typing away. Yet here I am now, not knowing what else I would rather be doing.

I also remember having long-term plans for myself to run a self-grown start-up right after graduation. It’s not that I haven’t been trying. I have been working hard on these things over the past years but nothing seems to have gained any valuable traction at all. With only 8 months left to graduation, this once long-term goal and deadline is suddenly approaching and hitting the reality of being unattainable. Such a realization kills the motivation to carry on pushing.

Visions of life after university used to be so bright and optimistic. But as the moment slowly approaches I realize how clueless I really am and that’s OK. Engineers are trained problem solvers; we figure things out, eventually.

http://blog.williecheong.com/shutdown-4a-study-term/

http://blog.rgaiacs.com/2014/08/17/mathml_august_meeting.html

http://blog.rgaiacs.com/2014/08/17/gsoc_august_11_august_17.html

• 7 changesets
• 19 files changed
• 104 insertions
• 22 deletions

List of changesets:

http://release.mozilla.org/statistics/32/2014/08/16/fx-32-b6-to-b7.html

I’m quite satisfied with how well the past week has gone. It’s been incredibly productive despite a few distractions and a great many meetings. Here’s my report on what I’ve been doing, and what I will be doing in the near future.

What I’m up to

I’ve been busy optimizing my own work processes, as well as setting up information so others know what needs to be done as well. I’ve also done a lot of copy-editing and organizational work in content, and have been touching up stuff ranging from the MDN inbox to the Learning Area to doc plans. It’s been a wonderfully productive week, and it feels good to be getting back into the swing of things.

What’s up next

Next week, I intend to dive into WebRTC, and to start putting together sample code so I can begin work on writing guides to working with WebRTC. It’s going to be really exciting!

As usual, of course, I have a number of other, smaller, tasks I want or need to accomplish, too.

What I did this week

• Moved the main page on DocShell from the top level of MDN to its proper home, and filed a bug on getting it fully documented.
• Dealt with infrastructure failures at my office: the air conditioning completely failed (working in a swelteringly hot office is not fun), and I discovered standing water in the restroom. The A/C is now fixed; the water problem has not been figured out yet, although the water has evaporated for now.
• Helped test the new GitHub login support on the MDN staging server, and filed a few bugs regarding quirks I noticed.
• Reviewed and had nothing but nice things to say about the new welcome email sent out by MDN to new members.
• Got involved in the discussion about disabling styled pasting in the MDN editor. I’m opposed to this; I would much rather we solve the problem from the user’s end — contributors should learn to be sure they don’t include crufty styles when they paste into MDN. But ideally we can come up with a solution that doesn’t break existing workflows, punishing people who aren’t making this mistake.
• Moved the page Write a new entry in the Glossary to the right place; it had accidentally been given an obsolete URL due to a couple of MDN bugs. Reviewed and copy-edited the content.
• Filed a bug for a feature suggested by biraj: content from one page on MDN that’s presented inside another page should be reflected in the displayed contributor list. I don’t know how likely this is to be addressed (it certainly won’t happen soon). It’s a big project and there are many unanswered questions.
• Copy-edited the new Glossary entry for the term “i18n“.
• Added the word “Glossary” to the list of tags that MDN offers auto-completion for.
• Followed-up on a bug asking me to write some copy for the Github login experience.
• Did some tidying up of the MDN style guide, including moving Chris Mills’ excellent new section on our policies on gender-neutral terminology to be among the language and grammar topics rather than in the markup and wiki usage topics area.
• Minor changes to the Learning Area page on CSS. This page needs a lot of work still but I saw low-hanging fruit.
• Converted the Learning Area into a zone. Its landing page needs finishing, but this is a nice step.
• Finished an extensive review and copy-edit of the Learning Area page Write an article to help learn about the web.
• Removed a page that was actually just a set of Firefox problem reports, and emailed the author information about how to properly report issues.
• Found an MDN “Linking Guide” lurking in a dead part of the site, and moved it into the MDN user guide, with major updates and copy-edits.
• Updated the MDN user guide’s landing page to use the LandingPageListSubpages macro, so it looks a little better.
• Adapted Luke’s screenshot/diagram about how to enable a page subscription on MDN into a new page in the MDN how-to guide.
• Tweaks to the Inbox page in preparation for expanding its visibility.
• Integrated the first round of feedback into the WebGL documentation plan.
• Updated my Geeksphone Peak to Firefox OS 2.0 nightly for use in upcoming WebRTC sample code tests.
• Filed a bug about iCloud.com saying “Android not supported” on Firefox OS 2.0's browser.
• Pinged developers about reviewing the WebGL documentation plan.
• Created several new basic (that is, mostly empty) MDN development project plan pages:
  • MDN accessibility review
  • Mobile/tablet experience review and update
  • Offline experience review and enhancement
  • Stack Overflow integration enhancements
• Copy-edited the Learning Area’s How to contribute to the Learning Area article.
• Filed a documentation request bug for documenting the NavigatorFeatures (hasFeature/getFeature) API. This API is low-priority privileged API, documentation-wise.
• Added notes to a couple of pages in the MDN contributor guide about being careful when pasting, to avoid pasting unwanted styles and classes into MDN.
• Created the DocPlanHelpUs macro, which inserts text inviting participation in a project and describing how to get started. Added it to the appropriate place in all extant doc plans.
• Took some notes, sent some emails, and added links to the project planning page for the on-site messaging project.
• Added a link to the MDN contributor guide to the footer of messages on the dev-mdc mailing list, and tweaked my email address on the moderator email list names.

Meetings attended this week

Monday

• #mdndev bug triage
• MDN development planning

Tuesday

•  1:1 meeting with Jean-Yves

Wednesday

• MDN Community meeting
• 1:1 meeting with Ali

Friday

• #mdndev weekly review meeting
• MDN bug swat (which didn’t get much done due to several missing people and connectivity issues this week). We did quickly select three bugs to ask to be uplifted into the queue:
  • No “Review needed?” section when creating a subpage
  • You shouldn’t be able to create a new page as a child of a redirect
  • That for some reason zone pages are not handling redirects of old “/en/” URLs correctly. I can’t find a bug for this but we’ve urged that it be fixed to avoid accidental creation of invalid page URLs in the future by mistake.

As you see, it was an intensely busy week! I’ve started moving into using OmniFocus to track what needs to be done and by when and I think it’s going to help, but we will see how it plays out over time. I have a history of not doing well at keeping up with my organizational systems, as you’ve possibly noted if you read my posts over history about my various attempts to get organized.

At any rate, it’s been a good week, and I can’t wait to get more done!

http://www.bitstampede.com/2014/08/16/the-sheppy-report-august-15-2014/

Four Months (just remembered this blog is for (H)an(n)a(h)grams, so: Fonts Humor)

I’ve been here for four months. I think the famous Mozilla firehose is finally starting to slow down. A main difference between me now and me three months ago is that now, on most days, I actually know how to do the things on my ToDo list. SuperBonus: I can usually follow what’s happening in meetings now!

Significantly, I’m starting to add things to my ToDo list that are more than just the bare minimum of program maintenance. I’m starting to understand where I might be able to innovate and add value.

About a month after I started, I inherited the job of maintaining @Mozilla social channels, and about a month after that, I inherited the job of managing the relationship with our Maker Party PR company. Together these things took up a good chunk of my time over the past two months, largely because they’re outside my area of expertise (I helped launch a social media program at my last job, but that was back when Twitter was brand spankin’ new, and things have changed tremendously since then).

While I think both of these tasks ended up providing me with a great platform for learning about the organization (I have to know what’s going on so I can tweet about it!), I am looking forward to focusing more intently on the aspects of the program manager job I feel I’ve been neglecting.

I Feel Good (I Do Elf Ego)

Some of the things I feel good about from the past few months:

• I think the Maker Party engagement updates and analyses (some of which I’ve posted on this blog) have been helpful in sparking some good conversation at our daily “Peace Room” meetings. Also, charts make me seem smart.
• Our Salesforce for Partners implementation is a tiny bit behind schedule, but I feel good about where we are in the process. I was glad to be able to take this partially off of others’ plates and share the burden, because no one should have to face Salesforce alone.
• Working with Dave, Erika, Mavis, and Sabrina on the Advocacy site has been a pleasure, and I think the end product is going to be great.
• Yesterday’s Tweetchat was pretty fun.

Can Do Better (rent taco bed)

Some things I want to work on in the months ahead:

• I want to operationalize what it means to be a Clockmaster, and refine the suite of tools we use to manage our work. Now that we have Sprinter, I feel a lot better about Bugzilla (which, I admit, I headdesked about for the first couple months I was here). But I don’t think it fully meets our needs, so we’ll need to supplement with other tools and processes.
• I want to help reduce the pain in our grant reporting process. Gettin’ paid shouldn’t hurt so bad.
• I want to crack the nut of social media. I was inspired by a recent conversation with Michaela Smiley, and I believe we can do a much better job of engaging and serving our community, while also better expressing the Mozilla brand and growing the Webmaker community. Hashtag win.
• I want to make sure Maker Party 2015 is even more full of awesome by capturing and acting upon our learnings from this year. In general, I’d like to help create a culture of reflection and continuous improvement. Not to get too existential, but isn’t this what life is about?
• I want to improve our systems for distributing knowledge across the organization. I’ve seen really good examples of this (Andrea’s email-fu workshop, the Fundraising workshops that happened a few months ago, Geoffrey’s trendlines workshop from this morning, and probably many more). I don’t think Encyclopedia BestPractica is working as a tool for knowledge sharing, so I’d like to come up with something that meets people where they are (rather than making them come find it).
• I want to keep improving our cross-team collaboration. Even in my short time here, I’ve already seen great strides in this, but there’s more to do. This project brief template is one of my first direct efforts toward that, in addition to just building relationships with many of my super rad co-workers.

Finally, I just want send a big ol’ shout out to said co-workers for making my first third of a year so enjoyable.

Onward!

http://hannahgrams.com/2014/08/15/13-of-a-year/