Big picture (Feb 2011)

From OpenHatch wiki

How to use this page

Add a section with your thoughts. It's okay if this page is messy. It's okay if your page is a beautiful grandiose dream-like vision.


Krzysztof's take on

OpenHatch, even though it is a very young project, has proven to deliver what it promises (take me as a perfect example). Like any other young project, however, it gets some things right from the very beginning, while some areas need time to evolve (plus a lot of effort). Recent feedback from glyph is a proof of that.

The following content is my attempt to identify ideas and concepts that should work toward achieving OpenHatch's mission. Although the observation is not based on data of any kind (be it raw numbers or simple feedback), it can still prove useful as a visionary playground for future releases.

Identified issues

Open Source projects need contributors who keep the project going (doh!). There are three types of contributors that we need to clearly distinguish:

  • People who start their Open Source adventure
  • Experienced people who want to work on Open Source project to help and/or learn new languages and technologies
  • Experienced mentors who seek contributors

New contributor experience

First and foremost, OpenHatch is about lowering barriers of entry. We want to connect new contributors with mentors as fast as possible, without unnecessary hurdles in between. Currently we achieve that by:

  • mentor search
  • project search
  • bug recommendations
  • missions
  • embeddable I want to help button
  • Build helper
  • etc.

These features serve their purpose pretty well. The problem arises when user finds a project that he is willing to work on (by devoting his free time and effort). Take GIMP for an example: the Chatter is not filled in, there is no mentor for this project and a link to project's website is nowhere to find. Even if there was a link, there is not guarantee that the project's page will provide all the information required to seamlessly start contributing.

I believe that as part of the OpenHatch's mission, we should devote some 'resources' to encouraging project maintainers and projects mentors to lower that nasty entry barrier for a newcomer. Build helper is a step in the right direction, but we need to do more. For example:

  • Introduce a mechanism, which notifies free mentors that there are projects which require a mentor
  • Encourage project maintainers to fill in information on their project(s).
  • Create some sort of guidelines section on how projects can lower barriers of entry. A good example is instructing Open Source projects to have a one- to two-step automatic build process, IRC channel, clear Getting started guide or providing a list of recommended tools. More importantly, we simply have to be an embodiment of well managed Open Source project (which is hard, I know).
  • Add more missions and make them more visible
  • Provide links to online and offline resources on popular technologies (e.g. Git Community Book, HGINIT, Dive into Python 3 etc.)
  • Promote OpenHatch in academia (e.g. Open Source project as a student project)

Experienced contributor experience

Recurring contributors, who want to find new thing to work on, will most likely:

  • Search a project to join
  • Revive dead/comatose project
  • Start a project of their own

We have got the first scenario pretty well covered, by the other two simply not. When it comes to project graveyard, we can provide facilities to mark projects as dead and we can mark them as such by periodically checking bug tracker for changes (issues getting resolved etc.).

Mentor experience

This is the area that OpenHatch definitely needs to improve on. Glyph pointed out that from his point of view:

  • Experienced users do not want to create yet another project page
  • Experienced users want to get contributors involved and maybe mentor people
  • Want to find people who clicked 'I want to help' button and get them going

The last point is crucial. We need a way for mentors/project maintainers to easily manage new contributors. By manage I mean:

  • Contact them on-site
  • Provide them with information required to get started (Build helper!)
  • See who is working on what (e.g. assign new contributors to bite-size bugs on OpenHatch)
  • Provide them with feedback and guide them to become fully-pledged contributors

What works:

  • I want help button. We need to promote it more!

Features that they most likely will not use:

  • Recommended bugs

Lack of input/data

We need more input on how well we are helping people (contributors, mentors) to achieve their goals. Glyph helped to spark discussion on how we can improve OpenHatch from experienced developer's point of view, but we need more:

  • Missions: completed, partially completed, average time taken to complete
  • User profile completeness
  • Project profile completeness
  • Project imports
  • etc.

Lack of awesomeness

The site has a lot of awesome features, but does not tell how it can make users awesome. We need to change the way we communicate with new and recurring visitors to our site. We need to show some benefits that come with involvement in Open Source projects, for example:

  • Team-work experience
  • Hands-on experience with release cycles [in mature projects]
  • Practical experience with technologies (languages, version control etc.)
  • Improved communication skills
  • Being part of something awesome
  • etc.

