MozFest 2012: How to Work Open

by Matt Thompson (absent), so actually Gunner

Processes & Tools

The process and tools, and how things are done should be open. Etherpad – like a google doc. Collaborative, and in Mozilla, tied to conference calls.

Give guidelines, not direction.

Open Philosophy

Some are a little open, but to be truly open, everything is open not just the nice looking bits. For example, the Firefox mailing list is open. The discussion on Chrome “kicking their butts” was a public discussion.

Need to pro-actively report out, especially for offline conversations.

Community

If you’re going to work in the open, it’s about the community. Have to ready to share: ownership, control, everything.

How to contribute from day one. Make a wishlist (e.g. documentation, testing – never done). Ask for things to be added to the wishlist.

Have core community values.

Motivations

  • Pain
  • Passion
  • Fame
  • Fun

Having a Narrative

Naming the contributors, and having an ongoing story.

Give other voices a channel. Invite others into the narrative. e.g. put someone else’s story into your blog.

Governance Model

Still have to have governance though. Study other successful projects, e.g. wikipedia. Key is a benevolent dictatorship with radical openness.

Risk

Risk aversion and fear is failure before even beginning.

Study the licenses and pro-actively license your content. e.g. GPL, Mozilla

Disagreements

Leading with questions to ask one-on-one why they

E-mail and IRC suck.

Best practice is to move to audio/video if the e-mail and IRC is not working.

Setting frame for discussion. Turn it from “Do you want a vitamin?” to “Do you want the orange or purple vitamin?” Another example would be to share only benefits of two choices.

Open Corporations

Use open paradigm. For example, Twitter uses volunteers to localize, so even though it doesn’t use an open platform, it uses an open model.

But propriety, locked down systems are in the process of dying. There are companies that are open software corporations e.g. Firefox, Redhat. What really makes you special is customization, service, etc.

Start internally. It doesn’t need to be open externally. It can open within the organization first.

Learn from Others

Study the successful open companies and organizations.

Model

Model for success, status quo and failure as a win, because you have learned what not to do again.

Think ahead and think aloud.

Going Google at Ryerson University: Sync’ing Work Back to Usual

I have found some things on the Going Google site a little incomplete, so I thought I’d supplement it with a blog post.

Set up your Google Token

This is really easy. Just sign into the Apps tab, click on Activate Google Token, and hit Activate. One important note,

you will not be able to see your Google Token again after activating it the first time (and you close the window).

So, write it down in a secure place in case you ever want to sync your accounts with anything else.

Sync Apple Devices

So which method you choose depends on what you want to sync. Both will sync mail and calendar, but for:

  • Notes use Gmail option
  • Contacts use Exchange option (follow the instructions on the Going Google site)

I personally only read and reply to emails on mobile devices, so I chose the Gmail option so that I could sync Notes. Google provides instructions on using this method (it’s essentially the same process), and here are the details you need:

Name: your name
Address: full email address
Password: Google Token
Description: account display name on your device

Multiple Calendars

To sync multiple calendars, you can still do that using the Gmail option, but to change which calendars you want sync’ed:

  • sign into your Gmail account using a browser
  • then visit Google Sync for Apple to choose which calendars you want sync’ed

Getting Calendar in Thunderbird

UPDATE: If you’re having issues, it provides less integration into Thunderbird, but try ‘Google Calendar Tab’ which opens GCal like it would in a browser minus Settings/Labs.

I warn you now. Google Calendar in Thunderbird still has a number of issues. If you’re on a MAC, I suggest using Google Calendar in iCal instead. I prefer having everything in one client, so I’m willing to live with and report bugs when necessary, but who knows, I may change my mind.

Step 1: Install Lightning

The Lightning add-on page actually gives the newest stable version of the add-on (for Thunderbird 16), but the newest official release of Thunderbird is 15, so head over to the Versions list and find Lightning 1.7. Install it according to the instructions (using the Install Add-on from File option in the Add-ons settings).

Step 2: Install Provider for Google Calendar Add-on

This step is actually optional depending on what method you want to use. Google Calendar now supports using CalDAV in Thunderbird, but it’s marked as experimental.

Just search for Google Calendar in the Add-ons tab and install from there.

Step 3: Add your Calendar

If you chose to install the Provider for GCal add-on:

  1. Open your Google Calendar
  2. Click on the Settings link located in the box at the right of the page.
  3. Click on the calendar you want to use with Thunderbird Lightning or Sunbird.
  4. Copy the link from either of the two XML buttons shown at the bottom.
  5. In Thunderbird: File > New > Calendar > On the Network > Google Calendar
  6. For Location, paste the link, but change http:// to https://

