Labs/Ubiquity/Meetings/2008-11-12 Planning Meeting

From MozillaWiki
< Labs‎ | Ubiquity‎ | Meetings
Jump to: navigation, search



2:00pm Pacific time


  • IRC channel: #ubiquity
  • Dial in:
    • +1 800 707 2533 (pin 369) Conf# 226 (US Toll Free/Skype)
    • +1 650 903 0800 x92 Conf# 226 (US/International)
    • +1 416 848 3114 x92 Conf# 226 (Canada)



  1. Fernando Takai (fern on irc)
  2. Gray Norton
  3. Blair McBride (Unfocused on irc)
  4. Zach (zak on irc)
  5. Jono DiCarlo (jono on irc)
  6. Atul Varma (atul on irc)


The format of the meeting was as follows: we went through all the sections of the 0.2 Roadmap Proposals document, with a different person (usually Jono or Atul) explaining what each section meant and answering any questions people had about the goals of the section. At the end of each section's discussion, we attempted to arrive at a consensus about the prioritization of individual items in each section, if we felt that it was important to do so. Once we went through all the sections, we prioritized them and selected two major areas that we felt were appropriate to work on for Ubiquity 0.2 given its current state and vision.

The meeting lasted approximately 80 minutes.

Ultimately it was decided that we focus on the following goals for the 0.2 release of Ubiquity, which should be completed by the end of 2008:

User Interface Innovation

  • We should refactor the internals of Ubiquity to allow for an external interface to easily "plug in" to Ubiquity's functionality; the context menu and the command-line interface should become UI plug-ins. Aside from making the code easier to understand, this will make it possible for other community members to create new interfaces to Ubiquity functionality through either updatable Firefox Extensions or streamable Command Feeds (more research needs to be done to figure out which of these will be most practical).
  • We should focus on enhancing the usefulness of the context menu in particular, to make it detect noun types more easily and provide better suggestions. Detection of noun types should preferably involve collaboration with Thunderbird's Andrew Sutherland, since he's in charge of adding "data detector" style support to Thunderbird and has already made some progress along this front.


  • Even core developers are reluctant to install command feeds on a whim because of the perceived threat of malicious/misbehaving code. While a social trust model will help with this, creating a security model allowing for e.g. a distinction between privileged and unprivileged commands will greatly increase the likelihood of participants to try new experiments. It's also by no means mutually exclusive from a social trust model; the two can certainly support each other. Additionally, having a security model in place is a prerequisite for more advanced kinds of "insurance" like inter-process sandboxing.


  • In addition to these, of course, we'll be tackling blockers to any of these goals, such as the fact that Ubiquity 0.1.2 doesn't currently work on Firefox 3.1 nightlies; we'll also be restoring all functionality from Ubiquity 0.1.1 that was lost in Ubiquity 0.1.2.
  • Gray Norton also brought up a good point in regards to the question of whether we want to make the stabilization of a feature set a high priority or not. The advantages of doing so are obvious, as it will mean the possibility of large-scale adoption, but the downside is that as we gain many new users, we lose some degree of freedom in regards to our ability to experiment with different ideas and approaches, as doing so can necessarily upset our user-base. As such, we decided that while it will eventually be a goal to stabilize the feature set, stabilization should generally take a back seat to innovation for the time being. In the future, it may be the case that Ubiquity's code line branches into one stable "productized" distribution intended for use by end-users while another remains an experimental playground of sorts.
  • This isn't to say that stabilization won't be a goal at all, however; in a lot of ways, the security issue we're focusing on for 0.2 is one of stability, and one so important that its absence prevents core developers from using the system to its full potential.

Additional Notes