Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
SimRel/Feature Categories
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".
"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 use as the "provider name" in features, e.g. "Eclipse EGit"
For more information, see Development Resources/HOWTO/The Eclipse Code Namespace Policy.