For more information, visit the Provider wiki page.

If you chose not to install the add-on, follow the instructions from Google.

Testing Needed

So, I’m going to be using Thunderbird, and hopefully it’ll work out, but there are one or two things I wish it had already (like popup reminders for events others created). It is supposed to work better than through CalDAV. I’ve heard iCal has pretty good integration though so I might still switch to that if I’m unhappy with GCal in Thunderbird.

Getting Staff on Board and Using a CMS: Moving to WordPress

The hardest part of moving any website is getting staff trained and changing their workflow to actually use the CMS. We previously had a static HTML type site, so everyone would email changes to one or two people. It was a big shift to suddenly have people take care of their own content.

As part of the training session, I briefly reviewed why we moved the website to a CMS and more importantly, how it benefits our patrons. It covered the usual, shifting resources and staff time, less maintenance, keeping content current, etc.

Tutorials

I found the best WordPress tutorials for staff were the WordPress.com support articles related to creating content. The only differences come from the plugins that are installed, but in our case, this only affects the “Upload/Insert” section above the editing area.

We also have access to lynda.com video tutorials, so I suggested the relevant sections (5 + 6) of the WordPress Essential Training.

I also wrote up a short blurb on how to check for broken links in a more visual way (and for our non-WordPress pages). I basically referred them to install and use LinkChecker (a Firefox plugin).

Content Guidelines

In addition to training staff on the actual CMS, I wrote two sets of guidelines for them to follow.

  1. General Guidelines on ‘Writing for the Web’
  2. Using WordPress to Make Content Accessible (to come in a future post)

To make it easy for staff to use, I wrote it as a page on the intranet (with anchor links for a short table of contents), and also made a PDF version for them to easily print it off.

Making Staff Responsible

I think the most important step in shifting web content management from a single team to the entire staff is assigning responsibility. If no one “owns” a page, it will not be regularly reviewed. If you assign ownership, at least it increases the chance of that happening. Here are the short blurb I wrote on staff’s responsibility of content:

Page Ownership Responsibilities

While you may delegate the task of creating or updating content on any page you own, you are ultimately responsible for it. This includes:

  • Content is up to date
  • Content, especially audio/visual, conform to Accessibility Guidelines
  • Copyright is cleared for all content (if applicable)
  • Transferring ownership when needed (long term leave, end of term)

Please Note: When links are found to be broken, you will automatically be notified via e-mail. However this is not a full-proof system as many broken links will not be “marked” broken. See the ‘How to Check for Broken Links’ page for more information.

Assigning Ownership

We explicitly mention that editing of pages can be delegated, because we decided that librarians would be responsible for pages. We identified and changed each page’s author to the librarian who would become the owner.

We still have about a dozen pages outstanding in which our team maintains as needed, but we also expect that staff may edit it if they find mistakes.

The Result

So far, it’s been fairly successful (yay!). While I get calls on occasion for help, staff seem to be finding it easier to use than Drupal (which we have for our intranet), and most seem to have no problems using it.

Content on a lot of pages are being updated, though as always, it really depends on the owner. One of the problems is that we migrated the existing pages, and there’s a lot of overlap in information, which we really need to consolidate. So, making the website better as a whole will take a bit more time, but at least content is now being updated on a more regular basis.

Guidelines on Writing for the Web

So as part of the website redesign and working on making the site WCAG compliant, I wrote a couple sets of guidelines. One of them was on writing content for the web. Some of the points and the example I got from a coworkers, but most of it I just consider sensible advice. Overall, I tried to keep it fairly short and simple in the hopes that staff members will actually read it!

Writing for the Web

Web readers skim pages and look for keywords, links, and other information that will help them find what they’re looking for quickly. Therefore, when writing new or revising content:

1. Be Clear and Concise

  • Make your page title descriptive and concise, keeping it fairly short.
  • Keep sentences, paragraphs, lists, and other information short and simple.
  • Use lists wherever appropriate, especially when users have choices. Use numbered lists for complex instructions and include important screenshots.
  • Unless you’re creating a policy page, keep the entire page short (e.g. 2-3 screens worth).

 Bad Example:
To find information on citation styles, go to the Library’s Home Page, click on Research Help, then click on Citations and Style Guides and choose APA Style Page, MLA Style page or RefWorks.

