Tag: mozilla

Building a learning resource directory for Mozilla

The Learning Resource Directory (LRD) is a project (overview here) I’m leading to help organize and make discoverable all the information for learning about Mozilla and how to participate in our many projects. This post introduces the project, explains the current working prototype and gives information about how to get involved.

Why Mozilla needs a Learning Resource Directory

Mozillians have created a sizeable knowledge base over the project’s 15+ year history. We have a significant number of resources documenting and teaching the tools, policies, processes and procedures necessary for contributing to Mozilla.

Unfortunately for contributors, new and experienced alike, these resources are spread across a multitude of sources. These sources include websites, mailing-list archives, forums, blogs, social media, source code repositories, videos, and more. Some of these properties are hosted by Mozilla, others are not. Some are publicly available, others restricted to volunteers who have signed an NDA or are otherwise vouched and some are reserved for Mozilla paid staff.

What these resources have in common is the absence of a central index or directory that links them all together and makes them easily discoverable. It’s this gap that we’re addressing with the LRD.

As such, the goal of the Learning Resource Directory project is to provide an inclusive directory of all learning resources across Mozilla. The complete project plan, including timeline and KPIs is available here.

Strategy and approach

In order for directories of this sort to be successful, the information they provide needs to be: complete, current, relevant and contextual.

In order to be complete and current, Mozillians not only need to have the ability to contribute freely to the directory, but they also need to feel a sense of ownership and empowerment to ensure they become an integral, active part of its curation.

In order to be relevant and contextual, the data in the directory needs to be structured such that multiple views into the data can be created easily. That is, different learner types need different views of the directory. A new contributor who first requires basic competence of our essential communication tools presents a very different use case than an active contributor looking to branch out and work with a different team.

Related projects

Two related projects to the Learning Resource Directory are Webmaker’s Web Literacy Mapper and MDN’s Learning Area documentation plan.

How the LRD differs from these projects is that the LRD is specifically about learning resources related to contributing to Mozilla and as such serves a different, if at times overlapping audience. There will certainly be some overlap between what MDN covers as part of their Learning Area plan and what the web literacy mapper covers. However, there is a lot to learn with regard to web literacy skills that has nothing to do with contributing to Mozilla. The same applies to developing web apps and other knowledge areas that MDN covers.

Do you know of other related projects or efforts? Let me know!

MozillaWiki as the platform

Taking the requirements into consideration, MozillaWiki quickly came to mind as a possible platform for creating the index. Powered by Mediawiki, MozillaWiki is already set up in a way that anyone can participate in content generation and curation. This is demonstrated by a significant active contributor base (MozillaWiki has 600+ active daily users). And, the Semantic Mediawiki extension, already in use, provides a way to store and view data in a structured manner.

A prototype

So, I set about designing and implementing a prototype of the Learning Resource Directory. It’s far enough long that it’s now ready for people to take a look, try it out and provide feedback: https://wiki.mozilla.org/Learning_Resources

Prototype of Learning Resource Directory homepage.
Prototype of Learning Resource Directory homepage on MozillaWiki
Prototype of Learning Resource entry creation form.
Prototype of Learning Resource entry creation form.
Learning Resources-Contributing to the Mozilla codebase - MozillaWiki
Prototype of Learning Resource entry page/article. Wiki users can easily edit without needing to use wikitext by clicking ‘edit with form’ button.

Attributes of a learning resource

Each ‘learning resource’ has its own wiki page. Unlike regular wiki articles, these pages are created and edited in a guided way with a form. As such, any wiki user can create and edit learning resource pages without needing to know wikitext.

