It's easy for me (and, I'm sure, most people reading this) to forget that the vast benefits of computers and the Internet are not yet accessible to the majority of the world's population. That's a lot of people who don't have easy access to the world's knowledge and people in the form of encyclopedias, science and math books, news, music, art, novels, forums, instant communication, and more.

So, I'm always inspired to see projects aimed at narrowing the gap.

San Francisco start-up Endless have designed a computer made to be affordable for emerging markets that saves cost by re-using a TV as a display (which are relatively wide-spread even where computers are not) and using best-of-breed open source software. And they've built the software specifically to work for the developing world which has different challenges than the developed world, such as unreliable Internet connectivity.

Please see the videos on their website that explain much better than I have the importance of bringing computers to the rest of the world.

I'm proud to say that my colleagues at Collabora have helped develop software platform that Endless will be shipping on these computers and have contributed to their Kickstarter campaign.

As I write this, there's just a little time left to contribute to Endless's Kickstarter campaign. Please consider a donation because every bit helps.

In the Folks project, we've managed pretty good buildability as we've been developing the project. So far, that's mostly been through us checking buildability of patches during reviews and fixing any build breaks immediately when we hit them on our own machines. As I said in my FOSDEM talk, I don't think this "spot checking" is sufficient for the kind of reliability GNOME projects really need given our reliance upon jhbuild (which, by its design, does not cope well with unbuildable master branches).

A couple weeks ago, Martin Pitt announced the jhbuild continuous build server he has been working on. It's a great setup and clearly details which modules are failing to build and why. It also keeps useful metrics like "time of last successful build", "time of last failed build", and runs and reports on the results of "make check".

This is a great safety net for GNOME as a whole, since it continuously checks our entire stack in a common environment. Once maintainers get reliably notified about any breaks, I think we'll see broad benefits. When our code reliably builds and passes its unit tests, it's a lot more attractive to outside (and inside!) developers.

With, thankfully little work, Folks is now reliably building and passing its unit tests on this server, and I intend to keep it that way :)

I'd like to thank Martin for setting this all up and him and Jean-Baptiste Lallement for helping debug some LXC-related issues which were causing some of our tests to fail on this server (but not for us maintainers, making it hard for us to help).

In the process of fixing these issues, the build server proved its usefulness for our project already because it caught a build break I didn't hit on my own system (because I had an older version of EDS build). Normally, this could have taken days or longer for me to notice because I tend not to re-build the stack below Folks very often. If I'm working on a large feature, I want to get it all working before I potentially break my build environment with unstable changes in our dependencies. A continuous integration system should also make frequently updating dependencies less of a risk (which is just more good news for everyone).

I coincidentally stumbled across this on my flight back from FOSDEM:

The word decision, closely related to incision, derives from the meaning 'a cutting off'. Making effective decisions—and learning effectively—requires massive elimination and the removal of options.
—Tim Ferriss, The 4-Hour Chef

During the GNOME Developer Experience Hackfest this week, one of the major goals we identified was the need to pick a single language to give a simple answer to "how do I write a GNOME app?".

Right now, if you ask that question, you'll get about 8 different personal-preference answers, which drives people away from our platform. Having to potentially evaluate several different languages and their stacks gives potential developers a lot of unneeded extra work.

There was broad consensus in the hackfest for this goal because it allows us to:

• It allows us to focus when we write developer documentation, fixing bugs in the development environment and the development of tools. This reduces our maintanence costs and enables us to be vastly more efficient.


• It enables code and knowledge sharing to occur, so that people can easily copy and paste code from existing applications, or find information about common problems and challenges.


• It provide a coherent and easy-to-follow path for new developers.


• It allows us to include the full GNOME framework within the language itself.

We spent a long time discussing the different options that are available to us, and there were a variety of opinions. However, at the end of the day, we had to recognize that no language is perfect and there will always be disagreement. The important thing was that we had to make a decision.

It's critical that everyone understands this decision as a plan to elevate the language, bindings, tools, and documentation to a level of quality we have not yet achieved. It is not a decision to abandon any other language bindings. We will continue to distribute other bindings and documentation as we do now and compatibility for the other languages will continue to be developed as they are today by the developers involved with those modules.

Our decision is to support JavaScript as the first class language for GNOME application development. This means:

• We will continue to write documentation for other languages, but we will also prioritize JavaScript when deciding what to work on.


• We will encourage new applications be written in JavaScript.


• We will be working to optimize the developer workflow around JavaScript.

C will remain the recommended language for system libraries.

Why JavaScript?

• Our language of choice needs to be dynamic and high level.


• There is already momentum in the GNOME Project for JavaScript -- it's used in GNOME Shell and GNOME Documents.
• 
  
• There's a lot of work going into the language to make it especially fast, embeddable, and framework-agnostic.


• JavaScript is increasingly being seen as a first class desktop programming language -- it us being used in Windows 8, mobile platforms, and for local web applications.


• JavaScript is self-contained -- it doesn't come with its own set of core libraries, which makes it more convenient for us when integrating it into the platform.