Better Example:
For more information about citation styles, check the

  •  APA Style Page
  •  MLA Style Page or
  •  RefWorks

2. Speak to Your Audience

  • Avoid acronyms and “library” vocabulary when writing content for the library’s webpages.
  • Write at a Grade 7-8 level in a direct voice, using “you”. For example, use “get” not “obtain”.
  • Because users scan pages and don’t read them, information needs to be written clearly and concisely and at a reading level that doesn’t impede typical user behaviour.

3. Be Meaningful

  • Links, in particular, should be meaningful. The words of a link should tell your reader what the link is about.
  • Screen readers have the option of listing all of the links on a page, so think about whether a user would know what your links refer to out of context.
  • In addition, don’t overuse links. Only use them where it makes sense, such as for a list of resources.

The Ends do not Justify the Means: The Necessity of Code Review

Hopefully this post does not sound like just a rant as I admit that this post has come up from my frustrations from using other people’s work, but I think this is particularly symptomatic of areas where there are not always IT experts, as is the case with many libraries. I also do not boast that I always know what I’m doing, but that’s why I think it’s invaluable to have some kind of code review process.

Making it Simple

As a general rule, better to make things as simple as possible rather than using complex methods if they both achieve the same things. I’ve been told that simple and clean code is the best kind of code.

There may be efficiency concerns involved, but then that seems to be left behind in the cases I’m talking about anyway. (Case in point, our website had 5+ CSS files, not all which had clear purposes, many of which were overwriting each other’s classes, which I had to rework into two files.)

Document and Comment

While some of the simple things might be obvious and self-explanatory, I don’t think I’ve ever seen anything over documented/commented in the ‘real world’ (as opposed to school work), so more is (generally) better. I think it’s doubly important where the creation of a product/tool might be outsourced, but the maintenance of it is done in house (as frequently seems to happen), that the code can be understood by a new/beginner programmer-type person.

Too often I have looked at code recently and thought “what does this do?” or “how many pages does it affect?” While I admit that it’s not always easy to know what or how much needs to be documented, because you don’t always know who will look at it in the future and things you write yourself tend to make sense, but do at least a minimal amount of documentation and commenting.

On a side note, do not name files or functions after yourself (one former student’s name is now unforgettable for that reason and this was created months before I started).

Get Feedback

Ideally, there is someone who is an actual programmer on your team or in your unit who you can ask to take at least a quick look over what you’ve done and give you feedback on whether you’ve done it correctly. If there’s no one ‘inside’, consider asking someone on the ‘outside’.

Within a team or unit, if there is more than one programmer-savvy person, consider establishing a Review/Feedback step in the process as you typically see before code commits (if this doesn’t already exist of course).

If you really can’t get feedback from someone else, then much like editing your own writing, step back from it (for, preferably, a couple of days) and look at it with fresh eyes and ask yourself some of the important questions, but namely:

would someone else be able to step in and easily understand what your code does?

Supervising Students

I believe that all the above points apply when working with students too. It’s okay if you’re not a programmer. At least take a brief look at the code, see if commenting is done, ask about the general process/framework, ask if they think a beginner programmer would be able to understand their code easily, etc. If you ask, it will at least make him/her think about it!

My Point

The end product does not mean it is what you want. Other people also need to be able to maintain and customize/modify. This all seems so obvious, but I think it bears reminding sometimes.

Code4lib Day 3: Keynote #2 Lazy Consensus

by Bethany Nowviskie, University of Virginia

She began by expressing that it is great to have a speaker from the inside the community and lots of thanks to the invitation to talk. Then continued to talk a bit about her background and where she is coming from, including Blacklight and Hydra. She is now in the library world, where she was introduced to many issues such as open access, class issues.

Lazy Consensus

Frequently, lazy consensus gets formalized, such as in committees. When a decision needs to be made, a proposal is put forward. Some might agree, but the default answer is yes. If there are objections, then you go back, but usually just some adjustments. In order to object, people need to take the time to think and take the effort.

Some might think that there are fortunes for the bold. However, with this social contract where  we already agree that if you don’t say yes or no, “we’re not waiting on you,” inertia can work with you or against you.

Chaotic Good

Your team should work in lazy consensus. Use it to do what you know is right. How do you know what’s right? Make sure you’re one of the good guys. Act and speak up when you need to.

Ideal Conditions

  • skunkworks / R&D operations – trust them to have a plan
  • developer-driven 20% time
  • rabble-rouse… in disguise – organize smartly to fit in
  • knowing your enemies (trends, not people) – extract personalities, because usually fighting bad trends, not people
  • finding your friends (people, not just trends) – check data preservation, open access, digital humanities people