Each learning resource has:

  • Name: Name or title of the resource.
  • Description: Short description explaining what the resource is.
  • Link: Link to the resource.
  • MozillaWiki page: Corresponding MozillaWiki page, if there is one. Often a resource will have a wiki page explaining more about the project and how to contribute to it.
  • Learning Area (of interest): Each resource belongs to one of six learning areas of interest:
    • Mozilla history and culture,
    • Community Building
    • Essential Tools
    • Products and Projects
    • Communication Channels
    • Cross-functional Skills
  • Access info: Is this resource available to the public, Mozillians-only, or Staff-only?
  • Subject tags: This field is used to indicate corresponding functional, product and/or subject areas. Values are separated with commas.
  • Web literacies: Which web literacies does the learning resource teach?
  • Audience level: Novice, Intermediate and/or Advanced. Some resources will apply to multiple audiences.
  • Contributor level: New, Casual, Active and/or Core. Some resources will apply to multiple contributor levels.
  • Additional Details: a free-form field which can include information that doesn’t fit elsewhere

Try editing an existing resource or creating a new one.

Viewing data

Storing learning resource data in this way allows us to create different views for the data. Rather than creating these views with a static list of links that needs to be manually updated, we can create them with semantic media queries.

Here’s the beginnings of the learning resource index home page where resources are grouped by their learning area: https://wiki.mozilla.org/Learning_Resource_Index

Learning Resource Index - MozillaWiki - Pentadactyl_379
Prototype of learning resource index page.

And here’s an example of how a team might use queries of the learning resource index to create topic and audience-specific information such as new webdev contributors: https://wiki.mozilla.org/User:Ckoehler/Demos/Webdev_Get_Involved.

User:Ckoehler-Demos-Webdev Get Involved - MozillaWiki - Pentadactyl_380
Prototype of team page with resources selectively display for a specific audience (in this case new webdev contributors).

These examples may not look like much, but keep in mind that they are dynamically created based on which resources have been entered that match the given criteria. This means that as new resources are added, or old ones updated, these pages will be updated as well.

Please get involved, and how!

Try it out and give feedback

The easiest way to get involved is to take a look at the learning resource index prototype,  edit some entries, create some new ones and then leave feedback in one of these places:

  • on the bug
  • on the talk page for the project
  • or directly to me by irc or email

Note: You’ll need to have a MozillaWiki account and be logged in to edit and create resources. You may request an account if you don’t have one already.

If you’re feeling adventures, try and create some views using semantic mediawiki queries. I’m in the process of documenting how to do this here, or you can take a look at one of the demos, copy its code and experiment with modifying it.

Guiding questions

As you’re experimenting with the LRD and developing your feedback, please keep these questions in mind:

  • Is it easy to create and edit entries such that many people across the project will get involved in helping to maintain the directory? If not, what could be made easier?
  • Do the current fields make sense? Which fields are missing? Which are extraneous?
  • How can pages for each learning resource be formatted for best readability? E.g., are the fields in the right order? Would a table layout be better? Some some fields have color-coding?
  • How can pages presenting different views of the LRD be formatted for best readability?

Join a community call

Additionally, I’m hosting a set of community calls to gather input and organize volunteers. Here are the dates of the calls:

  • Monday, 17 November at 8:00 PST (16:00 UTC) via IRC
  • Tuesday, 18 November at 13:00 PST (21:00 UTC) via Vidyo
  • Thursday, 20 November at 17:00 PST (Friday, 2:00 UTC) via Vidyo CANCELLED if you were planning to attend this session, get in touch and we’ll reschedule
  • Tuesday, 25 November at 9:00 PST (17:00 UTC) via Vidyo
  • Tuesday, 25 November at 12:00 PST (18:00 UTC) via IRC

Connection details for Vidyo meetings:

Connection details for IRC meetings:

Please join if you have comments, questions, general feedback or otherwise want to be involved!

 

An Update from the MozillaWiki Team, including a report from Wikimania London

Last week we pushed a major upgrade to MozillaWiki, one that was months in the making. This post discusses the process of that upgrade and also talks about work the MozillaWiki Team did while together in London for Wikimania.

Who is the MozillaWiki Team?

