Empathy

Posted on by

There does not seem to be much correlation, in either direction, between the ability to write good code and the ability to communicate with one’s fellow human beings. There is some correlation between programming well and describing technical issues well, but describing technical issues is only a tiny part of the communications in a project. Much more important is the ability to empathize with one’s audience, to see one’s own posts and comments as others see them, and to cause others to see their own posts with similar objectivity. Equally important is noticing when a given medium or communications method is no longer working well, perhaps because it doesn’t scale as the number of users increases, and taking the time to do something about it.

– Karl Fogel, Producing Open Source Software

bugzilla.mozilla.org Now Supports BrowserID

Posted on by

You can now log in to bugzilla.mozilla.org using BrowserID, courtesy of a Bugzilla extension I wrote. Log out and then click the “Login” link in the header and then the orange “Sign in” button to try it.

You can do this – unless, that is, you are a member of certain particularly sensitive groups. While Mozilla has great confidence in the BrowserID technology, it does not have perfect confidence in my coding ;-) Therefore, we are restricting who can log in until we get a little more experience with my extension. Eventually, it’s possible that we might go the other way and require BrowserID for certain sensitive groups, once BrowserID primaries appear with 2-factor authentication. But that’s a little way off yet.

If you visit your permissions page, you can see if you should be able to log in using BrowserID. If you are listed as a member of the “no-browser-id” group, you shouldn’t. Otherwise, you should. The no-browser-id group is currently made up of members of the following groups: admin, bz_sudoers, autoland, generic-assignees, hr, infrasec, legal, and anything with “security” in its name.

Maintaining Multiple Versions of Documentation in a Wiki

Posted on by

Dear Lazyweb,

I know of some software, and it has documentation. I want to be able to maintain this documentation, for the general good of its userbase. At the moment, its documentation is XML files in a VCS, with their own special build procedure with prerequisites. That makes them hard to modify, and as a consequence they are often out of date and certainly not as good as they could be.

Requirement A): I’d like the documentation to be web-editable, because that makes it really easy for anyone to edit quickly, which makes it much more likely the documentation will actually be up-to-date. I want the URL for the “latest version” to always be the same URL.

Requirement B): My software has multiple versions. Once I release a version, I’d like to keep a copy of the documentation in the state that it applies to that version. It may not change much again, but needs to be able to accept bug fixes. However, trunk documentation development must continue. In other words, I need to be able to branch the documentation, check in independently to each branch, and give people URLs to either a branch or the trunk. Each version should have a URL containing the software version number.

Is there any software out there, ideally already in use by the Mozilla project, which can meet both A) and B)? A) is met by all wiki software. B) is met by all version control software. But I haven’t found wiki software with the concept of branches, and I haven’t found a VCS which can display documents prettily and has a web-based interface for editing.

These requirements don’t seem uncommon. Proprietary software solves them. Is there anything open source?

Summer of Code Applications Open

Posted on by

Student Applications for the Google Summer of Code 2012 are now open. If you are a student and want to spend your summer hacking on cool software and potentially making a difference to the lives of millions of people, read the Mozilla list of ideas (or come up with your own), and apply. Need a summer job? Flip bits, not burgers!

Established Mozilla people: if you know someone who’s a student, please get them to consider applying!

Ladder of Abstraction

Posted on by

This interactive essay teaches about system design using a “ladder of abstraction” paradigm. Two things about it are notable.

The first is the fact that his interactive teaching simulations are built using the web platform, and that’s awesome.

The second is the point he makes in the first appendix:

If a language requires a “compile” or “refresh” to show the results of a change, it even denies us interactive control. Some languages are marketed as “sketchbooks”, but a real sketching environment would, at the very least, offer basic interactive adjustment … .

Perhaps someday this will change. Perhaps IDE makers will focus on dynamic exploration instead of static analysis, rich visualization instead of line debugging. Perhaps language theorists will stop messing around with arrows and dependent types, and start inventing languages suitable for interactive development and discovery.

Until that glorious day, it is our sad but unavoidable responsibility as system designers to build our own tools.

When creating, real-time feedback is key. The interpreted nature of JavaScript, HTML and CSS means we are in a great place to build creative systems which work like this for the web platform. Some of our developer tools already built into Firefox, and things like Hackasaurus, are there or moving this way.

Old Requests: Next Steps

Posted on by

You may recall we are doing some work to try and clear the backlog of old requests (review, super-review, feedback etc.) This first involved sticking a CSV template on bugzilla.mozilla.org so we could monitor the number and age of outstanding requests. Since mid-December, I’ve been downloading a full dump of the outstanding reviews each day. Then, in mid-January, we implemented a gently nagging email, to be sent every week, reminding people about their requests older then 7 days. I have now written a script to analyse that data, to see if the email has had any effect.