Your (Ethical) Obligations

  • always share information freely – it will fail otherwise
  • never shut out the public services and user experience
  • practice what you’d teach – think mentoring a promising novice
  • if you screw up, confess
  • try not to screw up in the first place

In Applying

If you have a bad technical plan, the library administration might not notice whether you implement it to the letter. They probably care more about the spirit than the letter of it. However, do genuinely try to explain to all levels of the organization.

Never do it alone. The word consensus is in there for a reason. You need enough people who agree on the direction to take that can be implemented reasonably and sustainably.

Keep talking to people.

Produce

If you produce, administration will have your back, but then you need to deliver a product that will make everyone look good, even the dead weights.

Involvement

The library is not involved enough in larger issues at the university, national, or government level. One common example is the research that is produced, peer-reviewed, and then sold back to the university at exorbitant prices.

It’s up to you to make contact with the leadership level of the organization. If you have a problem, put it on the agenda. Make the first move.

Shift Needed

There should a bias toward action. Stagnation is a far, far greater danger than taking measured risks.

Drive it like you stole it.

Q & A Comments

Does this reflect reality? Sometimes it is the person. – Act like it is the trend, even if it is the person. This will work better in some areas than others, but it is flexible.

Some believe that they are righteous and do not care about consensus. – Power to the people. Get enough of the staff to implement a directive.

How to deal with it going wrong? – Hard to do sometimes in formalized way, and need to do collectively.

EDIT: Bethany has now posted her version of the keynote talk on her blog.

The Whirlwind of Getting and Starting a New Job

I got a job! Mind you, it’s a contract and not a permanent job, but I think any new graduate will agree that even that is a feat when looking only within Canada, and being at least somewhat particular about what job to accept. In light of the whole process, I thought I would reflect a little on various aspects of getting and starting a job.

Prioritizing

I think it’s important for every person to decide on what they want in a job before applying to everything. Totally common sense I’m sure, but strangely for me, it took some time to really figure out what I wanted in terms of:

  • type of position – willing to take anything? including non-professional positions?
  • location – willing to move? what regions? urban or rural?
  • type of organization – libraries only or other information organizations?
  • salary – is there a minimum amount?

I’ll not spend time on the application and interview parts of the process as I’ve covered them before in other posts. I will only say that while it’s important to be flexible, you might think about whether you’re willing to spend money on flying somewhere if the organization will not pay for you.

My Interview

My interview was a particularly interesting situation as due to the available times, I ended up doing my interview after a 10-hour flight which I was sick on, 1-hour train ride, 20-minutes car ride, and a few hours to prepare and feel better. We also had a couple of technical difficulties, but I took them in stride (always have a back up plan!) as well as I could.

I also got asked a lot of questions about things that I honestly just did not know about. JAZZ? REST? Huh? Others I knew, but had absolutely no experience in, like AJAX, ColdFusion. I admitted to being unfamiliar with them and tried to emphasize that I am willing to learn (though I felt like a little bit of a broken record by the time I was done). Still, I think the important lesson is not to be daunted by the questions, since the questions are asked of all the interviewees.

Negotiating a Contract

As a new graduate, I was very nervous about negotiating my first professional contract. Thankfully, I had just finished my management class, so I took the advice of my instructor and inquired about:

  • benefits
  • relocation
  • vacation/sick leave
  • professional development
  • higher than minimum salary by considering my student work

Some things were a simple ‘no’ as mine is a contract and not a permanent position, but then I would never have known without asking. I think the last is especially important since many graduates may think that their work as a student will not count towards their salary, and while at some organizations it may not get the same level of consideration, that does not mean it will not be considered at all.

Starting a New Job

It’s important to know where you’re going and what time you’re expected the first day (oh and knowing what to bring for HR form filling), but beyond that,  I think it’s okay to just take your time getting into it. Certainly, I’ve been a little worried especially since there are various technical things to take care of, but thankfully, people seem very understanding of needing some time to settle in.

Getting a Job Also Means Not Always Taking a Job

So recently, many people I know (including myself) have been applying for jobs. Although it may be tempting as a new graduate to take any job that comes along (especially a permanent one), over the course of a couple of co-ops and student jobs, I began to realize that one of the most important aspects of a job is the work environment. This may seem obvious, but again, as a new graduate, most of us would be happy to even get an interview, let alone a hopes at a job.

Red Flags

