Revision as of 00:04, 7 January 2015

This is a work-in-progress.

This is a proposal. A work-in-progress proposal at that. At this point, this just a bunch of ideas.

Problem Statement

The feature categories in the simultaneous release repository have been in place for some time. We have added new categories over the years and there are several proposals to add additional categories. There is concern in the community that the large number of categories that we have in place now are already confusing to the user community. Adding new categories only makes the categorization less effective (taken to the extreme, if every feature has it's own category, the categories are useless).

Further, feature composition, names, and descriptions are inconsistently provided. Improving consistency will make identifying features much easier and should presumably improve the perception of quality being produced by the simultaneous release.

Roles

End users are exclusively concerned with identifying features to add to the Eclipse-based IDE. End users seek specific functionality; they are not interested in SDKs, or source code.

Extenders include simultaneous release features in their products, and may make use of source code and SDKs. Extenders are more sophisticated in their knowledge of how Eclipse features are represented and so are generally successful in identifying features in spite of categorization. That is, they are able to identify the features they need without extensive use of categorization (in fact, navigating the categorization may be an impediment).

Developers (committers/contributors) probably don't use the simultaneous release repository in their role. Specifically, a committer working on a project will probably not make much use of their own project's SDK and would instead access their project's code directly from the SCM. Contributors (which may include committers making contributions to projects for which they are not committers) may leverage the SDKs and source code features. In this case, however, they would be similar to extenders in terms of the sophistication of their knowledge of how Eclipse features are represented.

Features and Names

Features intended for the end user should have names that are reflective of the functionality provided by the feature, e.g. "Team Provider for Git". From the user's perspective, project names are meaningless: project names are like code names that are meaningful only to those who work "on the inside".

Do not include the word "Feature" in the feature name (that it is a feature is implied/an implementation detail).

"SDK" Features can use the project name, suffixed with "SDK", e.g. "EGit SDK"

All feature descriptions should actually be descriptive.

The project name should be used as the "provider name" in features, e.g. "Eclipse EGit"

For more information, see Development Resources/HOWTO/The Eclipse Code Namespace Policy.

Categories

Note that what I have below is just an example/start.

Database Development

• SQL Tools
• Open Data Access

General Purpose Tools Other Tools

• ACTF Visualization Extension for PDT Feature Accessibility Visualization for PHP Development Tools
• PHP Development Tools

Programming Languages and Tools

• C/C++ development tools
• C/C++ development tools - IBM XLC Compiler Support
• C/C++ development tools - Visual C++ Support
• Eclipse Java development tools
• Java development tools - Recommendation Engine
• PHP development tools
• Dynamic Languages Toolkit iTcl development tools
• Eclipse XML Editors and Tools
• Fortran development tools (Photran)
• JavaScript development tools
• Xtend IDE development tools
• SWT Designer Core
• Swing Designer
• WindowBuilder Java Core

SDKs and Source

• C/C++ Development Tools SDK
• Data Tools Platform Enablement Extender SDK
• Data Tools Platform Extender SDK
• Source for Eclipse XWT SDK
• Source for Eclipse XWT Workbench Integration SDK
• WindowBuilder SDK