Your current filters are…
by Dawn Foster
The best thing about open source projects is that you have all of your community data in the public at your fingertips. You just need to know how to gather the data about your open source community so that you can hack it all together to get something interesting that you can really use. We'll start with some general guidance for coming up with a set of metrics that makes sense for your project. The focus of the session will be on tips and techniques for collecting metrics from tools commonly used by open source projects: Bugzilla, MediaWiki, Mailman, IRC and more. It will include both general approaches and technical details about using various data collection tools, like mlstats. The final section of the presentation will talk about techniques for sharing this data with your community and highlighting contributions from key community members. For anyone who loves playing with data as much as I do, metrics can be a fun way to see what your community members are really doing in your open source project.
by Kitt Hodsden
Hacker Dojo is a community center in Mountain View, California, for hackers and thinkers to meet, discuss, learn, create, build and play. More than a co-working space, more than an event space, and more than the chaos it could be, the Hacker Dojo encompasses the open source culture and spirit both at its start and in its continual development.
Starting from a small but passionate group of developers, Hacker Dojo has grown into one of the biggest hacker spaces in the world. The growth hasn't been without its pains, the same pains that successful open source software projects go through: How do we manage a large group of people with differing opinions and personalities? How do we inspire the many to help help the dedicated few who do the bulk of the work? How do we "indoctrinate" new members into our open and inviting culture without losing their valuable contribution? How do we handle the bad apples while building our champions?
Adopting an open source philosophy from the code to the conduct has enabled our community to grow, developing into our vision of a Silicon Valley institution. Hear of our journey of "anarchy with respect," and how open source works in physical space.
What's going on in the mind of the user as they use your system? Did they choose it, or was it chosen for them? Do they like it or hate it? How can you tell?
Users are different. Some are technical, others aren't. Some are passionate. Many are silent and enjoy (or not) your project without any community interaction.
This talk will discuss the different types of users that exist, and their motivations. It'll take a tour of some of the study around this topic.
This talk will not talk about how to change your users, get them to be more (or less) involved or more (or less) passionate; although there will be time at the end for an open discussion on that topic.
Manuals are boring, but learning is necessary.
New contributors often have to figure out how to operate the tools of a project, like IRC, git, or svn, in a highly social environment: public communication between peers. When, for example, you post your first patch to a mailing list, it’s intimidating to know that your mistakes with the tools might reflect poorly on your programming skill.
Some video games have a “training level” where you can get shot without dying. Open source could have a training level where you can learn the skills you need without getting burned.
Our community built one. The OpenHatch training missions are a group of interactive web pages for learning skills you would use when contributing to free software like using diff, patch, tar, version control, IRC, and so on. A training mission shuns “manuals” and long, boring blobs of text, and it protects its users against learning through trial by fire. We say, “Here’s a short, concrete task to perform. Interact with our web-based robot, and it will tell you if you succeeded.” You can build up your comfort in a space without embarrassment.
Project maintainers often end up teaching basic community skills to new contributors. If you can ask them to complete a relevant training mission, you can save time and have a more knowledgeable contributor base.
In this talk, you will learn about the current training missions and discuss as a group how they can be useful to the attendees. We will highlight the training mission for a version control tool in which you are an agent for Mr. Good trying to gain the trust of Mr. Bad. We will discuss the diversity ramifications of learning community skills in a safe environment. After a tour of the OpenHatch community that built them and the Django-based implementation, we will discuss the attendees’ situations with new contributor skill levels and identify the most useful training missions to build next.
by l.m. orchard
Open Source projects are most successful when they attract enthusiastic and capable contributors. But, often the first thing a new contributor to a web development project faces is a README file with a long list of instructions needed to even get the thing running.
And that’s if they’re lucky: Just as often, the necessary documentation is incomplete or missing entirely, leaving a new hacker no way to get involved without investing a lot of time up front.
This is no way to treat potential volunteers; they’re doing us favors by spending time with our projects. In return for their time, we should do the best we can to make our projects accessible and rewarding without unreasonable demands.
To that end, we can use modern tools like VirtualBox, Vagrant, and Puppet to turn walls of text into virtual machines. We can offer simple bootstraps and even bootable disk images to can get new developers started quickly, allowing them to explore a running system rather than demand they understand the complete stack before the first page view.
At ISC, we work hard to develop and maintain high quality software
that supports critical internet infrastructure. We have been working
over the last two years to move our managed open source model into
an increasingly open development methodology. We are also doing
collaborating development with organizations around the world and
have embraced agile as a development methodology. Pulling all this
off while developing and supporting critical internet infrastructure
is no easy feat; hopefully some of what we've learned in the effort
would be useful to other open source citizens.
21st–24th June 2011