Even as new graduates, I think we should have certain expectations and if something throws up a red flag, we should be careful. If something throws up two or three, remember to reconsider whether you would take the job.

Say you get an interview. Great, right? Well, yes… but then what if some worrisome things started popping up? If say it was a permanent position, I would expect a lot of libraries to fly someone in for a second stage in-person interview. If they’re not willing, you might look into why. Budget might be a reason in the current economic environment, but then you might also consider whether the job is worth paying hundreds of dollars for the interview.

How was the first interview? Did you get a good sense of how people were like? Did you like the way that they did it? Did you feel like you were wasting your time? If you get negative ‘vibe’, research more about the library, ask colleagues and friends if they know anything. Think about whether you would want to work there for a year, for five, for ten.

Prepare Your Own Questions

I think the easiest way to get a better feel is to ask your own questions at the end of the interview. Again, this sounds obvious, but some people do not seem to be willing to ask questions such as:

  • How would you describe your management style?
  • How would you describe the team dynamics?
  • What do you like most about working for your organization?
  • Is there anything that stands out as a benefit to working for your organization?
  • etc.

I’ve asked these questions before myself and have gotten some pretty good answers from some and some vague ones from others. Vague isn’t always bad since it depends who your interviewers are, but on a panel, there should be at least one person who can properly answer each question.

Current Job Opportunities for System Librarians

For one of my management assignments, I decided to do a job analysis of the current job opportunities.

Purpose

Looking at the various aspects of the job postings to look at where and what opportunities are available as well as what is being looked for.

Methodology

Collected all systems related librarian positions which were primarily either systems or web services from September 1 to October 15. I collected 19 job postings and tallied the various aspects including skills and areas of knowledge required and preferred.

Results

The Basics

Jobs were primarily in academic libraries (17 of 19) and a majority were permanent full time (13). The job subareas and titles differ, but were generally broken down in this way:

Systems & Technical Services 2
Systems 8
Web Services 11
User Experience 1

Jobs were also generally in the East.

Canada United States
West 1 West 4
Central 1 Central 2
East 4 East 7

Finally of the salaries that were listed the average minimum of $49,000.

Education & Work Experience

No surprise that every single posting required: MLIS degree from ALA accredited school or equivalent.

Most required or preferred at least 2 years of experience, and preferred but did not usually required experience within the area of hiring.

Graph Years of ExperienceGraph of type of experienceNote that the “type” is an indication of whether the experience needs to be in the same type of library (e.g. academic library by posting from academic library).

Duties

Many positions included non-technical related duties. The top two:

  • Reference – 37% (7)
  • General/Student Instruction – 26% (5)

Technology Related Skills & Areas of Knowledge

As the majority of the positions were web services related, there was a bit of a bias towards skills that are web related, but generally for systems, I simply found that there were less specific technology requirements and it was also more diverse. The top technology related required skills & areas of knowledge:

  • HTML/XHTML – 58% (11)
  • Web Development/Design – 47% (9)
  • CSS – 42% (8)
  • Standards & Best Practices – 37% (7)
  • Emerging Technologies, Trends, & Issues – 37% (7)
  • Usability/User Experience – 32% (6)
  • JavaScript – 26% (5)

As I said, the range was wide and included everything from server administration to proxy to analytics.

General Skills & Areas of Knowledge

What might (or might not) surprise people is that the top required skills and areas of knowledge were general in nature and not technology related.

  • Communications & Interpersonal – 95% (18)
  • Collaboration & Teamwork – 84% (16)
  • Project Management, Planning & Organization – 68% (13)
  • Problem Solving & Analysis – 58% (11)
  • Work Independently – 47% (9)
  • Leadership – 26% (5)
  • Flexible & Creative – 26% (5)

If anything, I think this trend is encouraging for new graduates as it seems that “soft” skills are more important than the technology/technical skills which frankly, many of us just do not have the opportunity to learn in library school, but with some tech savvy would be more than willing and able to learn on the job.

Limitations

There are some obvious limitations to my analysis. For one, some job postings were no longer accessible as they were closed, which meant that they were not included. For my purposes, I also left out all management positions, such as AUL and director positions.

Another issue is that how qualifications were grouped was very subjective on my part, so may not have been consistent. For example, planning and organization was grouped with project management, but results would have been different if the three had been kept separate.

Possible Future Work

It would be interesting to see what the trends are in general rather than only looking at systems positions, but that would be a much larger effort.

Hopefully this information is useful for anyone else in North America interested in systems related jobs.