0.11.09

Theme: Toward feature completeness, focusing on having the site improve in-person events

The OpenHatch site has a lot of functionality. But the pieces are not all tied together coherently. Let's change that this month, at least for the parts of the site that affect in-person events.

Here's the break-down, per section of the site, of what we can get done for that in September. See http://lists.openhatch.org/pipermail/devel/2011-September/002353.html for more discussion of what "feature-complete" might mean.

Volunteer opportunity finder

• Bug importing actually, reliably, works. Goal: Fewer than 10% of bugs are stale (>3 days).
  • The problem here seems to be that some bug trackers suffer from really high latencies, or maybe just drop packets entirely and we don't time out in a reasonable way.

Project pages

• People who've clicked "I want to help" can be managed by project managers. There is already a good mockup of this in http://openhatch.org/bugs/issue282
  • Note: This UI requires that you log in. That's suboptimal. There's a bug about making this work for non-logged-in users.
• Projects can mark some training missions as particularly relevant to a project. (I think that permissions aren't important here.)
  • Michael Stone asks: Can you work-around this by telling people to link the relevant missions in their FAQ?
• Project pages show relevant events, harvested from the events calendar
  • Showing timely events on the front and +me pages is probably an adequate substitute.

Buildhelper

• Some reasonable way to edit/create them, other than adding data to the DB manually
• The ability to change the order of steps, using the web UI
• Before the hackathon part of a campus OpenHatch event, I/helpers should fill out buildhelper steps for projects that will participate
  • e.g., It would be/have-been interesting to do that for the Debian bug squashing party
• Support for multiple buildhelpers (for different platforms)

Training missions

• Training missions are organized into meaningful categories. One suggested grouping: by which curriculum module they might be used in, during an in-person teaching event
  • Proposal: http://lists.openhatch.org/pipermail/devel/2011-September/002368.html
• All current training missions have no open bugs.
  • Michael Stone suggests an alternative: all training mission bugs have stated work-arounds.

events.openhatch.org

• Event site supports time zones
• Events are integrated into front page of main website
• Front page of the events site links to the event policy

Also, some events

• Make Boston Software Freedom Day happen

Also, publicity

• Goal: 10 projects link to the training missions from their documentation
  • (We already have two: mediagoblin and WordPress. We just need eight more!)
  • I would settle for, "Four projects tell us why they do not link to the training missions from their 'Get involved' page."

Feature-completeness things that would be nice, but not necessary for events

This section contains optional goals that would rule, but aren't strictly part of the milestone.

Volunteer opportunity finder

• You can add bug trackers to our import entirely from the web UI.
  • The big obstacle here is that the we haven't decided the UI for it. Next step: Asheesh can come up with a coherent, implementable mockup.
• When you click on "Mentors (149)", we should visually break that number down so that people understand how we calculated it.
  • Suggestion by Michael Stone: Use an infographic. Instead of a number, we can show two visual indicators: one for language, one for project. Can be e.g. signal bars, or "Lots" "a few" "some": <a href="/people/?q=can_mentor%3A%22C%2B%2B%22">Mentors [:::] []</a>

Monitoring

• We know which pages load slowly, and we publicly graph this