0.11.09: Difference between revisions

Content added Content deleted

Inline

Latest revision as of 17:01, 3 October 2011

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

Status: Partly achieved. Parallel bug import alone didn't fix the staleness.

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.

Buildhelper

Status: Partly achieved. Future plans made: use a textarea as the buildhelper editor.

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)
Save checkbox status / save people's progress through the buildhelper

Training missions

Status: Achieved.

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

Status: Time zone support achieved, but that's all.

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

Status: Success.

Make Boston Software Freedom Day happen
Extra: Boston Python Workshop 4 happened.

Also, publicity

Status: List of possibly-interested projects made, but that is all.

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."

Off-theme things that would be nice

This section contains optional goals that would rule, but aren't considered show-stoppers for the milestone.

If you want to work on these, we would love to ship them during September.

Volunteer opportunity finder

Status: No progress.

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 or someone 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>

Project pages

Status: Big UI suggestions made for project pages, but that is all.

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.

Monitoring

Status: No progress made.

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

@@ Line 6: / Line 6: @@
 === Volunteer opportunity finder ===
+'''Status''': Partly achieved. Parallel bug import alone didn't fix the staleness.
 * 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 ===
+'''Status''': Partly achieved. Future plans made: use a textarea as the buildhelper editor.
 * Some reasonable way to edit/create them, other than adding data to the DB manually
@@ Line 26: / Line 21: @@
 ** e.g., It would be/have-been interesting to do that for the Debian bug squashing party
 * Support for multiple buildhelpers (for different platforms)
+* Save checkbox status / save people's progress through the buildhelper
 === Training missions ===
+'''Status''': Achieved.
 * 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
@@ Line 35: / Line 33: @@
 === events.openhatch.org ===
+'''Status''': Time zone support achieved, but that's all.
 * Event site supports time zones
@@ Line 41: / Line 41: @@
 == Also, some events ==
+'''Status''': Success.
 * Make Boston Software Freedom Day happen
+* Extra: Boston Python Workshop 4 happened.
 == Also, publicity ==
+'''Status''': List of possibly-interested projects made, but that is all.
 * Goal: 10 projects link to the training missions from their documentation
@@ Line 50: / Line 55: @@
 ** 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 ==
+== Off-theme things that would be nice ==
+This section contains optional goals that would rule, but aren't considered show-stoppers for the milestone.
+If you want to work on these, we would love to ship them during September.
-This section contains optional goals that would rule, but aren't strictly part of the milestone.
 === Volunteer opportunity finder ===
+'''Status''': No progress.
 * 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.
+** The big obstacle here is that the we haven't decided the UI for it. Next step: Asheesh or someone 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 [<span style="background: #FF6D3D;">:::</span>] [<span style="background: #B8FD6A"></span>]</a>
+=== Project pages ===
+'''Status''': Big UI suggestions made for project pages, but that is all.
+* 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.
 === Monitoring ===
+'''Status''': No progress made.
 * We know which pages load slowly, and we publicly graph this