Are you a technical writer -Want to work with amazing people and great team- Come join us
Published by Laura czajkowski July 6, 2012 in We're hiring!
We’re offering a unique opportunity to take part in one of the most exciting changes to affect the technology industry: the move to the cloud.
As Technical Writer in Canonical’s Launchpad team you’ll find the best way to ensure that users and developers of our software understand its benefits and how to use it. Whether it’s traditional documentation, screen casts or blog posts, you’ll find it easy to choose the right medium and you’ll have all the skills necessary to produce compelling, involving and effective content.
You’ll thrive in a rapidly changing environment where you’ll be expected to grasp new concepts quickly, develop an intimate understanding of three or four products simultaneously and determine the day to day shape of your own work.
A skilled writer, you’ll excel at finding the right information from your research and then communicating it with a casual confidence that puts people at ease and, most importantly, leaves them with the understanding they need to be effective.
Reporting to the team’s Product Manager, you’ll work as part of a fun-loving, highly skilled, global development team who produce tools including Launchpad, MAAS and Bazaar. You’ll share our love of hard work and our passion for free software, Ubuntu and the cloud.
Key responsibilities and accountabilities
- Explain our products through traditional documentation, screencasts, podcasts and any other appropriate method.
- Help ensure community and developer engagement with our platforms by documenting APIs and communicating the benefits of our various offerings.
- Tell the story of the products we develop, through compelling blog posts and white papers.
- Speak directly to the communities who use and develop our software in order to plan how you can best cater to their needs.
Required skills and experience
- Your written English is well crafted, compelling and fun. You care about how you write, as much as what you write. You’ve produced end-user documentation, developer documentation, blog posts and white papers. What’s more, you enjoy doing it.
- You have at least five years’ experience as technical writer, whether that’s professionally or as a consistent contributor to open source projects.
- You’re smart: you find no problem in learning and owning a new concept.
- When you speak, you find an instant rapport with your conversational partner or audience, and have no trouble in pitching your message appropriately.
- When you listen, you ask all the right questions and can use the answers to create content that is appropriate to your audience and the information you need to communicate.
- You live and breathe open source technology. You know the industry, understand the community and share the ideals. You know your OpenStack from your Intel, your ARM from your aaS and your Bugzilla from your Git.
- You’re equally comfortable dealing with people in person, by phone, over email or using IRC and other remote communication tools.
- You are willing to travel internationally, for periods of one or two weeks and occasionally longer, for conferences, developer-oriented meetings and sprints.
Desirable skills and experience
- You’ve worked as part of team building cloud-related technologies or developer tools.
- You use Ubuntu and are familiar with Launchpad and Bazaar.
- You have a familiarity with one or more of the following:
- IaaS platforms such as OpenStack, AWS, Eucalyptus
- Ubuntu Server, particularly in cloud contexts
- ARM server
- distributed version control systems
- a form of Linux packaging, such as .deb or .rpm
- Python development
- You have taken an active role in an open source software project and understand the dynamics, demands and constraints of working in a distributed community of volunteer and paid developers.
- You’ve worked as part of a distributed team and can demonstrate the self-motivation and discipline required in such an environment.
Apply online, if you have any questions drop by #launchpad
We’re hiring software engineers to work on cloud projects in Canonical
Published by Laura czajkowski in We're hiring!
Location: Flexible. If home based, reliable broadband connectivity required.
Role Summary
Do you want to be one of the engineers building the infrastructure at the heart of the cloud revolution?
At Canonical we’re developing technologies that are key to the transition to the cloud, with Ubuntu as the number one cloud operating system. We are looking for a fun, talented software engineer whose ingenuity, self-motivation and engineering skill have contributed to a shining track record of successful projects.
Alongside four or five other engineers, you’ll be part of an agile engineering squad, in Canonical’s Launchpad team, working in either a new development or maintenance role on a different cloud-related project every six to nine months. Your work will touch projects such as OpenStack, MAAS, AWSome and the Launchpad SaaS developer tools platform.
To succeed you’ll need to share our love of hard work and our passion for free software, Ubuntu and the cloud.
Your energy and enthusiasm will be key to delivering the project, and to making the squad fun to be a part of.
Key Skills and Accountabilities
- Develop new features in existing web or cloud applications or even start new ones from scratch.
- Participate in the maintenance of the portfolio of applications maintained by the Launchpad team (a group of six development squads).
- Collaborate within a small team of four to five engineers to design and deliver agreed features on an established schedule.
- Ensure high quality results from across the team by participating in established team practices such as code review and testing.
- Maintain readable developer-oriented documentation.
- Coordinate regularly with the rest of the Launchpad team.
Required Skills and Experience
- You have extensive experience in development of web applications using a major object or oriented application framework
- You are proficient with the technologies powering the web such as Python, HTTP, HTML, CSS and JavaScript
- You live and breathe open source technology. You know the industry, understand the community and share the ideals. You know your OpenStack from your intel, your ARM from your aaS and your Bugzilla from your Git
- You are well experienced with at least one web application framework, such as Rails, Django, Zope/Plone, Pyramid, Turbogears, Web Objects, etc
- You are well experienced with at least one JavaScript library/framework such as YUI 3/2, jQuery, Dojo, MooTools, or Prototype
- You love easy to use software and pay particular attention to making your applications a joy to use
- You have created stellar user interfaces using JavaScript, HTML and CSS
- You’re skilled in object-oriented programming in the Python language
- How people solve complex problems in software fascinates you. You also know that reliable and maintainable code are essential to long-term success. You’re familiar with writing about what needs to be done, as well as test-driven development and other “agile methods
- You have strong spoken English communication skills, and can communicate clearly in writing, including email and IRC environments.
- You have a good sense of humour and enjoy building a fun working environment with your colleagues.
- You are willing to travel internationally, for periods of one or two weeks and occasionally longer, for conferences, developer-oriented meetings and sprints
Desired Skills and Experience
- You are familiar with interaction design and have contributed to the user interface of a leading web application.
- You have built and managed a community around an open source project
- You have contributed code to an open source project
- You understand the basics of one or more of the following:
- laaS platforms such as OpenStack, AWS, Eucalyptus
- Ubuntu Server, particularly in cloud contexts
- ARM server
- Services Oriented Architecture
- Message-passing systems
- Distributed version control systems
- A form of Linux packaging, such as .deb or .rpm
- You are familiar with Agile/Lean development practices
- You enjoy exploring new languages like Go, Haskell or Clojure
- You have system programming experience in C
- You worked as part of a distributed software engineering team and can demonstrate the self-motivation and discipline required in such an environment
Apply online, or talk to us in #launchpad-dev if you want to see what we do!
Meet Martin Packman in the Blue squad
Published by Laura czajkowski July 5, 2012 in Meet the devs
Laura: What do you do on the Launchpad team?
Martin: I’m on the newly created Blue squad, and we’re on the nebulous task of maintenance at present. I’m also on loan doing some juju development work.
Laura: Can we see something that you’ve worked on?
Martin: You can see everything I’ve worked on. Well, all the things where I’ve had the convenience of using launchpad rather than having to send patches by email.
Laura: Where do you work?
Martin: From home like most of the other developers in Canonical. I’m only a few hours away from the London office, but haven’t been there since the relocation.
Laura: What can you see from your office window?
Martin: A weeping birch, and whatever feathered things perch atop. Sky, often blue, generally grey. Houses on the other side of the road. This time of year, swift acrobatics.
Laura: What did you do before working on the Launchpad team?
Martin: Bazaar! Which is still a pretty key part of how Launchpad works. In between I worked on a cloud api proxy, which has sensibly been dropped in favour of just using the native openstack api.
Laura: What did you do before working at Canonical?
Martin: Whatever came up, computer support and some development work.
Laura: How did you get into free software?
Martin: Mostly from using it, having it break horribly, and getting the urge to make the code actually work.
Laura: What’s more important? Principle or pragmatism?
Martin: Principle is more important, otherwise you compromise all the way to the other side. But you need some pragmatism to get anything done at all.
Laura: Do you/have you contribute(d) to any free software projects?
Martin: I’ve tended to submit changes for anything I use heavily at the time, and to various bzr related projects. I’d use this space to hector some maintainer who’d been sitting on a patch for ages, but everyone’s been organised of late.
Laura: Tell us something really cool about Launchpad that not enough people know about.
Martin: It actually works pretty well in lynx!
Laura: Is there anything in particular that you want to change in Launchpad?
Martin: You mean apart from making it work better in lynx? I’d like bug search to suck less.
Meet Vincent Ladeuil who works in the Blue Squad on Launchpad
Published by Laura czajkowski July 3, 2012 in Meet the devs
Laura: What do you do on the Launchpad team?
Vincent: Maintenance. Although I’m eagerly waiting for the sprint with gmb to get some hints on how to handle the beast 🙂 In the mean time, I’m focusing on fixing bugs and making the udd importer more testable.
Laura: Can we see something that you’ve worked on?
Vincent: https://launchpad.net/bzr and http://babune.ladeuil.net:24842/
Laura: Where do you work?
Vincent: At home
Laura: What can you see from your office window? 
Vincent: The venerable Strasbourg post office, lovely old stones.
Laura: What did you do before working on the Launchpad team?
Vincent: Developing bzr.
Laura: What did you do before working at Canonical?
Vincent:Various service/consulting work for > 20 years, including some episodes at software editors.
Laura: How did you get into free software?
Vincent: With pleasure
I think the most important event was in 1993: I encountered a blocking bug in g++ related to C++ templates (way before it was standardized). That was a roadblock, no work-around and it was Friday afternoon. In despair, I posted a reproducing case in the related newsgroup. When I came back to work on Monday I got an email telling me the bug was known *and* fixed *and* where to get the patch for the compiler.
That was a light-bulb instant: free software support could be far superior to commercial software support !
One week later, I got a second email asking me if I was out of trouble… Amazing, not only did I get a fix faster than I could have dreamed, but the guy *came back* to ensure I got it…
I never looked back.
Laura: What’s more important? Principle or pragmatism?
Vincent: Both are important. If you forget one, be prepared to pay the cost. Both are dangerous too if you forget the other:
– being pragmatic only most often means you’re adding to your tech debt or rely on others to finish your work,
– respecting principles excessively means you never deliver anything.
Laura: Do you/have you contribute(d) to any free software projects?
Vincent: bzr is my most important contributions (including a few plugins). I’ve occasionally sent patches to gtk, perl modules and various other bzr upstream projects.
Laura: Tell us something really cool about Launchpad that not enough people know about.
Vincent: Pass 🙂
Laura: Is there anything in particular that you want to change in Launchpad?
Vincent: Make it easier to test against for all projects that rely on it (I’m probably biased here as the udd importer severely suffer from not being able to properly test interactions with launchpad (read *and* write (branch creation mainly)).
Meet Jelmer Vernooij of the blue squad
Published by Laura czajkowski June 29, 2012 in Meet the devs
Laura: What do you do on the Launchpad team?
Jelmer: I’m one of the blue haired freaks on the Launchpad blue squad, although my hair isn’t actually blue – I’m sure we can fix this at the next squad sprint. At the moment, we are working on maintenance: fixing
critical bugs in Launchpad and dealing with incidents.
Laura: Can we see something that you’ve worked on?
Jelmer: I’ve contributed quite a bit to the code behind recipe builds. Most of my work has been on the backend though, not directly user-visible.
Laura: Where do you work?
Jelmer: Like most of us I work at home, which in my case is in Utrecht, the Netherlands. Occasionally I cowork with other teleworkers in Utrecht.
Laura: What can you see from your office window?
Jelmer: At the moment, I see just a big sad drapery made out of rain. On brighter days, I look out on a park and a canal.
Laura: What did you do before working on the Launchpad team?
Jelmer: The Blue squad, which I’m currently in, was originally the Bazaar team. Before that, I worked on the Launchpad team too. This was back in the days when there were no squads, but teams – I was in the Soyuz team. The inimitable Matt Revell interviewed me back in 2010:
Laura: How did you get into free software?
Jelmer: A long time ago, in high school, I ended up maintaining a few server machines running FreeBSD and Samba. After hitting some bugs, a dive into the source code followed to see what I could fix. I’ve been involved with various free software projects ever since.
Laura: What’s more important? Principle or pragmatism?
Jelmer: Do I really have to choose? That’s not very pragmatic.
Laura: Do you/have you contribute(d) to any free software projects?
Jelmer: Beside Launchpad, the main free software project I am involved in is Samba. There are several other projects that I have made major contributions to, such as Bazaar, CUPS, Wireshark, OpenChange, BitlBee.
I’m a Debian maintainer and Ubuntu uploader, mostly for projects I am involved in upstream. This knowledge comes in handy when working on the archive side of Launchpad.
Laura: Tell us something really cool about Launchpad that not enough people know about.
Jelmer: https://launchpad.net/builders lists all the Launchpad builders and
the mischief they are up to.
Laura: Is there anything in particular that you want to change in Launchpad?
Jelmer: It would still be really nice to have dashboards of some kind in
Launchpad. There is even a LEP.
Creating teams on demand
Published by Curtis Hovey June 25, 2012 in General
We want the project maintainer to be the default party that the project shares private information with. The problem at the moment is that Launchpad does not know how to set a team as the project maintainer during setup. Improper project setup is the root cause of most cases where information is disclosed to the wrong people. We need to improve project registration and setup to ensure users can ensure private information is managed properly. This issue is complicated by a very old issue, it is not possible to register a team at the moment you discover you need one. Launchpad must let me register a new team that will maintain my project when I first setup my project.
The Purple Squad discussed what we can do to simplify team registration and perform the registration in any page that allows you to set a team. We discovered several areas where we can make improvements.
- Do not ask for non-essential information like contact address.
- We can simplify the team membership policy language.
- We can fix the confusion about membership renewal.
- Launchpad can pre-fill the form with sensible defaults when the team will be used in a role.
Ian put together a demonstration to prove we could extend the person picker to also permit you to register a team.
When you want to set the project maintainer to a new team, Launchpad will ask you to confirm its suggestions for the Launchpad Id, display name, and membership policy. You can change the values, but most of the time you will choose to continue, and Launchpad will register the team and place it in the role.
Fixing a simple bug in Launchpad – A screencast
Published by Graham Binns June 20, 2012 in General
When I ran the Launchpad Development Clinics at the last UDS, I was asked if I would give a presentation on how to fix a simple bug in Launchpad. This sounded like a great idea – after all there’s a lot of parts to the Launchpad development process that apply to every single branch you ever write, so it seemed well worth the effort. Rather than a presentation, though, I figured a screencast would be of more use, so here is just such a screencast. If you’ve got any questions or comments, don’t hesitate to get in touch.
Meet John Meinel – Blue Squad leader and Papa Smurf
Published by Laura czajkowski in General, Meet the devs, Teams
Laura: What do you do on the Launchpad team?
John: I’m the team lead for the Blue squad. Right now our squad is on Maintenance, so I generally do the coordination work of our team with other teams and the system administrators.
Laura: Can we see something that you’ve worked on?
John: Before we switched to maintenance, our team was focusing on doing Bazaar work. Within the more recent time, we’ve done stuff like fixing up the Ubuntu Distributed Development package importer, and getting translations for Quantal started for Launchpad.
Laura:Where do you work?
John: I work from home in the Netherlands.
Laura: What can you see from your office window?
John: We have a forest near our house, and some of the other neighbors houses.
Laura: What did you do before working on the Launchpad team?
John: As mentioned, we were focused on development of Bazaar, though arguably that was still part of the Launchpad group (not officially, but in spirit).
Laura: What did you do before working at Canonical?
John: I worked for a company developing medical imaging algorithms, mostly for detection and visualization of disease.
Laura: How did you get into free software?
John: Our team wanted to use something better than CVS for development. At the time SVN was pretty hard to set up, and there was just the beginnings of a couple of tools for distributed version control. I got into tla at the beginning, and was happy when Canonical started Bazaar, and I was able to hack on it.
Laura: What’s more important? Principle or pragmatism?
John: I’m a fairly pragmatic engineer. I think it is good to use principle as a guideline, but in the end if the work isn’t in the hands of people using it, it is providing no benefit and is arguably wasted effort.
Laura: Do you/have you contribute(d) to any free software projects?
John: Well, Launchpad and Bazaar are both pretty clear things (and tla a little bit before that). I also developed some other tools while here at Canonical. Such as Meliae for profiling python memory.
Laura: Tell us something really cool about Launchpad that not enough people know about.
John: The UDD package importer turns the changes from debian packages into real VCS branches that you can do lots of nice stuff on. (annotate the history, log the history, see the graph over time, etc.)
I think we are at about 90% coverage, and you can do “bzr log ubuntu:package” to find out the recent history for a package in ubuntu.
Laura: Is there anything in particular that you want to change in Launchpad?
John: My own personal project with launchpad is improving the connection handling when accessing Bazaar branches. Right now it is approximately 3s just to do the ssh handshake and start talking to codehosting. I have some improvements that should decrease that significantly, but we encounter some strange hanging bugs that are only reproducible in production. And LP’s commitment to having minimal user-visible downtime is particularly problematic for SSH connections. A single HTTP request is less than 5s, but an SSH connection can legitimately be active for an hour if accessing a large project.
Privacy and security replaced by information type
Published by Curtis Hovey June 18, 2012 in General
All users can now see the information type section that replaces the privacy and security section shown on bug and branch pages. This change allows users to clearly state the kind of information a bug or branch contains. Launchpad will soon permit project maintainers to share information types instead of managing individual bug and branch subscriptions. Project maintainers can see a link on their project’s front page to the “Sharing” page. Sharing lists all the users and teams their project shares some private bugs and branches with. This list might be surprising. Launchpad Beta testers will soon be able share and unshare kinds of information to simplify management of whom the project discloses private information to.
See Reimaging the nature of privacy in Launchpad for more details.
Pondering how sharing changes project roles
Published by Curtis Hovey in General
The Purple Squad recently discussed how the forthcoming sharing feature changes project setup. Sharing will allow project maintainers to share kinds of information with users and team. This feature separates access to private information from bug and branch subscriptions. Maintainers do not need to manage hundreds of subscriptions, users do not needs to block unwanted email.
Before sharing, direct subscriptions were the only way Launchpad knew which users the bug or branch was disclosed to. Launchpad would subscribe the maintainer, or the team in a designated role to ensure someone could work with the information in the bug or branch. The subscribed users would then be responsible for subscribing other users and team so that everyone who needs to know about the information could work with it. Most users subscribed to private bugs and branches get unsolicited email. Each user’s project, series, and milestone subscriptions are ignored.
After sharing, subscriptions to projects, series, and milestones will just work. If a private bug matches your project subscriptions, and that kind of information is shared with you, you will get the email. You will be able to subscribe to kinds of information, such as embargoed security.
The security contact role
The security contact role is obsoleted by sharing. It can be removed.
The security contact exists to tell Launchpad which team to subscribe to embargoed security bugs to ensure the information is disclosed to someone. The role does not convey any other privileges. Only one team could be in the role; it was not possible to tell Launchpad that embargoed security bugs should be disclosed to several teams. Sharing allows the maintainer to specify which teams embargoed security information is disclosed to.
The bug listing page implies that no one has access to security information when the role is not set. This was never the case. Launchpad subscribed the maintainer to the bug if no one was in the security contact role. Maybe Launchpad should show a notice to maintainers when it detects that no one is subscribed to get security mail? This presumes email is how users want to be notified. It think this is nice to have, but not a requirement. I would prefer Launchpad to present a log of recent activity on its pages and send me emails that summarise important activity when I have not visited the pages recently.
The bug supervisor role
The bug supervisor looses its private bug responsibilities after sharing. It is still useful to delegated additional bug editing privileges to a team who does not drive development decisions.
The bug supervisor role will be used less often. Most teams currently in the bug supervisor role are also in the driver or maintainer role. Launchpad required maintainers to set the bug supervisor role to ensure that those that plan released can also see the private bugs. Small projects will not need the role. It will only be needed by projects that want to expand the number of contributor who can triage bugs without expanding the number of people who do release management.
The maintainer role
The maintainer role is unchanged by sharing. Well, it responsibilities are unchanged, so we must ensure that the project shares private information with the maintainer by default.
When a project is registered, Launchpad must share each kind of private information with the maintainer. This is rule is not as simple as you might think. Many projects are registered by a user, who sets a team as the maintainer during setup. From Launchpad’s perspective, the project has transferred the role. Launchpad does not know what to do [1]. Some maintainers do not want to work with private information, they delegate to other teams. Launchpad cannot presume that changing the maintainer means changing who private information is disclosed to. Maintainers can always choose to share the information with themselves.
Launchpad’s project setup workflow is incomplete. There are two screens that gather the basic information, but you can set additional information on the project front page. There are five pages to configure how the project uses Launchpad that maintainers should review during setup, but we did not have the time integrate them. We do not want users to do more work. Instead we want Launchpad to present just the essential information and have sensible defaults.
Reimaging/completing project setup is out of scope for the sharing feature, but it might be in scope for the Purple Squads next feature, private projects. During setup, Launchpad needs to know who the maintainer will be and share private information with them. We can consider this work as an enhancement to maintain expected behaviour. We will do this work as a part of the sharing feature. When we work on private projects, we can explore what else project setup and reconfigure needs to do to ensure that information is disclosed to the proper teams. Private projects will also entail making projects public, which means reconfiguring the kinds of information a project has.
[1] If you have ever changed the bug supervisor or security contact, you might know of the pain I am alluding to. Bang head against desk, scream at computer, weep, set aside a few weeks of your valuable time to update all bug subscriptions yourself so that the new team can do it’s job. This whole scenario is implicitly fixed by sharing since subscriptions are not used to manage access.
