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

For discussion, please see bug 457287

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".

Obvious exceptions include projects that have descriptive names, e.g.

C/C++ development tools
PHP development tools
Java development tools

Note that Java trademark guidelines require that we use lower case "development tools". We need to decide if we want to make this consistent with other development tools.

Optional/extra extensions extend the base feature name.

C/C++ development tools - IBM XLC Compiler Support
C/C++ development tools - Visual C++ Support

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

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

All feature descriptions should actually be descriptive of the feature. Descriptions should not include the project name.

The project name prefixed with "Eclipse" 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.

SimRel/Feature Categories

Contents

Problem Statement

Roles

Features and Names

Categories

Breadcrumbs

SimRel/Feature Categories

Contents

Problem Statement

Roles

Features and Names

Categories