Community approval process

NOTE: The contents of this page are not set in stone, and are subject to change! This page is a draft in active flux ... Please leave suggestions on the talk page.

The text here has been copied directly from the old developers program talk page, and this needs revision, editing, and generalizing to become a community approval process for projects in general.

Community driven implementation proposal

The current infrastructure for the devel program (in terms of getting machines) isn't a long-term sustainable thing, especially given the bottlenecks already occurring and the growth rate we're experiencing. SJ has put forth a proposal for a community-driven implementation of "developer's program" machine distribution; this is my current understanding based on our 1/29/08 discussion. Mchua 14:08, 30 January 2008 (EST)

Possible systems

This section describes systems that can be used to get projects that have been proposed laptops (in order of their priority and need).

Old system

1. A Proposer - let's call him Peter - wants XOs for his grassroots group / cool project / pilot.
2. Peter writes up a description of what he'd like to do, who he'll be working with, his experience, how they'll carry out the plan - basically, a project proposal.
3. Peter sends his proposal to a closed mailing list of admins. Peter's proposal is not posted publicly.
4. The admins look at Peter's proposal. If they don't think it creates enough value to OLPC to warrant what he's asking, they send him back feedback on the same, or a "sorry, we can't do this" letter.
5. If the admins /do/ like Peter's proposal, they tell Shipping (Julia) to mail laptops to Peter straight out of 1cc, and the process closes.
6. Alternatively, if the admins become aware that someone needs an XO, they can decide to ask Julia to send her a donated laptop even without a proposal being submitted.

Pros: Decisions of who gets how many laptops are made by people in-the-know whom we trust.

Cons: Bottleneck - doesn't scale, and currently has lots of lag time. Things go on behind closed doors; feedback and discussion on project proposals which may potentially improve said proposals doesn't happen.

Current community system

The community system proposal involves the entire global OLPC community collaboratively working on a priority ordering of outstanding projects and suggests how many laptops should be allocated to each program/project. Over time, this community refines the heuristics for evaluating which projects are / will be most successful at improving education through OLPC.

There will be a group at Brightstar or some other distributor (we'll call it "the shipping center" here) that describes what is possible (in terms of parts available, etc), and updates people when laptops actually go out, but does not have administrative control over who gets laptops.

There is a group called "the Amenders" with access to this db with veto power who can nix proposals outright regardless of community feedback.

There is also a group called "the Choosers" who can approve a proposal outright regardless of community feedback (or create a proposal for a third party who needs a laptop on short notice - for instance, VIPs or last-minute demos). (Choosers will, however, be strongly encouraged or even required to find alternative sources for these non-community-approved allocations.)

This is probably clearest explained in an example.

1. A Proposer - let's call him Peter - wants XOs for his grassroots group / cool project / pilot.
2. Peter writes up a description of what he'd like to do, who he'll be working with, his experience, how they'll carry out the plan - basically, a project proposal.
3. Peter submits his proposal via a website that feeds into a "proposals database," in order to keep Peter's contact information private and preserve the original state of his submission, including a summary paragraph.
4. Peter's proposal (with details on background, timeline, relationships to other projects, etc) is automatically posted to a wiki page and linked to from a "Projects review" page that includes summaries of and links to all projects currently under review.
5. Discussion ensues on the proposal's talk page about how well the project fits the criteria that the community is looking for (in terms of being conducive to OLPC's mission, etc). and people can offer to help out, comment on ways to improve the program, discuss how many laptops should be allocated, etc.
6. When consensus is reached, if this consensus involves sending the project one or more XOs, a revised summary is posted to a section of a "Waiting for laptops" wikipage along with an indication of priority and how many laptops it's getting.
7. Discussion continues on this page - no longer about whether a project should get laptops and how many, but on how high on the priority list for sending laptops they should be (this will change as situations change, for instance whether there's a local chapter nearby that can look after XOs, or whether core development is sorely needed in the area of the proposal, etc).
8. The Shipping Center keeps an eye on this "Waiting for laptops" page (or possibly a database synced to it), and when laptops are available, they ship them out to projects according to priority listed on the page.
9. Local groups and individual owners can also keep their eye on the "Waiting for laptops" page and offer to share/lend/donate their machines to projects, so that the Shipping Center is not the only place where people can get XOs for their projects.
10. When Peter gets his laptops through whatever means, his project is moved into a page of "Current projects" with summary, date, laptops sent, and links to project pages with updates and such, and contact information from Peter.
11. When Peter has finished using the laptops, or someone else thinks Peter is no longer utilizing them properly, Peter can send the laptops back to be recycled into someone else's project (or the person can start a community determination process that can culminate in Peter being requested to return his computers).
12. At any time during the process, the Amenders can nix a proposal and remove it from the database.
13. At any time during the process, the Choosers can add a proposal for donation to a third party, and push a proposal to the front of the priority "Waiting for a laptop" queue.

PROS:

• Openness and community involvement,
• removes much of the current bottleneck while still allowing a few trusted people to admin the process veto anything that is obviously not helpful or gaming the system, if problems come up.

CONS:

• Trust issues - is it possible to abuse this system?

  In a way that noone else in the community notices and makes a fuss about? Less likely than the possibility of abusing a system with a small number of overworked reviewers.

• Learning/adoption curve - how to get people to use and understand it?

  If this is just filling out a form, similar to getting people to use and understand the current process (fill out a form and send it to a given email address). A common first resopnse to a request can now be "please work through steps 3 and 4, to give more info to the community about your work" rather than hanging out in limbo b/c an app was vague

• Not clear on how the timeline of community reviewing will work - is there a cutoff date, will apps go stale?

  The same question applies to the status quo. There are many apps never acted upon that are now 8 months old. They are also lost in a stack of papers and not visible anywhere.

• What is the determinant of whether and when consensus is reached?

  Edge cases are always tricky. Rules of thumb are helpful; a class of contributors (moderators?) trusted to assess consensus could be used one day. As a first pass, see how this is handled for featured articles on wp. Contentious project proposals could be considered not there yet, any serious complaint that is not addressed being enough reason not to add a project to the list.

Criteria for choosing projects

1. Is it generative? Can more people use the result to do future new things?
2. How many people are interested in helping out?
3. Is it naturally multilingual/alingual?
4. Is it suitable for children of all ages?
5. Is there a working prototype?

Current work being done

• Crazy-chris and aaron kaplan set up a db (projectdb.olpc.at) that can take in all needed info for project applications, and will soon be able to interface with the Brightstar database.