Big picture (Feb 2011): Difference between revisions

No edit summary
== Asheesh's take on 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
* 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.
* 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?
** ...?
Anonymous user