Here’s what happened, looking at the most common type of request (“review”), in terms of the number of review-days outstanding[0]:

The first noticeable downtick in the graph is just after the first nagging email got sent out, and as you can see, the effect continued weekly for about a month, before vanishing, and the level plateaued again. I would interpret that as an indication that all the low-hanging fruit is now gone. And there’s still a lot of outstanding reviews – 928 older than 90 days (down from 1192).

We reduced the number of outstanding review-days. But was this due to people dealing with some old ones, or were people getting more timely with newer ones? If we do the graph again, this time ignoring all reviews older then 30 days, we can see that (if we assume the number of new review requests per day is roughly constant, which as far as I can tell it is) there’s not been much reduction in waiting time:

So what do we do now?

I think we want to get to a place where no request is outstanding more than 30 days, and where someone with contributor engagement can monitor requests as they cross that threshold and try and see why and when something went wrong. On average, 4.4 reviews a day cross the 30 -> 31 day threshold. As reviews are the most common type of request, I’d suspect it’s about 5 requests a day.

Here are some options to clarify the situation and make it better in the future (of which we could do more than one). Note that here I am talking about requests which have the ability to take an explicit requestee (such as “review”).

  1. Ban new requests “of the wind” (ones without a named requestee)
  2. Ban new requests of requestees who have not been active in Bugzilla for > N days (suggested N: 30)
  3. Cancel existing requests of requestees who have not been active in Bugzilla for > N days (suggested N: 30)
  4. Cancel existing requests on VERIFIED bugs (are there any which could validly be on such bugs?)
  5. Cancel existing requests on RESOLVED bugs (are there any which could validly be on such bugs?)
  6. Cancel existing requests which have been outstanding > N days (suggested N: 30)
  7. Find someone to examine requests which cross an N-day boundary and investigate them (suggested N: 30)

All bans would be accompanied by advice on finding an appropriate reviewer. All cancellations would be accompanied by an apologetic comment and useful advice for the patch submitter about steps to take next.

Thoughts?

[0] Note: I’m no statistician. I’m happy to give my collected data to anyone else who wants to do some analysis. Just email me. Anyone who wants a CSV dump of all current requests, it’s here.

Identity

Posted on by

Various points have been made in the mozilla.governance discussion about a possible Mozilla Code of Conduct and policy on Planet Mozilla, relating to what restrictions might be placed on appropriate topics of discussion within Mozilla. It has been suggested that “politics” or “religion” might be examples of topics which would be so restricted in some or all forums.

Graydon Hoare has also raised the question about what acts being a Christian does, or does not, ‘imply’.

This post is intended to be an explanation of where I’m coming from when approaching such questions.

Being a child of God is my identity. It’s not something I do, but something I am – or, more accurately, have been irrevocably made, by the undeserved kindness of God. It’s not an aspect of my personality and actions which I can expose or suppress at will. It can’t be laid aside. It’s not a tribal membership or a political affiliation. It’s a total transformation, and an all-encompassing worldview.

This is because the claims of Jesus Christ over the world are total. Abraham Kuyper, the Dutch politician and theologian, wrote: “There is not one square inch of the entire creation about which Jesus Christ does not cry out, ‘Mine!’” This includes me (and, for that matter, you, whether you recognize it or not).

It’s not something that I do, but it does affect everything that I do. 1 Corinthians 10:31 says “whatever you do, do it all for the glory of God“. My involvement in Mozilla is to the glory of God. (That’s where the name of my blog, Hacking for Christ, comes from.) There is no separation between “the things I do because I am a Christian, or for Christian reasons” and “other things”.

So I love my neighbour because I am a Christian. I work on Mozilla because I am a Christian. I enjoy a sunset because I am a Christian. All of these “because”s are equal. In evaluating what I do, the lordship of Jesus is never “not relevant”.

The following analogy is in no way meant to be inflammatory; I pick it because I think there’s a genuine parallel in thinking, in an attempt to help others understand my position. If I’m wrong, please be assured no offence is intended.

I am sure that many transgender people feel that their gender identity is core to who they are, in what I would suggest is a very similar way. So what would happen if we were to say to a trans person: “Being trans is a bit controversial. There aren’t many people here who are like that, and some people don’t agree with it. We’d rather you kept it to yourself. Sure, you can be trans outside the community, but please don’t discuss it or related issues here, or indicate that you are trans e.g. by your choice of gendered clothing[0], or take actions which are based on your gender-constructionalist worldview, or even show you have such a worldview”?

Such a suggestion would, I would have thought, be met with a polite explanation of how what was being requested was not only practically impossible but deeply hurtful. And perhaps some stronger words too!

My point for the discussion is: whatever we end up deciding, don’t ask me to do the equivalent.

[0] It could be that here, or elsewhere in this para, I’ve not used the right phrase; please be charitable, and focus on the overall point.

