Meego Wiki
Views

Talk:Community Office/Community device program

From MeeGo wiki
< Talk:Community Office(Difference between revisions)
Jump to: navigation, search
(Created page with "'''Note: the content on this page is still in the very early proposal stage.''' (moved from main page and kept for reference) --~~~~ ==Status== Putting together budget proposal…")
 
(One intermediate revision not shown)
Line 33: Line 33:
Best Practices:
Best Practices:
* One big advantage of our system is that it's not well advertised, so people submitting their names tend to self-select fairly well. This avoids having people who just want to get free hardware spamming the queue. I'd expect any system MeeGo to have to be more official and, thus, high profile and to require more stringent criteria to go with it. ([http://lists.meego.com/pipermail/meego-community/2010-September/001896.html from Ryan Abel])
* One big advantage of our system is that it's not well advertised, so people submitting their names tend to self-select fairly well. This avoids having people who just want to get free hardware spamming the queue. I'd expect any system MeeGo to have to be more official and, thus, high profile and to require more stringent criteria to go with it. ([http://lists.meego.com/pipermail/meego-community/2010-September/001896.html from Ryan Abel])
 +
 +
 +
= Questions from Community =
 +
 +
== Andrew Flegg ==
 +
* How many [devices] have they got to allocate?
 +
* Are there strings attached?
 +
* Do they want any say in who they go to, or is it entirely at the discretion of the MeeGo project?
 +
* Will they ship directly to a set of names & addresses?
 +
* Is there a cost to the developer? (i.e. is it free or discounted?)
 +
* How does "the MeeGo project" decide?
 +
** Ask for volunteers?
 +
** Go forth and tap people up?
 +
** Who is involved in the decision?
 +
** 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 =
 +
 +
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.
 +
 +
== Proposal 1 ==
 +
(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's clarification: I was only making a suggestion - that we might use the decentralised network nature of the community to generate the list, but have device distribution stay centralised (or loosely centralised - see "device distributors" idea below). I don't think this will work for most device programs, but for some smaller ones this might be very effective (inspired by David Cuartielles of Arduino). --[[User:Dneary|Dneary]] 11:00, 13 December 2010 (UTC)
 +
 +
== Proposal 2 ==
 +
(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.
 +
 +
== Proposal 3 ==
 +
(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.
 +
 +
== Proposal 4 ==
 +
(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.
 +
 +
== Proposal 5 ==
 +
 +
Simply implement same process as used for maemo.org (http://wiki.maemo.org/Fremantle_Developer_Device_Queue) and refine as needed.
 +
 +
== Proposal 6 ==
 +
(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?
 +
: Dave's suggestion: Tell people that if they're not doing anything useful with the hardware, they should give it to someone they know who will have more use for it. Or encourage people who don't need the hardware not to ask for it!
 +
:: Randall's reply: given that potential contributors are scattered across the globe, there will be shipping costs involved.  My concern is that this could make some holders of unused devices reluctant to pass them on.
 +
 +
= Discussion =
 +
 +
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.

Latest revision as of 19:40, 5 March 2011

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

Status

Putting together budget proposal & basic timeline --Dawnfoster 18:33, 30 September 2010 (UTC)

Overview

  • Community members will apply to get access to devices
  • We will have detailed requirements, selection criteria and approval process
  • All devices is this program are production hardware (no pre-release silicon)
  • See timeline for more details

Timeline and Task List

  • 11/08/10 Figure out a budget for this program and get it in our plans for 2011
  • 11/10/10 Talk to the Linux Foundation about details and administration of this program
  • 12/10/10 Draft plan in place with criteria for acceptance, selection process, etc.
  • 01/07/11 Final plan in place
  • 01/24/11 Program implemented and in place

Possible Future Enhancements to the Program (Phase 2+)

  • Remote access - look into providing remote access to devices (can someone provide more technical details about how Forum Nokia does this now)?

Notes from Maemo

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):

  • They put their name on a wiki page, listing their projects and maemo.org username. The Maemo Community Council then passes details along to Quim for Nokia to dispatch devices.
  • It's pretty informal, and it's just a case of persuading the Council. Since the Council are elected by the community, it's effectively the community self-selecting devices for itself.

Best Practices:

  • One big advantage of our system is that it's not well advertised, so people submitting their names tend to self-select fairly well. This avoids having people who just want to get free hardware spamming the queue. I'd expect any system MeeGo to have to be more official and, thus, high profile and to require more stringent criteria to go with it. (from Ryan Abel)


Questions from Community

Andrew Flegg

  • How many [devices] have they got to allocate?
  • Are there strings attached?
  • Do they want any say in who they go to, or is it entirely at the discretion of the MeeGo project?
  • Will they ship directly to a set of names & addresses?
  • Is there a cost to the developer? (i.e. is it free or discounted?)
  • How does "the MeeGo project" decide?
    • Ask for volunteers?
    • Go forth and tap people up?
    • Who is involved in the decision?
    • 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. --Dawnfoster 02:58, 9 December 2010 (UTC)
    • Good question, but couldn't we address various devices/conditions with a hierarchy here? --Texrat 03:08, 9 December 2010 (UTC)

Proposals

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.

Proposal 1

(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's clarification: I was only making a suggestion - that we might use the decentralised network nature of the community to generate the list, but have device distribution stay centralised (or loosely centralised - see "device distributors" idea below). I don't think this will work for most device programs, but for some smaller ones this might be very effective (inspired by David Cuartielles of Arduino). --Dneary 11:00, 13 December 2010 (UTC)

Proposal 2

(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.

Proposal 3

(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.

Proposal 4

(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.

Proposal 5

Simply implement same process as used for maemo.org (http://wiki.maemo.org/Fremantle_Developer_Device_Queue) and refine as needed.

Proposal 6

(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?

Dave's suggestion: Tell people that if they're not doing anything useful with the hardware, they should give it to someone they know who will have more use for it. Or encourage people who don't need the hardware not to ask for it!
Randall's reply: given that potential contributors are scattered across the globe, there will be shipping costs involved. My concern is that this could make some holders of unused devices reluctant to pass them on.

Discussion

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.

Retrieved from "http://wiki.meego.com/Talk:Community_Office/Community_device_program"
Personal tools