[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse.org-architecture-council] FEEP Voting, Iteration #1 - Summary
|
Not sure if I understood John right, but I had read the AERI triage & fix as specifically targeted for Platform,
which I do think suffers from the "tragedy of the commons" issue today so could certainly use some FEEP help.
I do agree with you that AERI should primarily be an incentive for projects to fix their quality and not wait for FEEP to fix it for them.
But if you look at Platform, the few heroes in there currently shoulder a heavy load for the benefit of all of us.
I like the idea making the FEEP for AERI proposal more measurable.
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
direct +43.662.457915.85 fax +43.662.457915.6
-----Original Message-----
From: eclipse.org-architecture-council-bounces@xxxxxxxxxxx [mailto:eclipse.org-architecture-council-bounces@xxxxxxxxxxx] On Behalf Of Gunnar Wagenknecht
Sent: Tuesday, November 24, 2015 6:47 PM
To: eclipse.org-architecture-council
Subject: Re: [eclipse.org-architecture-council] FEEP Voting, Iteration #1 - Summary
John,
It sounds like we should scratch the "fund a developer" approach completely then and propose something along the lines for triaging & fixing AERI problems (ranked by number of problems reported)?
My only concern is with the message such a budget could imply. According to Marcel, there was a significant jump in reported problems with the last (service) release. If there is now a budget, some projects could conclude that they don't need to pay high attention to quality/testing because AERI will catch it and the Foundation will provide budget for fixing it later.
I would rather see the FEEP money being invested into things that will bring the IDE forward then cleaning up things which projects should pay attention to.
-Gunnar
--
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx, http://guw.io/
> Am 24.11.2015 um 17:52 schrieb John Arthorne <John_Arthorne@xxxxxxxxxx>:
>
> Thanks for all your work gathering and assembling this, Marcel.
>
> I want to poke on "fund a developer to triage and fix the most common errors" one a bit. Apart from the fact that the topic was changed half way through voting, I have a meta-point about how this one is quite different from all the other proposals. For all the other topics, we are essentially making guesses about what we think is the most valuable thing to focus on. I find it hard to judge whether it is more important to work on GTK vs Mac issues, or how to measure the competing proposals on how to improve discovery/install of new plugins. However from AERI we have concrete evidence of errors that occur thousands of times per week for our users. We have a clear way to rank them so we know the most effective thing to focus on. We have a clear metric that can be used to define and measure success at working on it. The downside is that there is a fair bit of noise in the signal, and a lot of "grunt" work to sift through them and identify either the real fix, or the change to our logging code or in AERI to filter or reclassify them appropriately.
>
> To me this one in particular is the perfect use of FEEP funding. It is perhaps not the most exciting work, but it is work that will have real and measurable impact on our quality, and user's perceptions of Eclipse IDE's as a quality product. It is also something that can be scoped up or down to suit any budget FEEP may have. I think the "full time" aspect really skewed the discussion away from the central point here, so I wanted to make sure everyone had a chance to reconsider the proposal and give their thoughts for or against it.
>
> John
>
>
>
> From: Marcel Bruch <marcel.bruch@xxxxxxxxxxxxxx>
> To: "eclipse.org-architecture-council eclipse.org" <eclipse.org-architecture-council@xxxxxxxxxxx>
> Date: 11/19/2015 06:23 AM
> Subject: Re: [eclipse.org-architecture-council] FEEP Voting, Iteration #1 - Summary
> Sent by: eclipse.org-architecture-council-bounces@xxxxxxxxxxx
>
>
>
> Greetings AC Members,
>
> here are the current vote results. There were 16 proposals, and 18 AC members voting. IMHO these results provide a great input for further discussion. This is the summary of the current votes:
>
> Bug Summary Average
> 479686 [FEEP] Improve GTK 3.0 support
> 1,6
> 18
> 480176 [FEEP] Allow user to discover plugins to edit a specific type of file
> 1,6
> 17
> 482409 [FEEP] Fix issues in Mac SWT port
> 1,5
> 15
> 482236 [FEEP] JVM selection UI in the launcher
> 1,2
> 17
> 482034 [FEEP] p2 improvements
> 1,1
> 15
> 480177 [FEEP] WTP XML editor technology face-lift
> 0,8
> 17
> 480547 [FEEP] Prompt user to install additional plugins
> 0,8
> 17
> 479536 [FEEP] Improve Tooling Support for NullPointerAnalysis
> 0,5
> 17
> 480551 [FEEP] Enable "refresh using native hooks"
> 0,3
> 17
> 480546 [FEEP] Make everything available in Eclipse Marketplace
> 0,2
> 17
> 481227 [FEEP] Improve Dark Theme
> 0,1
> 17
> 480024 [FEEP] [jdt] Fund full-time committer for JDT
> 0,0
> 17
> 482037 [FEEP][platform] Fund a developer to triage and fix the most frequently occurring errors in Platform UI
> -0,1
> 17
> 479541 [FEEP] New Project Website for our IDE
> -2,0
> 2
> 480550 [FEEP] Tips & tricks dialog
> -0,1
> 17
> 480553 [FEEP] Review most used marketplace plug-ins
> -0,9
> 17
>
>
> Given these votes, the following topics seem to be of major interest to AC members:
> • Improving GTK 3.0 Support - 1,6
> • Allows users to discover editor plugins based on file-extensions - 1,6
> • Fixing Mac SWT errors - 1,5
> • JVM Selection UI - 1,2
>
> Note that this list is neither a final statement nor a recommendation. It’s a starter for more in-depth discussions - especially for the controverse proposals with wide variance. Those may be caused by different understandings and need further discussion.
>
>
> How to proceed?
>
> Those that voted a +2 on certain topics (and still would vote +2) and feel that the proposal may be misunderstood by others should ask specific voters for their opinions. Preferably, as Pascal said, this discussion takes place in Bugzilla.
>
> I’d propose to reserver another week for iteration #2 - until next Wednesday - to settle the discussions on these controversial topics.
>
> From there, we’ll see whether another iteration is needed. My goal is to finalize this list until the next AC meeting, discuss it there if necessary, and present the results to the EF then.
>
> Regards,
> Marcel
>
>
>
>
>
> _______________________________________________
> eclipse.org-architecture-council mailing list
> eclipse.org-architecture-council@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
>
> IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.
>
> _______________________________________________
> eclipse.org-architecture-council mailing list
> eclipse.org-architecture-council@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
>
> IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council
IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.