The MozillaWiki team (formerly called the Wiki Working Group) is a mix of paid and volunteer contributors working to improve MozillaWiki. It is facilitated by MozillaWiki module owner (myself) and peers Gordon P. Hemsley and Lyre Calliope (both volunteer contributors).

Results from MozillaWiki user survey informs current roadmap

This summer, OPW (GNOME Outreach Program for Women) intern Joelle conducted a survey of MozillaWiki users. Much of our current roadmap is informed by the results of this survey, including re-organizing the Main Page, making information easier to find, improving the mobile experience and making editing easier.

If you’re interested in the results of that survey, watch her presentation Improving the Gateway: Mozilla Wiki User Research.

Why upgrade Mozilla Wiki now?

The primary motivation for this upgrade was to make current the version of MediaWiki, the software that runs MozillaWiki. Running a relatively older version of MediaWiki (1.19) prevented us from utilizing newer, beneficial features as well as useful extensions that require current versions of MediaWiki.

The Mozilla Wiki now utilizes MediaWiki version 1.23, and you can read about key features and improvements here: https://wiki.mozilla.org/MozillaWiki:News/2014-08/Upgrade_to_MediaWiki_1.23#MediaWiki_changes

This upgrade was carried out in two steps. The first was to change the default skin to Vector, which we did at the beginning of August. The second was to upgrade the software and require all users to use the new skin. This work we did last week.

Why did we choose Vector and drop support for all other skins?

Creating and maintaining MediaWiki skins is a complex and time-consuming process.

The two previous custom skins used on MozillaWiki were Cavendish and GMO. Already these themes, particularly GMO, were missing features available to users in officially supported skins. Our planned upgrade would make this disparity in user experience even greater. While planning the upgrade, we determined it didn’t make sense to expend resources keeping these skins tested and up to date, nor did it make sense to continue to offer a broken user experience just to maintain familiarity.

We selected Vector as the default skin because it is the one supported by MediaWiki itself and is thereby guaranteed to be stable and fully-featured. MonoBook is another theme supported by MediaWiki and we have left that enabled and available to use for those users who want an alternative look and feel. (You can make this change on your preferences page.)

Report from Wikimania London

As I mentioned, the MozillaWiki team has been preparing for and planning for this upgrade for several months. A small group of us gathered in London this August to have dedicated time to work together together and learn about MediaWiki and how to best utilize it at Mozilla by attending Wikimania, the annual MediaWiki community conference

The group included an even mix of paid and volunteer contributors who had been regularly participating in MozillaWiki team activities: Lyre Calliope, Jennie Halperin, Joelle F, Gordon P. Hemsley, C Liang and myself.

We spent the first two days hacking on MozillaWiki and the other three attending conference sessions and hacking together in between.

Having this rare time together in one place allowed us to get a lot done in a relatively short period of time.

Tasks we accomplished include:

  • updated sidebar (only visible in Vector and MonoBook)
  • created and deployed a new Main Page
  • roadmap planning through 2015 q1
  • planned and tested an upgrade to MediaWiki 1.23
  • continued to work on category planning

During the Wikimania conference, we accomplished the following:

  • learned about upcoming changes in MediaWiki, such as the new search extension (elastic search)  and visual editor
  • generated ideas for engaging new contributors across Mozilla projects, via targeted campaigns and directed play
  • generated ideas for recognizing different kinds of contributions leveraging badges and other projects at Mozilla
  • increased awareness of the Mozilla Wiki in the larger wiki community
  • learned about ways to enable real-time collaboration on the wiki
  • invited a number of Wikimedians to join Mozilla via the Wiki Working Group, CBT, and other areas

All of this information and collaboration helped us create our current roadmap.

Improvements planned for rest of 2014

