(added original proposals from main page) |
|||
| Line 38: | Line 38: | ||
== Andrew Flegg == | == Andrew Flegg == | ||
| - | |||
* How many [devices] have they got to allocate? | * How many [devices] have they got to allocate? | ||
* Are there strings attached? | * Are there strings attached? | ||
| Line 49: | Line 48: | ||
** Who is involved in the decision? | ** Who is involved in the decision? | ||
** How does the institutional memory work if someone turns out to be all talk? | ** How does the institutional memory work if someone turns out to be all talk? | ||
| + | |||
| + | == Dawn Foster == | ||
| + | * I wonder if the provider conditions belong in some type of form that the vendors provide when they submit their intent to provide devices? I could see Intel, for example, having different conditions for different types of devices. And hopefully, we'll continue to get additional vendors who will need to add their conditions, too. However, it would be useful to get some examples here like what we have for TI to help us design the form with the right parameters in mind. --[[User:Dawnfoster|Dawnfoster]] 02:58, 9 December 2010 (UTC) | ||
| + | ** Good question, but couldn't we address various devices/conditions with a hierarchy here? --[[User:Texrat|Texrat]] 03:08, 9 December 2010 (UTC) | ||
= Proposals = | = Proposals = | ||
Note: the content on this page is still in the very early proposal stage. (moved from main page and kept for reference) --Texrat 01:57, 9 December 2010 (UTC)
Contents |
Putting together budget proposal & basic timeline --Dawnfoster 18:33, 30 September 2010 (UTC)
Maemo had a similar device program. Please feel free to add any notes, best practices, things that were learned from that program:
Maemo Process (from Andrew Flegg):
Best Practices:
Following are some proposals that have emerged from recent discussion. There are useful elements to all of them, and they are not all necessarily mutually exclusive-- we can build a single, comprehensive solution from highly regarded parts.
Note that the existence of a formal MeeGo program would not prevent participating providers from making products available to MeeGo members via other channels.
(Dave Neary, from IRC)
The Maemo program failed because we were applying an objective measure for something which is necessarily subjective. And decentralising an activity which is mostly centralised. The opportunity I see there is for referrals. The community works as a network. So anyone who could usefully use a device is surely known to someone. And if we can get those nuggets of information - "could use a device", "has time", "will build stuff" - sufficiently centralised that people giving out devices know people who could use them.
Randall's notes: If I understand correctly, there's an assumption that a community nomination/request process will “just work” and even a single coordinator (who is of course heavily involved in the community) will be made aware of needs, interests, merits, etc. I also believe this is possible with the right coordinator. I agree with Dawn Foster that the coordinator should report to the Linux Foundation (preferrably as an employee) to minimize provider bias.
(Dave Neary, from IRC)
Another way of doing it is to hand out devices like moderation points on slashdot (this is a bit further out of left field). You name maybe half a dozen community members (including Dawn/Quim/Arjan/...) "device distributors". Each one has a quota of devices at their total discretion. And you grow the pool of distributors on trust & merit - maybe based on who refers the most people?
Randall's notes: another good suggestion, although redistribution of unneeded devices will still require a logistics solution.
(Randall Arnold)
The Linux Foundation establishes a full time position with one duty being the coordination of device programs with providers and acting as the interface to the community. It might even ultimately make sense to have a single office but with a coordinator for each major global region.
Device providers can target MeeGo members directly through their own means (specifically, via contests, etc), but the LF conduit will still manage logistics. Community members could nominate themselves or other members; final decisions could be made by random drawings, community leader approval, or [your proposed selection process here]. Dave Neary's suggestion to use a certain number of community leaders at first would be good for starting out, with the provision that this would be subject to periodic review and possible replacement (eg, if a community council were begun).
For the most part it is expected that device providers would feed a central pool. Devices would be shipped to recipients from that pool by the LF coordinator. When recipients no longer have need of a device, they would request a prepaid shipping label from the coordinator and return it to the central pool.
Devices could also be handed out at local meetups (see Dave Neary's suggestion below) via drawings, contests, etc.
(Dave Neary, email)
The hardware programs I've seen so far tend to adopt one of three approaches: give hardware to people based on what they've done in the past, give hardware in reward for participation in some competition, or give hardware to people based on the promise that they will do something.
For boards, I would like to propose a fourth way: Give a workshop teaching people how to use MeeGo on the hardware, and provide the hardware to workshop attendees & let them take it home at the end.
The problem with giving hardware to people based on their reputation is that they tend to cumulate hardware - I know a lot of kernel people's reaction to a hardware giveaway is often "put it on the pile over there" at this stage. THere's no guarantee they'll have any utility for the hardware or do anything with it.
Giving hardware as a prize for a software development contest is tempting, and if you have really good docs on how to get started with development using emulation or something, that might be a good approach - but it does add some overhead in terms of judging.
Expecting people to apply for hardware (à la Nokia) also has a limited return on investment, I'm afraid, because it's one thing promising to do something with the hardware, and another thing to actually do something with it. Also, I would argue that past reputation is actually a poor predictor for the amount of hacking you'll do for a new device.
The fourth way, providing hardware as a reward for participation in a training workshop, has a double incentive - you're not expecting people to do hardware hacking as a prerequisite, and you're training people & giving them the tools which they need to be able to do something with the hardware afterwards. Plus, participation in the workshop is, I would argue, evidence of a willingness to actually do some hacking with the hardware afterwards.
Simply implement same process as used for maemo.org (http://wiki.maemo.org/Fremantle_Developer_Device_Queue) and refine as needed.
(Quim Gil, email)
I can imagine this scenario being quite common:
- A company is willing to distribute some hardware with some reasons in mind.
- That company has already a % of devices being distributed through their own channels, but would be happy adding a % for the MeeGo project, who would find the best recipients for the occasion.
- Contact made: the company says it has a number of devices and after some time the MeeGo project can provide a list of names & addresses for those devices, organize an event where this people will take part, come up with another proposal, etc.
- The cost of distributing that hardware is covered by the company, but the hours and skills to find the right people is contributed by the MeeGo project.
Randall's note: redistribution of unused devices would still be an issue. Solution?
Please add/change items here as necessary, and ask further questions on meego-community email list.
The goal of course is to replace the above proposals with a Process.