Big picture (Feb 2011): Difference between revisions

From OpenHatch wiki
Content added Content deleted
imported>Paulproteus
No edit summary
imported>Paulproteus
Line 117: Line 117:


== Asheesh's take on OpenHatch.org as of today ==
== Asheesh's take on OpenHatch.org as of today ==

=== Meta ===

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.


=== Problems with the volunteer opportunity finder (and suggested changes) ===
=== 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 openhatch.org/search/:
Some problems with openhatch.org/search/:


* People who discover interesting things to work on sometimes worry that the project doesn't really care about accepting that contribution.
* 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 [http://ant.1045680.n5.nabble.com/openhatch-td2788992.html 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.
* 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". Once you've used the filtering to


* 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:
* Mentorship is quite unclear: We provide no visible differences
** Does the project have a commitment to new contributors?
** Does the OpenHatch site have the training missions relevant to the project?
** ...?

Revision as of 21:36, 6 February 2011

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.

Problems

Krzysztof's take on OpenHatch.org

OpenHatch, even tough 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 are the necessity - 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.

Resources:

Community

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 OpenHatch.org.

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 OpenHatch.org as of today

Meta

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.

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 openhatch.org/search/:

  • 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?
    • ...?