We’re really proud of the work we’ve done on the Mozilla Wiki so far, but we’ve no intention to slow down yet. Improvements we’re planning to roll out this year, include:

  • [bugzilla bug_id=”1051201″] (to restore important feature to users and make wiki easier to use)
  • [bugzilla bug_id=”1051189″] (to provide a mobile-friendly interface)
  • [bugzilla bug_id=”915187″]
  • [bugzilla bug_id=”1051204″]
  • [bugzilla bug_id=”1051206″]
  • [bugzilla bug_id=”1064994″]

An invitation to Participate

We hope you’re liking our work on MozillaWiki so far! We invite all those who would like to contribute to the wiki to join our regular MozillaWiki team meetings which are every other Tuesday at 8:30am PT (15:30 UTC). Our next meeting is 16 September. Participation details.

Driving Project-wide Community Growth by Improving the Mozilla Wiki

At the Mozilla project there are many ways to contribute. Some contributions are directly to our products: Firefox Desktop, Firefox for Android, Firefox OS, Webmaker, etc. Some contributions are to things that make those products better: QA, localization, release engineering, etc. Some contributions are to tools that help us work together better, such as: Pontoon, Bugzilla, Mozillians and the Mozilla Wiki.

I’ve long had a personal interest in the Mozilla Wiki. When I started as a paid contributor in 2011, it was my main source of information about the many, many Mozilla projects.

And I’m not alone in this. Contributor Sujith Reddy says:

The wiki page of Mozilla has got info about every project running around. For instance, being a Rep, I get questioned by many people on mails, What exactly is the ReMo program. I would reply’em with a single link: https://wiki.mozilla.org/ReMo Basically, it makes my work easier to explain people. It is Mozilla-Encyclopedia :)

And contributor Mark A. Hershberger says:

Wikis provide the best way for a community with many members to collaborate to disseminate knowledge about their shared interest…The wiki provides one of the easiest ways to start contributing to the shared work and become a contributing member of the Mozilla community.

And it’s not just volunteer contributors who find the wiki essential. Here’s Benjamin Sternthal from Web Production:

The Mozilla Wiki is an essential part of how Web Productions manages projects and involves community. The Wiki is particularly valuable for our project hubs, the central place where anyone can view information about a project without having to hunt around in various systems.

History of the Mozilla Wiki

The Mozilla Wiki has been around for a long time. According to WikiApiary it was founded on in November of 2004 making it nearly 10 years old! It has over 90,000 pages, all of which are public, and roughly 600 daily users.

During most of its existence the Wiki has been maintained by community without organized effort. Mozilla IT has supported it on Mozilla’s corporate infrastructure, and various community members, paid and volunteer, have worked to keep it as up-to-date and functional as possible.

This approach worked fairly well for a long time. But during the last couple of years, as our community has experienced incredible growth, this ad-hoc approach stopped serving us well. The wiki has become harder and harder to use when it should become easier and easier to use.

Formation of the Wiki Working Group

And that’s why a group of us came together in March 2014 and formed the Wiki Working Group. It’s been a few months and the group is going very well. We meet twice a month as a full group, and in smaller groups as needed to work through specific issues. There are 25 people on our mailinglist and meeting attendance averages 8-12, with a mix of paid and volunteer contributors in about a 1:1 ratio. Of the paid contributors, I am the only with time dedicated to work on the Wiki.

In a short amount of time we’ve made some significant accomplishments, including:

  • triaged all open bugs (>100, some open several years without updates)
  • created a formal governance structure by creating a submodule for the Wiki within Websites
  • reduced the clutter and improved usability on the wiki by eliminating new spam (spam accounts and pages previously numbered in the several hundreds per day on average)
  • improved usability of the wiki by fixing a few critical but long-standing bugs, including an issue with table sorting
  • created an About page for the Wiki that clarifies its scope and role in the project, including what is appropriate content and how to report issues

One of the long-standing bugs was to re-enable the WikiEditor which greatly improves usability by giving users an easy-to-use toolbar to allow page authoring without having to know wiki markup.

Chris More from Web Productions gave us this feedback on these recent changes:

