Bugzilla – Full Text Bug Listing
| Summary: | allocate FOE funds as directed by community | ||
|---|---|---|---|
| Product: | Community | Reporter: | Scott Lewis <slewis> |
| Component: | FoE Disbursements | Assignee: | Eclipse FOE Disbursements <foe-disbursements-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | antonel.pazargic, bugs.eclipse.org, caniszczyk, denis.roy, Ed.Merks, gunnar, Markus.Milleder, Paul.White, stepper, wayne.beaton |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | stalebug | ||
|
Description
Scott Lewis
Certainly a policy that's fairer is better by definition. Unfortunately I think this approach only guarantees fairness for the donors not necessarily to the recipients. It seems likely to ensure that the rich get richer: http://ed-merks.blogspot.com/2011/03/universe-is-unfair.html After all, won't the most amazing projects, with great code quality, excellent testing, great documentation, builds with timely bug fixes, responsive forums, and sexy compelling UIs snap up disproportionally more of the money? I.e., won't the projects least likely to need the money attract the most? I don't think donor earmarking will work well, exactly for the reasons Ed brings up. Thus, I think fund allocation should be driven by a published policy. This bug (and its predecessor) shows that this policy needs to be much more concrete than just naming the principle of fairness. I suggest developing such a policy or set of policies and putting it up for voting among the FoE's. Any such policy should aim to have a benefit beyond helping a single project. My priorities as a long term follower of Eclipse's development would be: 1. Releng support * Decision support for what to use. Dave Carver mentions PDE Build, B3, Buckminster and Tycho as options in http://intellectualcramps.wordpress.com/2011/03/07/are-projects-outpacing-the-ability-to-adapt-and-repsond/ . Even as an avid follower of Eclipse (I've heard all the names previously) I wouldn't know how to decide between them. * (Better/more visible) introductory documentation for these tools, especially with an eye toward participation in a coordinated release. * Best practices documentation and tooling to check compliance with said best practices All of these things should be useful well beyond Eclipse.org, for everybody creating Eclipse plugins. 2. Releng support again Dave Carver also mentions long running builds as a possible problem for Eclipse's build infrastructure. * Develop ways to reduce build runtimes (Dave has some ideas in his blog post). * Support projects to structure their builds accordingly. * Again create best practices documentation and maybe tooling. This is more focused on benefiting Eclipse.org and Eclipse projects directly. 3. Evangelizing The discussion about FoE fund allocation has also brought up problems with sponsorship for Eclipse. * There are corporate free-riders - try to get them to become sponsors * Existing sponsors don't like to fund infrastructure - talk them into doing it anyway 4. Help infrastructure components The Releng work above is already along these lines, but this help may also be more direct. This also means treating the FoE fund as a sponsor for the infrastructure work mentioned in the evangelizing section, and may hinder those efforts ("Why pay, it's happening already anyway" :-( I'd see e.g. most of the Eclipse platform, ECF, WTP's source editing and faceted projects, parts of CDT (used also by PTP) and the core of DLTK as infrastructure (obviously wearing my "Eclipse the IDE glasses :-) The criterion is broad use (or potential use) by other projects, while there is no obvious interest in investing major effort there. 5. Eclipse Summer of Code Going in a completely different direction, FoE's may want to support a program to introduce new developers to Eclipse while getting some focused work done, analogous to what the Google Summer of Code does. This could be used as an organizational container for work on any of the points above (well, except for evangelizing). (In reply to comment #2) > I don't think donor earmarking will work well, exactly for the reasons Ed > brings up. I would like to challenge the notion from Ed's blog that things are unlikely to be 'fair' when decisions and choices are made by the community (as opposed to a centralized policy...which is guaranteed not to be fair...that's a joke Ed :). I think the basic problem here is that everyone has their own definition of what's fair...in terms of scarce resource allocation among the projects...e.g. 'projects that need it', 'all projects equally', 'projects that have consuming communities', 'help small projects', 'help projects that are not corporate supported', 'help popular projects', etc. Rather than 'giving up'...as Ed says in his blog :), I think that turning that decision over to the community (as opposed to centralizing it) can be a way out of disagreement over the definition of fair (and I'm assuming that disagreement about something like fairness will never go away...rather it will be sublimated to 'majority rules' or other, broader notions of fairness in decision making). Note that the process/mechanism for community-based direction of resources does not have to be a popularity contest. Yes, I agree that that *could* be a problem, but why not have the community donation mechanism favor the priorities (e.g.) that Markus outlines...e.g. have the donations optionally (donor's choice) go to a 'pool' for releng support...specifically for projects that have requested such support (i.e. that have expressed need). Other such mechanisms are possible, and would be simple to implement. They also wouldn't have to stay fixed over time (i.e. they could be different as circumstances dictated). Incidently...any policy that is created, reviewed, agreed upon, voted upon, etc will be (I believe) too slow and static...especially with rapidly changing circumstances (e.g. yearly releases). So to summarize: 1) I don't think that community direction has to be a popularity contest (there is admittedly a danger of that, but that danger can easily be mitigated) 2) Guided/targeted donation...along the lines Markus describes (based upon need in recognized important areas...i.e. releng) could work well. 3) Centralized policy (which is what we have now, BTW) doesn't seem to be working well (by my estimation)...so why would we want to continue with exactly the same approach? I would encourage everyone on this bug to read the comments on bug 313479. I would personally like to avoid engaging in the same discussion/making same points as was begun almost a year ago...and which (at least partially) led to the creation of the FOE disbursement program in the first place. There is recent work in decision making that is relevant to this bug. It's called 'Nudge: Improving Decisions About Health, Wealth, and Happiness' by Thaler and Sustein. I'm not going to insert a link here, but it is easily found (along with lots of web-based resources), by searching for 'nudge' or 'nudging'. The connection of this work is this: currently, the main objection to this this bug from comment 1 and Ed's blog seems to be that such an approach would inevitably devolve into a 'popularity contest'. The implication seems to be that it's somehow necessary that the committer Board reps or some other centralized body first devine and then decide what's 'fair' in terms of scarce resource allocation across all projects that they are supposed to represent. I think that the assertion that community decisions about resource allocation will inevitably devolve into a popularity contest is incorrect. Especially if the FOE choice mechanism (i.e. the actual web interface for FOE contributions) uses the notion of 'nudging' in the directions that are considered fair...e.g. using any resources for releng...having any resources go disproportionately to smaller projects (that perpetually need more help with releng), directing to projects that the FOE contributor actually uses (as per discussion on bug 313479)...can all be imposed very simply/easily through some simple 'nudging' in the appropriate directions that are recognizable by contributors and other community members as 'fair'. This doesn't have to be complex technically...as others have already suggested mechanisms that are readily available...e.g. allowing contributors to 'tag' their contribution to go in certain directions (e.g. releng, certain projects, etc). To summarize: a) I don't think that community-driven allocation will/has to lead to a popularity contest. b) There are easily implemented and very effective mechanisms to prevent 'a' from becoming a problem. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. (In reply to Eclipse Genie from comment #6) > This bug hasn't had any activity in quite some time. Maybe the problem got > resolved, was a duplicate of something else, or became less pressing for > some reason - or maybe it's still relevant but just hasn't been looked at > yet. IMO it's still relevant...and nothing has been done. The timing of this automated notice is fortuitous, as once again...particularly the small projects...seem to be struggling with completing releng/Luna SR requirements. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. (In reply to Eclipse Genie from comment #8) > This bug hasn't had any activity in quite some time. Maybe the problem got > resolved, was a duplicate of something else, or became less pressing for > some reason - or maybe it's still relevant but just hasn't been looked at > yet. The Eclipse Genie has become amazingly ironic. Must be that AI I keep hearing about. > > If you have further information on the current state of the bug, please add > it. The information can be, for example, that the problem still occurs, that > you still want the feature, that more information is needed, or that the bug > is (for whatever reason) no longer relevant. I think the root problem (project starvation) is still very relevant. I'm inclined to point at the FEEP programme mark this as fixed. Thoughts? (In reply to Wayne Beaton from comment #10) > I'm inclined to point at the FEEP programme mark this as fixed. Thoughts? I think my thoughts can be best expressed by the question: what is FEEP? (In reply to Scott Lewis from comment #11) > I think my thoughts can be best expressed by the question: what is FEEP? http://lmgtfy.com/?q=eclipse+FEEP :P (In reply to Eike Stepper from comment #12) > (In reply to Scott Lewis from comment #11) > > I think my thoughts can be best expressed by the question: what is FEEP? > > http://lmgtfy.com/?q=eclipse+FEEP :P Thanks...I was making a point that was apparently lost. "FEEP...utilizes the funds donated through the Friends of Eclipse program to make significant and meaningful improvements and enhancements to the Eclipse IDE/Platform. ...EF will engage with key stakeholders in the community to determine the highest priority issues to be addressed" How does this address: 1) The resource needs of any EF projects that aren't the IDE? 2) Democratize the allocation of FOE resources, rather than turn them over to centralized allocation? (i.e. see 'key stakeholders' and 'better/fairer' in bug description) This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. I don't know that we have a path forward here, or a concrete vision that is backed with participants that can move it forward. Please reopen if I have that wrong. (In reply to Denis Roy from comment #16) > I don't know that we have a path forward here, or a concrete vision that is > backed with participants that can move it forward. Please reopen if I have > that wrong. All I can say is that afaict, nothing substantive has been done about the problem identified by this issue, and for those of us not in a tech-induced haze...the problem is showing...through ongoing struggles to get anything other than the corporate-owned projects into a sustainable situation (witness the worsening resource problems associated with both the simrel and the IDE itself, not to mention the projects upon which they depend). This is not sustainable. See log4shell. Denis you are of course correct that there are no participants available to move it forward...precisely because the structure/organization/control of the EF, TLPs, Board doesn't support those participants (as per this issue). wontfix is an appropriate resolution sadly. |