Re: [platform-vision] Minutes from December 3/2014

[Daniel Megert <daniel_megert@xxxxxxxxxx>]

> The next call
will be at 11am ET on Wednesday, December 17.

I will join the call but will be approx.
5 minutes late.

Dani



From:      
 Wayne Beaton <wayne@xxxxxxxxxxx>
To:      
 platform-vision@xxxxxxxxxxx
Date:      
 03.12.2014 22:58
Subject:    
   [platform-vision]
Minutes from December 3/2014
Sent by:    
   platform-vision-bounces@xxxxxxxxxxx

---

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
[attachment
"728X90.jpg" deleted by Daniel Megert/Zurich/IBM] _______________________________________________
platform-vision mailing list
platform-vision@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-vision