With the re-introduction of the visual wikieditor, it has allowed non-technical people to be able to maintain their project’s wiki page without having to learn the common wiki markup language. This has been invaluable with getting the new process adopted across the Engagement team.

We’ve also worked hard to create a clear vision for the purpose of the Wiki Working Group. Early on we reached consensus that it is not our role to be the only ones contributing to the wiki. Rather, it is our role to enable everyone across the project to feel empowered to participate and collaborate to make the Mozilla Wiki an enjoyable and lively place to document and communicate about our work.

Where we’re going in 2014

With that in mind, we’re working towards the following milestones for this year:

  • increasing usability and stability) upgrading to current version of Mediawiki
  • updating the default skin (theme) to be more usable and mobile-friendly
  • improving the information architecture of the site so content is easier to find and maintain
  • engage contributors to learn to use the wiki and help us improve it by running a series of “wiki missions”
  • create compelling visual dashboards that will help us better understand and recognize wiki activity

We expect these changes to increase participation on the wiki itself considerably, and to increase community activity in other areas of the project by making it easier to document and discover contribution pathways. In this way, the WWG serves all teams at Mozilla in their community building efforts.

Chris More from Web Production again:

The use of the wiki has recently been amplified by the introduction of the Integrated Marketing process. The new process is essentially program management best practices to ensure what Engagement is working on is relevant, organized, and transparent. The wiki has been used to document, share, and to be the hub for both the process and every major project Engagement is working on. Without the wiki, Engagement would have no central public location to share our plans with the world and to understand how to get involved.

So, while our group is small, we are highly engaged. As we continue our work, we’ll enable many, many more people to become contributors and to continue contributing across the project.

How to Get Involved

If you’re interested in joining or following the Wiki Working Group, take a look at the How to Participate section on our wiki page for links to our mailinglist and meeting schedule.

If you have general feedback about the Mozilla Wiki, or things you’d like to see improved there, leave comments on this Sandbox page.

It’s the 4th of July and I’m Celebrating Independence from Facebook

I just requested that Facebook permanently delete my account.

This change is a long time coming. I’ve grown increasingly concerned about the power Facebook exercises to commodify and influence our social interactions. There’s nothing holding Facebook accountable in the exercise of this power. Aside from all of that, I get very little out of time spent on the site. Yes, it’s a way I can connect with some folks for which I’m not in the habit of calling, emailing or writing. There’s nothing stopping me from doing this, however. I have the phone numbers, emails and addresses of the folks I generally care about keeping in touch with. I do wish more folks had their own blogs, though.

Earlier in the week I posted a message on my timeline telling folks that in a few days I’d be deleting my account. I listed a few other ways to get in touch with me including twitter, my blog, and email. The other thing I did was look at the settings for every Facebook page I’m an admin on and ensure I wasn’t the only one (I wasn’t). I also downloaded a copy of my info.

Today I logged in, ready to delete my account. First I couldn’t find a way to do so. I noticed a “deactivate my account” link under security settings. I figured this was the only way, so I tried it first.

When you try to deactivate your account, Facebook presents you with a page that does everything to try and get you to keep your account active. It shows you pictures of your friends, says they will miss you and prompts you to message them. I found it particularly funny that one of the friends it showed me was Creepius the Bear (and identity created to demonstrate how creepy one can be on Facebook):

Creepius will miss me after I've left Facebook.
Creepius will miss me after I’ve left Facebook.

And then after this you must provide a reason you’re deactivating your account. For any reason you select, you’re given additional information that supposedly resolves the concern:

Facebook wants to know why you're deactivating your account.
Facebook wants to know why you’re deactivating your account.

What caught my attention was the Email opt out option, which states:

Note: Even after you deactivate, your friends can still invite you to events, tag you in photos, or ask you to join groups.

Not what I wanted, so I started figuring out how to work around this. Unfriend everyone first? Sounds tedious. Then someone asks me in IRC, “why don’t you delete instead of deactivate?” I responded saying I didn’t know that was an option. So, I searched Facebook’s help for “deactivate my account” and found this help page: How do I permanently delete my account?

