| [platform-vision] Minutes from December 3/2014 |
|
In attendance: Dani Megert Lars Vogel Martin Lippert Alex Kurtakov John Arthorne Minutes: We need to make it clear that the vision does not imply that we have all necessary resources to implement the vision. We must make it clear that additional resources are required. In fact, soliciting additional resources has to be part of the strategy. "won't happen is people don't join" Some will happen and some will not depending on resources. We should include "JVM languages" in the vision statement: -- Our vision is to build leading desktop and cloud-based development solutions, but more importantly to offer a seamless development experience across them. Our goal is to ensure that developers will have the ability to build, deploy, and manage their assets using the device, location and platform best suited for the job at hand. Eclipse projects, the community, and ecosystem will all continue to invest in and grow desktop Eclipse. Full-function cloud-based developer tools delivered in the browser will emerge and revolutionize software development. Continued focus on quality and performance, out-of-the-box experience, Java 9, and first class Maven, Gradle, and JVM Languages support also figure prominently in our vision of a powerful developer’s platform. -- Fix the little things. Make it easier to contribute. This will increase the "coolness" factor (or at very least reduce friction) which should be a net positive, encouraging more people to step up. Oomph profiles for JDT have recently been created which makes it way easy to create a JDT development environment. Performance testing of the platform is improving. We now have some results posted on the downloads page. Focus on user experience; make the user the first priority. Traditionally, adopters have been the first priority and it's been left to adopters to polish their Eclipse-based offering. We need to move some of that polishing into the Eclipse packages. This will require dedicated resources. We need people with a strong interest in making the user experience great. We need to take an holistic approach to the user experience. Most projects are--naturally--exclusively concerned with their own project's usability. We've had some success with relatively little things like line numbers on by default and whitespace reduction. These are examples of little irritants that many of us don't quite understand, but still yield relatively large gains when we address them. Think of EPP packages as end-user products. More extensive testing is required. We currently test to ensure that the features generally behave well together. Testing needs to extend to usability, key-binding and other such conflicts, etc. Aside: Are Oomph packages the real SDKs? We need to find user experience resources. We may need to pay for them. Improve the committer workflow. Reduce the effort that committers spend on things that don't add real value. Let them focus on what really matters. Make things easier for committers and contributors https://bugs.eclipse.org/bugs/show_bug.cgi?id=435599 Specific marketing focus on Java developer tools. Facilitate communication between Che and JDT/Platform. Flux is an enabling technology. There is overlap between Orion and Che. Orion plays an important role. In the context of Java, Orion is enabling technology (for Che and Flux). In the broader space, Orion is front-line technology: _javascript_ and node. Flux is currently a fork of JDT. This is not sustainable. JDT needs to be extended/refactored to support Flux and Flux-like behaviour. We still don't really know JDT manifests in the cloud. What is the granularity of the workspace? One JDT or many? Should we try to tackle "big things"? Wayne brought up past complaints regarding complexity in the menus. Consensus was that it is probably not our best target. It's a very big problem that is hard/impossible to get right without making menus completely dynamic. Consider building functionality that can identify misbehaving plug-ins and their corresponding root feature. This gives the user the opportunity to remove misbehaving features. Further, it informs the user of who to connect with to resolve issues (instead of just opening a bug against JDT). A UI might even provide a very easy way to remove the feature and links to the feature provider. Assemble a list of the most annoying bugs. "Every Detail Matters" might be a better name for the "must not look goofy" effort. We need to review the full experience: website > download > install > use > extend. -- Based on what we talked about today, I've taken a stab at the (high-level) strategy: Reduce friction for users (install, out-of-the-box experience, general usability) Reduce friction for contributors (push Oomph as the way to realize a complete development environment) Get Che building at Eclipse (and produce downloads/releases) Actively recruit resources Marketing focus on Developer Tools (Java developer tools in particular) Lets discuss any concerns directly in the mailing list rather than wait for the next call. The next call will be at 11am ET on Wednesday, December 17. Thanks, Wayne --
Wayne Beaton @waynebeaton The Eclipse Foundation  |