Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] FEEP Voting, Iteration #1 - Summary
The trade off on bringing the platform forward versus defects and technical debt is a valid point. I think in the end it would be valuable for FEEP to fund a mix of those two.

On your other point, I guess there is always a risk in whatever FEEP funds, that it could displace effort that someone else would be willing to do for free. However the thing with Platform that I believe makes it a bit unique, is the scale of defects reported versus the size of the active contributor base. Eclipse Platform UI has over 16,000 open defects, and AERI identifies dozens more every week. Saying that the current committers "should pay attention" doesn't help. There are about a dozen active contributors there who are working hard on the things that are important to them or their employer. I don't think those 20 people will go away if someone funded by FEEP is chipping away at that backlog, with a goal of fixing the bugs with the highest possible impact for the entire community. I think the significant jump in problems shows what we have known for a long time, that the reported defect rate exceeds the fix contribution rate, and anything we can do to reduce that gap is worth considering.

John



From:        Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx>
To:        "eclipse.org-architecture-council" <eclipse.org-architecture-council@xxxxxxxxxxx>
Date:        11/24/2015 12:56 PM
Subject:        Re: [eclipse.org-architecture-council] FEEP Voting,        Iteration #1 - Summary
Sent by:        eclipse.org-architecture-council-bounces@xxxxxxxxxxx



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.

Back to the top