I follow the link in that article, and got this prompt:

Deleting my facebook account.
Deleting my facebook account.

Much nicer, right? No guilt-trips and attempts to invalidate address my concerns. I clicked “Delete My Account”, filled out my password and captcha and got the following confirmation:

Confirmation that my account has been deactivated and will then be deleted
Confirmation that my account has been deactivated and will then be deleted

I also received confirmation via email.

So, that’s it! Assuming I don’t log in to my account during the next 14 days, my account will be deleted. Ah, freedom!

If you like the idea of doing this, but want a more gradual approach, check out de-facing, in which one person talks about their plan to leave Facebook one friend at a time.

Some OpenID Providers

While I don’t hear about it a lot recently these days, there are still some sites that I need OpenID to log in to. I had been using myOpenID from Janrain for this, but that service was retired. Unfortunately, So was my backup provider, ClaimID.

So, I went shopping for new providers! Here’s what I found:

Whatever OpenID provider you have, I highly suggest setting up delegation. OpenID delegation means you can use any website you control as your OpenID login. The delegate website is configured to use your chosen provider and you can switch anytime without having to update your login information on other sites.

How do you set up delegation? It’s easy! You just have to add the following two lines to the head of the site you want to act as delegate:

<link rel="openid.delegate" href="http://mywebsite.com/" />
<link rel="openid.server" href="https://myopenidprovider.com/" />

Replacing “mywebsite.com” with the site you want to act as delegate, and “myopenidprovider.com” with your chosen OpenID provider (e.g., openid.stackexchange.com). Make sure you have an account at the OpenID provider of your choice before doing this.

If you have a self-hosted WordPress blog, you can use this plugin instead of editing your theme files.

Thanks Aaron Parecki, Nicolas Ward, and Sumana Harihareswara ‏ for helping me compile this list. Know of an OpenID provider not already on the list above? Let me know in the comments!

Changes to Mozilla Wiki: New users must request accounts

Update 9 June 2014: To clarify, only those who wish to edit the Mozilla Wiki need to request an account. You do not need an account to read the wiki.

Note: The FAQ below is also available on the Mozilla Wiki at MozillaWiki:Accounts.

For some time now the Mozilla Wiki has been significant amounts of spam. To give you an idea of the magnitude of the problem: hundreds of spam accounts are created every week and a handful of admins each spend upwards of 4 hours per week identifying and deleting spam content and accounts.

To combat this problem, we have have implemented a change to the way user accounts are created.

Prior to this change, anyone could create an account and immediately start editing pages. After a short interval, a new user was then able to create pages as well.

Now, all new users are required to request an account and have that request approved prior to logging in and editing or creating pages.

We expect the impact of this change to valid users to be minimal. During a typical week, only a handful of legitimate user accounts are created. The rest are spam.

Below you’ll find a list of questions and answers to help aid in this transition. If you have any questions that we have not answered, please let us know.

Thank you to everyone who helped implement this change, including: Jake Maul, Jason Crowe, AlisonW, KaiRo, and Gordon Hemsley, as well as all those who agreed to help approve accounts.

FAQ

What is the work-flow for new users?

The new work-flow for new users is as follows:

  • A user visits the Mozilla Wiki and clicks Log in / create account
  • Users that don’t already have an account will click request one
  • On the request account page, the user will enter their preferred username, email address, name, bio, and additional information about themselves (optional).
  • After the user submits their request, they will receive an email asking them to confirm their email via a link. The user clicks on that link and their email is then confirmed.
  • Once the user’s request is approved, they will receive an email notification that includes a temporary password. They will be required to change their password the first time they log in to the wiki

Is the work-flow different for users who have accounts already?

No, those users will login as they always have.