We need to think why they came to OpenHatch in the first place and how we can not only help them accomplish their goals, but also invite more people to come.

People are lazy

Well, not all of them. But a lot of them are. I think that no one likes to yet again fill in and maintain his profile on at yet another website. We need a way to both integrate with existing services (blogs, source repositories) and also differentiate from them. The project importer feature works well (although it's very slow), but we need to do more so we convince people it's worthy to take time and maintain their profile information. We can achieve that by:

  • Integrating Twitter to their profile pages (?)
  • Integrating blogs (they also tell their Open Source story! (c) glyph)
  • Initializing new profiles with information gathered from GitHub (e.g. repository language => user's skill), Ohloh and others

Game mechanics

Game mechanics is the new hotness. In our case, they might be usefull - we want new contributors to feel that they are making progress, be it by completing missions, being promoted to project maintainer or by closing bugs.

I personally think that missions is a good place to start leveraging game mechanics. We could introduce badges or titles system based on mission completeness and difficulty. But first, we need more missions which are build with game mechanics in mind.



I think that the community map feature can be taken to entirely different level. It is already pretty awesome to discover other people in your town with similar believes and interests, but there is more to be done. Why not extend OpenHatch feature set with community events (similar to Meetup)? There are plenty of Open Source events going on, e.g. at universities, and it would be really good to promote such events on

Great, now what?

Now, the hard part. We have limited resources (for now, at least) and a lot of things to do. To make the magic happen, we have to choose very narrow focus area for each milestone, so we are able to receive feedback and decide quickly whether we are going in the right direction. Otherwise we might end up with bloated website full of features that nobody use.

Asheesh's take on as of today


I think that a good way to tackle the systematic problems with the OpenHatch site are to, for each release, think about a particular kind of user of the site, and make the site more useful to that person.

For example, I think February's release could focus on helping people improve and discuss the OpenHatch site itself. Good release goals for that release might be:

  • A solid tutorial on creating new training missions.
  • Outreach to groups who might be interested in creating training missions.
  • Outreach to projects who might be interested in using the training missions to teach something to new contributors.
  • A forum+mailing list where people discuss what they like and don't like about the site.

Actionable: Problems with the volunteer opportunity finder (and suggested changes)

The purpose of the volunteer opportunity finder is to help people make their first open source contribution. I'm most interested in the target audience of people with no solid social connection to other contributors, largely because I believe that helping those people is the ticket out of the community's diversity problems.

Some problems with

  • People who discover interesting things to work on sometimes worry that the project doesn't really care about accepting that contribution. (I've seen people join IRC and ask, "Which one of these bitesize bugs is something the project really cares about?") The volunteer opportunities are provided sorted by recency, but really it makes the most sense to sort by "Probability that the project will treat you well as a new contributor".
    • We can do that through an OpenHatch<->project commitment, where project participants who sign up can optionally sign up to an agreement that they plan to uphold in terms of how they treat new contributors. For example, they could say, "We aim to provide an initial answer to all mailing list messages within four days". Many of these commitments can be automatically evalulated.
  • Mentorship is quite unclear: We provide no visible difference between situations where someone is willing to teach a necessary skill, like a programming language, versus someone in the project is enthusiastic about
    • Similarly, see this thread about OpenHatch on the Ant mailing list.
    • It should be possible on the project page to say, "We have a mentorship program, but we don't use OpenHatch for it", and then the OpenHatch system should handle that smoothly.
  • We don't really know what troubles people run into, as new contributors. I think that when you head out to a project from the Volunteer Opportunity Finder, we should give you a top-bar that frames the bug, and it offers you a button to click indicating you want to get started. There are a bunch of data collection features we could make; we could start by asking people to post on the forum with how they're doing.
  • The volunteer opportunity finder does not index the contents of OpenHatch project pages. That's absurd.
  • We should rank the "quality" of bugs we import, and provide detailed data on how we do our evaluation so that projects know how to improve, and new contributors can make meaningful judgments about what our quality level means. I'm imagining a one-star to five-star rating, automatically generated based on criteria. Some criteria:
    • Does the project have a commitment to new contributors?
    • Does the OpenHatch site have the training missions relevant to the project?
    • Use of the OpenHatch buildhelper
  • Some people want to submit drive-by patches. Other people want to join a project and start a commitment. I think that this should be a big question as you reach the volunteer opportunity finder: which one do you want? And we can help projects make it clear which one they are interested in, also.

Actionable: Making the site more useful to existing project members who want new contributors

This is my response to glyph's feedback.

What do we want project leads to experience through OpenHatch? I think we want them to get new contributors.

  • Goal: The project page should not feel weird and alien.
    • Fix: It should be explicit what caused the project page to get created.
  • Goal: Front page should explain how OpenHatch can attract contributors to a project.
    • Fix: Replace "Create a contributors page for your project" with "Attract contributors to your project".
  • Goal: It should be easy to contact the people who say, "I want to help."
    • Fix: do what Krzysztof said about that.
  • Goal: Make "tell your open source story" seem more interesting
    • Fix: Replace it with, "Showcase the projects you've worked on". I think that text change alone fixes a serious problem.
  • Goal: The landing page (after you log in) should be useful to you, not a mess of arbitrary suggestions from the site.
    • Fix: For each major type of contributor, create a "mode" for the landing page. Through tabs at the top, you should be able to switch between these modes at will. These should mostly not require that you are logged-in.
      1. "Make your first contribution"
      2. "Attract contributors to your project"
      3. "Help make this website better"
  • Goal: Glyph wants new contributors to just end up on OpenHatch (presumably, so he doesn't have to write a website that's useful for them.
    • Fix: Um, let's do the ones above, and then figure that out.
  • Goal: glyph wishes more projects had a clear "This is exactly what you do to submit a patch" page.
    • Fix: We should make the presence of such a page part of the ranking of projects. We should make sure that we say it's okay if your page is hosted on your site. We should provide a reasonable template, and make it easy for people on OpenHatch discuss these pages on the forums. (I think we'll get some high-quality feedback from a community of people who hang out on the OpenHatch forums/mailing list just because they like to talk about what makes a good "How to submit a patch" page.)

Actionable: Help people join 'Task Forces' to make broad changes to projects

I'm imagining that there's a list of "groups" within the site. Anyone can form a group and invite people to it. Your group must name some achievable goal for its first month of existence; if it does not, the system forcefully disbands the group. (In order to stick around, your group has to provide a link to evidence that it achieved its goal. Someone from the forum or IRC has to mark the task force's goal as succeeded.) The group can only stay together for four months total; after that, its membership and achievements are frozen as a relic of the past.

Some groups I would like to see:

  • The "License headers and copyright statements" task force
  • The "Write a new OpenHatch training mission" task force
  • The "Reach out to university students to teach them about open source" task force

I think it should only be possible to create a Task Force if you are a person who started a Task Force that succeeded in its first-month goal. (Maybe we can permit people who were part of a Task Force when it started to start them, too.)

  • Actually, I think that anyone can create a task force, but it can't start its four-month existence until some other successful Task Force starter person agrees to join it.
    • Then, if the Task Force succeeds, the person who starts it gets the "I can start Task Forces" status.
  • We should provide some sort of in-group communication system for the Task Force, like a mailing list.

Rambling: Most projects don't want to put in the time to encourage participation; how can we help projects that do want new contributors highlight that?

I think the above is the biggest question for OpenHatch. As a goal, it's not important that OpenHatch have a website at all. If all the projects could just communicate consistently, clearly, and instructively to new contributors, then they would all get more contributors.

But there are some resources that make sense for projects to share. For example, projects don't always write their own git tutorials; they link to existing ones.

In addition, there are things that not all project maintainers know. Bitesize bugs are one cultural thing that some projects do that others probably haven't even thought about. Another is telling new contributors that their emails will get answered within four days.

Rambling: Events (AKA, Asheesh thinks people don't follow things they read)

I think that IRC-based tutorials on "How to run your project well?" in which people chat with OpenHatch people about how they could run their project well would go a long way.

When running the Penn workshop, I saw that there was a huge amount of interest from students who wanted to do something neat with open source.

jesstess's take on the maintainer experience

As a project maintainer, what I want is

  • a once-a-day-max digest e-mail and/or
  • a section on my Openhatch homepage listing new people who have clicked the "I want to contribute" button for projects for which I consider myself a maintainer.

You could imagine the place where the "I want to help button" lives looking like:

For new contributors:
[ I want to help ]

For maintainers:
Get notified when new people want to help [ checkbox ]

  • I like this. It would be not too hard to implement; if you have the project on your profile page then it shows the checkbox instead of the button. Also, if you have already clicked "I want to help" then don't show it (and maybe something else related to it e.g. "Started contributing? Add this project to your profile!") --Pythonian4000 21:53, 12 February 2011 (UTC)

with a checkbox on my profile for whether or not I get digest e-mails about new contributors (and maybe the list of projects you've checked the get notified box for, for easy toggling of whether or not you receive notifications). Mousing over the [ Get notified ] button explains what will happen and that you can configure settings on your profile page. You always have a "new contributors notification section" on your homepage containing people who've clicked the [ I want to help ] button for projects you've asked to be notified about. This would probably be a box with a max size, with a [ see all ] link taking you to the full page of contributors if the number exceeds the box size.

I have less clear a vision on how you'd clear out the new contributors section. There could be a [ clear all ] and individual clear buttons next to each entry, so you can keep track of people you've reached out to. There could be both a [ clear ] button and a [ contacted ] checkbox. If I were implementing this I wouldn't worry about the details for version 1.

  • The Recent Activity Atom feed currently has people who click the "I want to help" button in it, so it would also be possible to generate Atom feeds for individual projects. --Pythonian4000 21:53, 12 February 2011 (UTC)

Palhmbs's view / problems on/with

No. 1: Open Source involvement has to be both fun, and rewarding for new contributors/maintainers to stay interested.

Bug Trackers

I think it would make a huge improvement to the open source communities perception of Openhatch if we were able to add the Projects Bug Trackers quickly.

    • This probably means that more than 1 person should be working on implementing adding Bug Tracker types.
    • The new Bug Tracker GUI should go a long way to making adding a projects tracker as pain free as possible.
    • Displaying the bug tracker info with a iframe / overlay is a great idea, but needs fleshing out, we should capture metrics -
    • Making sure that the speed of the site and the space available on the site does not adverse affect the user experience. This involves monitoring the site effectively, and setting targets for expansion of OpenHatch as it gets more users and more projects (bug trackers).

Old issues in OpenHatch's Bug Tracker that seem to have been forgotten

There are a few very old bugs (under issue 100) that ought to have been closed or fixed, show our love for OpenHatch by getting these old issues sorted first.

Mentorship should be handled adequately

This is huge, new contributors usually want help quickly to keep motivated, unfortunately mentors have limited time!! So if your looking for a mentor, usually you need 1, 2 or even 3 in a particular coding language to be able to get that help.

    • Also as a mentee, I'd find mentoring more rewarding if there both parties had more opportunity to do collaborating. (Pastebin just doesn't cut it usuall) - making mentee's and mentors aware of more collaborative tools to getting things resolved.
    • If a big project already has development policies / guides in place then OpenHatch needs to be able to link to those and provide that information adequately.
    • Mentors should not only state they are available, but also how many people they think they might be able to mentor.
    • Mentors and mentees need to be encouraged to keep in touch with eachother.

PS. I've been involved with a site that concentrates solely on mentoring ...

    • The No.1 problem I've noticed is in getting the right match up ( not all people match eachothers individual personalities )
    • Keeping both parties interested in keeping up contact. Too often it's the mentee/mentors fault for not being proactive enough.

A Project Maintainers Build Helper

Let's also pro-actively get projects to simplify their build processes to break down the new contributor barrier.

Have a Openhatch Roadmap

    • Set attainable targets, and have longer milestones (every 2 months)
    • Group people's talent together ( UI , Bug Tracker, Missions, Outreach, Meetups ) - btw I like Asheesh's "Task Force" idea.

Describe different types of OSS involvement

Alot of projects I've noticed have problems finding specific types of contributors, some of them really, really need documentation helpers, but because in medium-sized projects nobody is interested in documentation, it gets missed. Other projects really need bug triagers or translation specialists etc. So - make it easier on Openhatch to allow projects to promote specific areas of these sort of bugs, or a specific tag on a bug.