Anonymous user
0.11.09: Difference between revisions
→Project pages
imported>Paulproteus |
imported>Paulproteus |
||
| (10 intermediate revisions by 3 users not shown) | |||
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.
===
'''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
=== events.openhatch.org ===
'''Status''': Time zone support achieved, but that's all.
* Event site supports time zones
Line 33 ⟶ 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 42 ⟶ 55:
** 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
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
| |||