What is the new work-flow for bureaucrats?

  • Once the user has confirmed their email, a notice of the request is sent to designated wiki users (a notice is also included on the RecentChanges and Watchlist pages for users who have the ability to approve).
  • The bureaucrat reviews the user’s account request and takes one of the following actions: approves, holds, or denies. Bureaucrats are instructed to approve all users they can reasonable verify are people with legitimate reason to edit the wiki (that is, not spammers or bots).

What should I do if my request has not been approved withing 24-48 hours?

Please email wikimo-admins@mozilla.org or find us on IRC in #wiki.

What should I do if I am involved in a Mozilla-related event which is likely to generate many timely user account requests?

Please email wikimo-admins@mozilla.org or find us on IRC in #wiki to let us know. We’ll do our best to have someone on hand during your event to approve requests.

Alternatively, we can create accounts for users ahead of time.

Why am I still encountering spam on the wiki?

The volume of spam received by the Mozilla Wiki has been such that we’ve not always be able to keep up with it. The change we have made to new user account creation affects the creation of new spam, but does not address preexisting spam content. We will continue to work on identifying and removing content. If you see a page that is clearly spam, let us know via IRC in #wiki.

How can I get involved with improving the Wiki?

The best way to get involved with improving the wiki is to join the Wiki Working Group (and we’d love to have you!).

Note: This FAQ also available on the Mozilla Wiki at MozillaWiki:Accounts.

Ideas for better scheduling

Recently I’ve been thinking a lot about how to make more time for meaningful project work as well as for rest. One way to free up time has been to significantly reduce the number of meetings I attend and facilitate, and to make those meetings as efficient as possible when I do attend.

This post focuses specifically on better scheduling techniques. If you find it useful, you might also find Strategies for Facilitating Better Meetings useful.

Idea 1: Only schedule meetings when there are no other effective options.

Meetings take up a lot of time. An hour long meeting doesn’t just take an hour, it takes an hour per person who attends the meeting. There’s also an opportunity cost associated with meetings. When you’re in meetings, you aren’t getting any other work done. The opportunity cost is multiplied if you have work that that requires long blocks of uninterrupted time. On days where I an hour of free time interspersed between meetings are days where I completed nothing but superficial tasks.

In general, always aim for fewer meetings. Before scheduling a meeting, ask yourself what the goal of the meeting is, and can that goal be accomplished in another, preferably asynchronous way.

There’s a caveat to this idea, however. If while discussing a topic in an asynchronous channel and you realize going round and round without progress or are otherwise not making progress, it’s time to move to a synchronous channel. This might be a video or telephone call or an IRC chat.

Idea 2: Schedule the shortest meeting possible.

Think about your goal, the number of people attending and then pick a meeting length accordingly. Many people default to hour long meetings for no other reason than it’s the default of many calendaring tools, and we’re used to thinking in full-hour increments. Take a look at your agenda. Do you need a full hour to get through it? Would 30 or 45 minutes work instead? Treat people’s time as the valuable and finite thing that it is and only ask for what you absolutely need.
zimbra default appt duration

Idea 3: Use a calendar tool to create and send a meeting invite.

Zimbra, Thunderbird via Lightning, iCal, Google Calendar, Outlook. Most email clients have this built in, so you shouldn’t have to think too hard and nor should your recipients. If you’re self-hosting email or on an otherwise non-mainstream hosted email, you probably have enough technical savvy to figure out how to send a calendar invite. Why? For those of us who live and die by our calendars, if something is not on there, it isn’t happening. Or it is, but I don’t need to know about it. Sending a calendar invite bypasses my often overwhelmed email queue and gives me the opportunity to respond in a routinized way without having to get to inbox zero.

Idea 4: Only invite those who really need to attend.

Call out attendees who are truly optional (many calendar tools have this feature, if not, use the invite body). Your agenda should give an good indication to invited attendees why they need to attend. Keep an eye out for acceptances and declines and follow-up accordingly. Don’t wait until the meeting has started to try and track down a necessary participant who didn’t respond to your meeting invite.