EU is 113% Democratic

Posted on by

You couldn’t make it up. The vote on an amendment to some “orphan works” legislation in the EU’s Legal Affairs committee (which has the responsibility of “safeguarding the integrity and trustworthiness of the legal framework as a whole in Europe”) was lost 14 votes to 12. Nothing wrong with that, except that there were only 23 voting members. In other words, there was a 113% turnout – a figure of which Vladimir Putin or Robert Mugabe would be proud.

When it was pointed out that these 3 phantom votes could have affected the outcome, a re-vote was nevertheless denied.

Front-runner for “understatement of the year” goes to Christian Engström, Member of the European Parliament for the Swedish Pirate Party, who said:

“What can I say? There is a lot of room for improvement when it comes to democracy in the European Union.”

“MPL Boilerplate at Mozilla” FAQ

Posted on by

The mozilla-central and comm-central MPL 2 switchovers (bug 716478) will happen soon, once I figure out how to fix the build and test errors from the tryserver. In the mean time, people who are making new patches have asked for some guidance on how to deploy the new MPL 2 boilerplate. This is it:

  • There is no need to switch the headers in the files you touch in the normal course of your work; doing so just makes merge conflicts more likely
  • When adding headers, e.g. to new files, Mozilla policy is to use this boilerplate
  • We request that you not change it, other than adapting it for another comment character

Some people have asked whether they should add the names of contributors anywhere. The answer is “no, please, there is no need”.

The MPL 2 (in Exhibit A) does permit people to add “additional accurate notices of copyright ownership” to the boilerplate. The purpose of this language is to allow copyright headers from other licenses to be included when necessary for compliance with those licenses, when portions of code are copied in. It can be used for other purposes, but Mozilla officially discourages those types of uses in our codebases.

Adding a personal copyright notice has no additional legal effect, because copyright is granted by default, and it clutters up the head of the file, because such notices cannot later be removed unless someone is very sure they no longer apply (section 3.4). They also tend to “spread” as code is copied from one file to another, because the extra notices should (although don’t always) go along. Copyright notices are not a “credit mechanism” – we have about:credits for that, or, in some projects, an AUTHORS file.

However, if a contributor feels strongly about it, we will not turn away patches which contain, in addition to their primary purpose, additional copyright notices referencing that contributor for files with significant changes. These should be of the form:

Portions Copyright (C) <year> <name>.

and should be part of their own comment block, not the main license comment block. But again, please be clear that this practice is legally unnecessary and leads to practical inconveniences.

Free Kiva Microfinance Trial

Posted on by

Kiva.org is a website which connects people with money to lend (like you or me) with recipients of microfinance in the developing world, via its Field Partners who actually make the loans.

If you join today, entrepreneur Reid Hofmann (who happens to be a member of the Board of Directors of Mozilla Corporation) is funding a free trial – everyone who joins gets a $25 loan to disburse for free. If you think this is a good way to help people, I’d encourage you to try it out :-)

Small print: although the join URL contains my public Kiva username, I don’t think I benefit if you use it. Also, you should not assess my level of involvement with Kiva via the stats on that username.

Project Guidelines

Posted on by

At some point, the number of conventions and agreements floating around in your project may become so great that you need to record it somewhere. In order to give such a document legitimacy, make it clear that it is based on mailing list discussions and on agreements already in effect. As you compose it, refer to the relevant threads in the mailing list archives, and whenever there’s a point you’re not sure about, ask again. The document should not contain any surprises: it is not the source of the agreements, it is merely a description of them. Of course, if it is successful, people will start citing it as a source of authority in itself, but that just means it reflects the overall will of the group accurately.

…

Don’t try to be comprehensive. No document can capture everything people need to know about participating in a project. Many of the conventions a project evolves remain forever unspoken, never mentioned explicitly, yet adhered to by all. Other things are simply too obvious to be mentioned, and would only distract from important but non-obvious material. For example, there’s no point writing guidelines like “Be polite and respectful to others on the mailing lists, and don’t start flame wars,” or “Write clean, readable bug-free code.” Of course these things are desirable, but since there’s no conceivable universe in which they might not be desirable, they are not worth mentioning. If people are being rude on the mailing list, or writing buggy code, they’re not going to stop just because the project guidelines said to. Such situations need to be dealt with as they arise, not by blanket admonitions to be good.

– Karl Fogel, Producing Open Source Software

Your Most Important Skill

Posted on by

The ability to write clearly is perhaps the most important skill one can have in an open source environment. In the long run it matters more than programming talent. A great programmer with lousy communications skills can get only one thing done at a time, and even then may have trouble convincing others to pay attention. But a lousy programmer with good communications skills can coordinate and persuade many people to do many different things, and thereby have a significant effect on a project’s direction and momentum.

– Karl Fogel, Producing Open Source Software