User:Mchua/Braindumps/getting feedback for builds: Difference between revisions
No edit summary |
|
(No difference)
|
Revision as of 15:21, 19 December 2009
what
An open community feedback session (or sessions) for gathering feedback from all the deployments using XOs, particularly end-user/community/non-technical feedback. This feedback will be translated afterwards into items that developers can implement. It is intended to be before the 9.1.0 design discussion in Boston in mid-November.
why
Greg Smith is making heroic efforts to keep everyone in the feedback loop in terms of what deployments need and what developers should implement for the XO build.
We need to help.
what 1cc should walk away with
The artifact we should create together is not a product (9.1.0) but the process we're going to use to get there. At the end, we will publicly release the URL of a webpage containing (or containing links to)
- The list of needs identified (everything available in English and Spanish, try to translate into other languages). Each item here will include
- What is the need? What is not happening with children learning in deployment classrooms right now?
- Who needs this? (Which deployment, which classroom?) Includes contact info for either the person(s) who need this, or their representative for the 9.1.0 release cycle.
- What kind of effort/resources would be required to fill the need?
- What is happening with this need? (Is it going to be done? If not, why not? If yes, who is doing it, what is the first step they are taking, how can anyone at any time find out what they are doing, and how can they be contacted?)
We will also produce a webpage that contains (or contains links to)
- a list of existing feedback loops from deployments to the OLPC volunteer community and 1cc
- instructions for finding out about and using these feedback loops
- instructions for changing how a feedback loop works, or listing what loops are active/inactive
what groups should walk away with
- Each group/should have a public statement of what it needs, and why, and how they're going to make it happen.
- Each group should have a public statement of what help it can offer - over and above what it immediately needs.
- Each group should have a publicly posted way to modify the above. As little bottlenecking as possible.
The goal is for groups to leave with the feeling that they have been heard (because they have been heard), and that they understand what is happening with the things that they asked for, and why.
Even more important is for groups to know that they are empowered to fix their own problems, which problems are solvable with them without 1cc's intervention, and that they can see a clear path to making it happen with the resources available.
Questions
More concrete questions to ask people at such an event:
- It's a month after 9.1.0 launch date. What do you want to have happening in your programs?
- How are you going to know that this is happening? (Criteria of declaring this "success"?)
- Ok. What features, exactly, in the system do you need to have that happen? Technically?
- What is the first step that you need to take to implement this? (How far out this line of planning can you go - how far do you need to go to know if it is possible?)
Implementation
this is a strawman.
Stage 1: Feedback gathering
Structured
Greg!
Unstructured
Open ended