This is the start of a process and there's obviously a lot of work ahead of us. However, prioritizing a single language will enable us to turn GNOME into a compelling platform for application developers in a much more effective and efficient manner.

After years of attempting to apply the philosophies of Inbox Zero and Getting Things Done (including, appropriately, failing to finish the GTD book twice), my personal and work inboxes are empty and I've never felt so on-top of my tasks. In no particular order, here are some changes I've made that have helped me out:


Forget what you're standing on and focus.

I read The 4-Hour Work Week, which touches on Inbox Zero and adds some interesting productivity-increasing ideas, including giving up on boring articles and the controversial "don't waste time reading news". I haven't stopped reading news, but I feel like I've gotten a little more efficient at it. I mostly ignore mailing lists (except those for my immediate projects). The only reason I'm subscribed to some is so that I can reply to them on the occasion I'm CC'd or someone brings up a specific discussion to me.

Along the line of distractions, I've been training myself to catch them before they happen. Because there's increasing evidence that multi-tasking reduces productivity (and it seems obvious to me anyhow), I push myself to not switch tasks unless I absolutely have to. And I actively ignore anything that I know will needlessly steal my focus. This includes only checking up on IRC periodically (and mostly just to check for messages that have been highlighted for me). If it's urgent, people will send me a direct message (and Gnome Shell will give me a nice notification).

I believe the author of 4HWW intentionally mentions keeping only calendar events, not tasks. I've always liked the idea that you will remember anything important and anything minor will come up again (particularly because I've struggled with far too many tasks in my GTD system). But that seems too extreme/unworkable for me, so the key has just been being much more aggressive in deleting tasks that sit too long (knowing I'll never get to them) and doing periodic sweeps through each list. If you have trouble with that, you might want to create a "some day" list to move neglected tasks to. Then, just make a point to ignore that list. I think I'm nearly ready to delete mine.

Another part of minimizing mental burden has been closing application tabs and windows and conversation notifications as soon as I can. When I finish a task, I close everything related to it (even if I think I'll use some of them later). The stress saved by this reduction in visual noise is much greater than occasionally having to re-open something sooner than expected (which is incredibly rare, as you might imagine).


Your screen should not look like this.

And the latest change I've made, just before reaching inbox zero/GTD zen, has been to batch process my inboxes. I had a terrible habit of glancing at mail, flagging it important and unread, then moving on. It turns out that I subconsciously skip over bold, red lines of text. This was a horrible priority inversion that lead me to sporadically clearing out the simple mail while ignoring the high-priority, difficult tasks.

Now, when I do my few daily mail passes, I do two quick passes (always in oldest to newest order, never skipping any):

1. Add tasks, file mail
   
   1. parse out new tasks to my GTD system (setting due date and priority appropriately)
      
   2. if it needs a trivial or no response, give it immediately, then file
      
   3. otherwise, move on to the next letter
      
2. Give non-trivial responses
   
   1. Read the letter in detail
      
   2. Respond to each point necessary
      

Now, with an empty inbox, I can get work done by just drilling through items in my work or personal task list in order from highest to lowest priority. It's a lot harder to skip around, ignoring the important tasks, when they're sitting in front of you, in the exact order you've chosen yourself.

I still have things to improve (I really wish I had one place to manage all my tasks, not several), but I finally feel in control of my day-to-day goals!

Valerie Aurora posted a very insightful article about harassment at conferences. She focuses largely on "hacker"/security conferences, like DEFCON, but the general principles apply to all conferences. And I've personally seen related bad behavior (though to a much lesser degree) at conferences I've attended (which have all been based around open source software, not "hacking"/security).

The work that Valerie's Ada Initiative is critically important for the technology industries, which still have a lot of work to do on being inclusive (particularly to women).

As some personal anecdotes, most of the best conferences I've attended have had strict anti-harassment policies/codes of conduct (including Linux.conf.au and GUADEC). They help make the conference a more-welcoming place by clarifying unacceptable behavior, which brings in more participants from a wider variety of backgrounds, which makes the conference better for everyone.

Specifically, GUADEC's and Gnome's work to include more women has really started to pay off. The official count this year was that 17% of the attendees were women, and it was obvious. And it was especially for anyone who's been attending since Vilanova in 2006, like me, where I can honestly only remember a few women attendees. The Gnome Outreach Program for Women certainly deserves a fair amount of credit here, as do the Gnome community's clear and consistent enforcement of the Code of Conduct.

Codes of Conduct/anti-harassment policies/many laws should not be necessary. But they clearly are because some people otherwise don't understand or refuse to comply with common decency. These policies really require a fairly minimal amount of effort to create and enforce, open attendance to a much wider and diverse audience, and benefit everyone as a result. Everyone wins!

We're going to have a Folks & Friends hackfest and discussion at the Desktop Summit on Tuesday at 10:00. Meet in front of Kinosaal and we'll re-locate to a room with tables.

Topics include (but are not limited to):

• User input. We'd really like to hear what you think about Folks and its Empathy and Gnome integration.


• Constructive compliments


• A follow-up on progress on the tasks we set at the Social IM/Contacts hackfest in Cambridge


• General discussion/questions/requests