Micro Lightning Talks: Things Mozilla Developers Need To Know

I hope to present a set of Micro Lightning Talks at the upcoming Mozilla Summit, called “Things Mozilla Developers Need To Know”. Micro Lightning Talks (which I just invented) are one or two sentences – one of instruction and one optional additional sentence of rationale – so a lot of them can fit into a conventional “long” lightning talk. The sentences have a common theme, in this case our development process.

So each Micro Lightning Talk tells people, in one or two sentences, something that it would be good if everyone on the Mozilla project knew, and why – either because it would make their own lives easier, or because it would make someone else’s life easier! Here are some examples:

  • When creating new tri-licensed files, you should use the boilerplate linked from the mozilla.org/MPL rather than copy-pasting from an existing file. This is so the formatting is right for automated tools.
  • When you change the meaning of a string in a DTD or .properties file, you must also change its name. Otherwise, localizers won’t know to re-localize it.
  • You need let the licensing team know before importing third party code into the tree. This is so we can meet our licensing obligations.

If your life would be made easier if everyone in the project knew a very simple Mozilla-development-related thing, then please post your ideas here, in one or two sentences – one of instruction and possibly one of rationale. I will consider all submissions :-)

12 thoughts on “Micro Lightning Talks: Things Mozilla Developers Need To Know

  1. * When you start using whatever smart text editor, you should prior check its encoding is set to UTF-8 without BOM. Otherwise your beautiful new creation is likely to crash miserably [to be reviewed because this is missing technical accuracy probably]

  2. @Goofy: It depends what kind of file you’re editing. Among others, I have found that “no BOM” is an essential requirement for anything whose first line starts with #! including (for instance) perl, python and unix-shell scripts, but that a BOM doesn’t harm (and is sometimes useful) for HTML or CSS. I don’t know if the Mozilla codebase includes Vim scripts (which, for recent versions of the editor, may start with #! but don’t need to) — if it does, absence of BOM is only required if they are to be loaded by the shell as executable scripts, something which for that kind of file is a rarity.

    In any case if you’re making changes in an existing file, your editor should neither add nor remove a BOM without your explicit say-so.

  3. When you’re making a wide-ranging change across the codebase, you need to check for usage of whatever you’re changing outside of just mozilla-central: comm-central, mobile-browser, camino, and so forth. Doing so is 1) polite (and formerly officially part of the Mozilla Project social contract) and 2) will save everyone lots of trouble when it comes time for your patch to land.

  4. When you make a Mozilla-wide event, don’t shut out people working their butt off for a Mozilla project. Otherwise, they may part ways with you and Mozilla may lose diversity and whole subcommunities.

    (Sorry, I may be somewhat bitter, feel free not to publish this one. I may come up with actually useful ones later, for those people who actually have been invited.)

  5. When filing bugs, set the OS to “All” if it applies.

    Set javascript.options.showInConsole to true and look in the Error Console occasionally!

  6. Phil: I have a twitter account, but I’ve never tweeted.

    Percy: Are you able to give more guidance as to how to do that?

    Dan: What is the purpose of your second point? Reporting errors to webmasters? Finding bugs in your JS patches?

  7. > Percy: Are you able to give more guidance as to how to do that?

    The idea is to be able to show videos (like the recent well produced qmo video http://quality.mozilla.org/) in local talks, making the most impact from the effort of producing them. For this we need original language (usually English) subtitles to begin with, which should be released along the video.

    From a localizer´s point of view, uploading a .srt file to Verbatim or some other Narro setup would do it. A Google doc or a bugzilla attachment are options too.

    As for how to produce the subtitles, I´m not sure what is the best way, but the Firefox 5th anniversary video and more recently, Mozilla Labs videos were both released this way, and properly localized by several communities.

    Note that I am not talking about providing videos merged with subtitles, but subtitles in a separate text files.

    An online tool for merging localized subtitles with the videos would be awesome though. At least while Universal Subtitles matures.

  8. Percy: I have a feeling that telling people they need to provide a transcript with every video they put up is going to result in fewer videos being put up.

    Is it not possible for the first translation team to do English subtitles, and then the subtitles in their language?

  9. > Percy: I have a feeling that telling people they need to provide a transcript >with every video they put up is going to result in fewer videos being put up.

    >Is it not possible for the first translation team to do English subtitles, and >then the subtitles in their language?

    Gerv, yes localization is always a burden, but the message is more about taking this aspect in consideration rather than making it a requirement for actually releasing video content.

    That said, the videos that are more interesting to localize, are *many times* the better produced, and perhaps more likely to have the necessary resources (software, people, time, money).

    Here´s my statement reworded and adding the accessibility benefit I didn´t mention before:

    * When you produce a video, consider providing original language subtitles as part of production so people can localize them for foreign and hearing impaired audiences.