Anonymous user
0.11.09: Difference between revisions
→Project pages
imported>Paulproteus |
imported>Paulproteus |
||
(14 intermediate revisions by 3 users not shown) | |||
Line 4:
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.
* 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▼
=== 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.
* 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 [<span style="background: #FF6D3D;">:::</span>] [<span style="background: #B8FD6A"></span>]</a>▼
===
'''Status''': Partly achieved. Future plans made: use a textarea as the buildhelper editor.
* 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.▼
* Some reasonable way to edit/create them, other than adding data to the DB manually
* Projects can mark some training missions as particularly relevant to a project. (I think that permissions aren't important here.)▼
* The ability to change the order of steps, using the web UI
** Michael Stone asks: Can you work-around this by telling people to link the relevant missions in their FAQ?▼
* Before the hackathon part of a campus OpenHatch event, I/helpers should fill out buildhelper steps for projects that will participate
* Project pages show relevant events, harvested from the events calendar▼
** e.g., It would be/have-been interesting to do that for the Debian bug squashing party
** Showing timely events on the front and +me pages is probably an adequate substitute.▼
* 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
===
* We know which pages load slowly, and we publicly graph this▼
'''Status''': Time zone support achieved, but that's all.
== Feature-completeness things that would be nice, but not necessary for events ==▼
▲* 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."
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 [<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
|