optional attendee field in Zimbra
optional attendee field in Zimbra
optional attendee field in Google Calendar
optional attendee field in Google Calendar

Idea 5: Manage large, group meetings using shared calendars instead of individual invites.

In the case of large, group meetings, I recommend using shared calendars instead of sending invitations to individuals or even groups of individuals. These work best for meetings where attendance is medium to very large, attendance is optional and variable, and the content of the meetings are largely updates with room for discussion. Using shared calendars allows people to subscribe to the calendars of events or groups for which they are interested in participating and gives them control over how to manage that information in their own calendars. With a shared calendar, a person can toggle visibility and choose whether or not those appointments will affect their free/busy status without having to respond to individual invites.

Public, shared calendar for CBT Education Working Group
Public, shared calendar for CBT Education Working Group

Idea 6: Share your own calendar whenever possible

Sharing your own calendar allows others to initiate meetings with you without having to go back and forth via email asking ‘what time is good.’ Doodle and other websites accomplish similar things, but take time to setup. If you share your calendar publicly and let people know about it, they can compare it with their own schedules and send an invite for a time that seems to work for both of you. If the time doesn’t actually work for you, you can decline or respond suggesting a new time. You won’t necessarily eliminate the back-and-forth with this method, but at least you’re a step closer. When someone sends you an invite, your time is blocked as tentative and there’s less of a chance you’ll be booked for something just after you’ve told someone via email you were free at that time.

What about privacy? Most calendars allow you to set not only the visibility of individual appointments (private vs public), but also to what extent you share the details of your calendar. Here’s what my public calendar , which is a combination of my personal and work calendars, looks like:

My public calendar
My public calendar

I’ve chosen to share only the free/busy status of my calendar, so all you see are blocks of time say ‘busy’ and ‘tentative’ depending on how I’ve responded to appointments. For me, this is a good mix of privacy vs the convenience of easier scheduling with other people.

Idea 7: Respond to meeting invites timely and accordingly

Whenever possible, respond to meeting invites timely and accordingly. This means accepting, declining or tentatively accepting invites that you receive. What constitutes ‘timely’ here is contextual. When I receive the initial invitation for a regular recurring meeting, I either accept all as tentative (thus blocking my schedule) or do nothing. Then at the beginning of each week, I look 2-3 weeks ahead and make sure I’ve either accepted or declined according to my availability. For meetings happening on the same day as I receive the invite, I try to accept or decline as soon as I see the invitation. For meetings happening within the week, I try to respond the same day I receive the invite. If I don’t know whether or not I can attend, I respond with a tentative acceptance and often provide the reason or a clarifying question: “I most likely have a conflict at this time, but could potentially move it. How important am I to this discussion?”

What are you strategies?

What strategies do you have to make scheduling easier, better, more productive? Leave them in the comments. Or tweet at me.

Community Building Education Update – 12 May 2014

Education & Culture Working Group

Wiki Working Group

  • Held our regular working group meeting on 6 May (notes).
  • Discussed group feedback on the draft scope and mission statement for both the Mozilla Wiki and the WWG itself.
  • Finalized About wiki.mozilla.org statement and posted for feedback. See announcement for background and please comment!

Community Building Curriculum Subgroup

  • The community building curriculum subgroup had its first meeting (notes)! During the meeting we brainstormed what kind of community building curriculum could be possible to roll-out this year. We agreed that finding existing curriculum and adapting for Mozilla would be the best way to utilize our limited resources. Between this meeting and next, we’re going to make a list of possible resources to adapt
  • A community building skills question is prepared in Mozilla Moderator and after seeing with responses from the MozCamp design session in April, I’ll announce project-wide and ask for Mozillians to submit their ideas.

Get Involved

As always, you are welcome to join me in any of these projects. Look at my mozillians profile for the best way to get in touch with me.

Upcoming meetings

Calendar file for both meetings: ics or html.