OpenHatch Roadmap Sept 2012

(originally from http://piratepad.net/OpenHatchInOneYear)

Mission statement

Free, open source software loses tons of prospective contributors because it is difficult to learn how and where you can fit in. OpenHatch is an open source community aiming to help newcomers find their way into free software projects. We work toward this goal through this website and outreach events, both online and in-person.

Problem statements

• Today, it is still too hard to know how the open source world can put you to use.
• Project maintainers could be able to spend less time teaching general skills to new contributors, which would help both maintainers and the new contributors.
• Too few programmers (and other types) understand how to participate in open source projects, which leads to fewer people participating in the community. Teaching people how to be involved generally, even if they don't get involved within a short time (say, six months) of the teaching, will help them communicate with our community in the future.
• New (and old) contributors need to be more aware of those recruitment, education, and mentoring resources that already exist in FOSS. When people have questions, everyone should know where to point them.
• OpenHatch (the website) should be more stable and usable.
• Anyone interested in making the free software world easier to approach should feel comfortable approaching us and saying what they are working on and finding out how we can collaborate.

Specific goals:

Primarily-human goals

• Turn OpenHatch into a non-profit

• Hold 4-8 UPenn-style outreach events, plugged into active FOSS communities
  • These events should reach 200-300 people, and we should create surveys to find out if people who attend them are successfully getting involved (or at least learned about the community).

• The site has clear, usable documentation for how to clone our various events, like "Build it" and the UPenn-style recruitment events

• Asheesh will follow up with Ale (with whom he gave the LGM "How to grow your projects" panel talk) and write up a series of blog posts together about how projects can improve, and challenge projects to actually achieve those changes that we are asking for.

• Create some sort of "how to make your project friendly" best-practices pamphlet document thing
  • Workshops / IRC meetings on the subject would also be nice...

• Ask project leaders what other training missions would be useful, and recruit outsiders to write them
  • Missions spec should be clear and well-documented enough to make this easy

• Collaborate w. Read the Docs somehow
• Collaborate with "Contribute" (.appspot.com) also
• Collaborate with "Git Started" (or whatever it's called that ymasory likes)

• MORE METRICS! (yeah, okay, a lot of this is code, but not so feature-focused)
  • Measure how much positive impact we are having (and be able to see graphs)
    • How many training missions users have completed
    • How many projects have additional info / buildhelper steps / etc filled out
    • Some way to see how many times we point people to bugs (frames feature?)
  • Also solicit more qualitative feedback!

• Streamline OH source code so that we don't have so much stylistic inconsistency and silliness (e.g. project models in /search/)

• OH.org has solid usability
  • When people come to the main site, a miracle occurs (they know what we're about and can find what they're looking for)
  • Run site by projects, ask them what they want!
  • Smoother integration between OH and projects' own websites

• OpenHatch has an i18n translation team, and the code is refactored to support translation

Primarily-website feature goals

• More useful opportunity suggestions for new contributors
  • Add a mode to the automated volunteer opportunity finder with one where someone from the project has to manually review the bug(s) before they go live, and add a note saying, "If you do this in the next $x days, I will be there to mentor you" and/or other personal notes to new contributors (like, "You'll probably want to read this jQuery tutorial before getting started") (giant bug bucket v. "Outreach Team Featured")
  • Try to point new contributors to projects where we have good reason to believe the new contributors will have a good experience. That might mean biasing the volunteer opportunity finder toward projects with active outreach or mentorship efforts, or active OpenHatch pages, or so forth.
  • Some sort of rating system could possibly be implemented for project's response times, friendliness etc. Ideally based on objective metrics.
  • Integrate Q&A on project pages with the volunteer opportunity finder so that people can see those answers when searching for things to do
  • Make the volunteer opportunity finder help new contributors self-categorize into being (a) short tasks or (b) joining a project long-term

• Move the main focus of the website from bugs to projects.
  • Add more metrics for projects - searching, categorising via tags (tagclouds?)
  • Bugs are still good to index and categorise, but this should be a sub-feature of the projects, rather than projects just appearing as a "side-effect" of bugs being imported.

• Buildhelper exists, can be edited via the website, and is used by >100 projects (!)
  • Come up with a reasonably extendable format for a Buildhelper document that websites can create and edit on their own site and link to their project on OpenHatch.
    • One way to do this is a file they keep in source control that we update e.g. daily.
  • Ask projects to set up Buildhelper documents as part of "Build it" events that they run

• Be stable / have better plans for handling site outages
  • Figure out how we are going to handle site backups
  • Optimize the current setup so that things don't ever get broke because we run out of disk space or because there is a DDOS of people from a slashdot posting. :P

• OpenHatch forums exist and are used by actual humans

• Asheesh's "task force" feature exists and is used by actual humans

• Calendar of events in open source land that would be helpful to new contributors exists and is used by actual humans
  • Integrated w. Railsbridge / PyStar / similar programs
  • Aggregates other known calendars, but events are approved by Asheesh / somebody before they appear
  • Can also add events manually

• Provide more of our data to other people as APIs

• Project pages let project maintainers point at relevant training missions