The features without descriptions bother me. Some of them, like
org.eclipse.equinox.core.feature.feature.group, can get away without
a description because nobody is ever going to see them in the
"Available Software" dialog. Still, I'd like to see every feature
described. I don't think that this is (or should be) a "must-do",
but it sure feels like a "you should want to do".
I really like the CDT descriptions, e.g.
org.eclipse.cdt.xlc.feature.feature.group 8.3.0.201310011017
Support for the IBM XL C/C++ compilers.
org.eclipse.cdt.xlc.sdk.feature.group 8.3.0.201310011017
Support for the IBM XL C/C++ compilers. Software development kit
including source code and developer documentation.
org.eclipse.cdt.xlc.source.feature.group 8.3.0.201310011017
Support for the IBM XL C/C++ compilers. Source code.
It's pretty clear to me why I might want to install one vs. another.
There are, frankly, too many entries in this list that appear to
just assume that a user sitting in front of the open "Available
Software" dialog knows enough about their project to hunt for it by
name.
I *really* like that that the EGit project uses a description that
does not include the project name ("An Eclipse Git Team provider in
pure Java."). In fact, I'm quite sure that they don't expose the
project name anywhere in their UI. I don't think that the average
user tends to know project names, or particularly care about them.
I am not suggesting that all project names need to be suppressed.
Xtext comes to mind as a project name that probably belongs in the
feature name and description (for example). C/C++ Development Tools
is another fine example (descriptive project names should generally
just work). I think that _not_ including "(CDT)" in the name or
description is the absolute right thing to do.
Building brand association is fine. I am by no means suggesting that
non-descriptive project names should be excluded. But don't assume
that the user will just understand what "Slartibartfast UML" or
"Trillian UI" means (for example). Give them a reason to install
your project feature.
Wayne
On 11/12/2013 05:01 PM, David M
Williams wrote:
Oh, sorry, skim
reading .... for descriptions,
see
http://build.eclipse.org/simrel/kepler/reporeports/reports/descriptions.html
or
http://build.eclipse.org/simrel/luna/reporeports/reports/descriptions.html
From:
John Arthorne
<John_Arthorne@xxxxxxxxxx>
To:
Cross project issues
<cross-project-issues-dev@xxxxxxxxxxx>,
Date:
11/12/2013 03:44 PM
Subject:
Re:
[cross-project-issues-dev]
Feature descriptions
Sent by:
cross-project-issues-dev-bounces@xxxxxxxxxxx
I think the more interesting
question
from Wayne is about the feature *descriptions* rather than the
names. Our
names could use some tuning as well, but the description is the
opportunity
to describe the end user capabilities in more detail. I think
adding the
feature descriptions to the report may be helpful, although
projects can
also review their descriptions by clicking each one in the
install dialog
and looking at the details box.
From: David
M Williams <david_williams@xxxxxxxxxx>
To: Cross
project issues <cross-project-issues-dev@xxxxxxxxxxx>,
Date: 11/12/2013
02:17 PM
Subject: Re:
[cross-project-issues-dev] Feature descriptions
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
They are already there! See
http://build.eclipse.org/simrel/luna/reporeports/reports/featureNames.html
The original purpose of this "report" was to spot cases where
people had "null" for the name or &featureName (indicating
an error in NL files) but ... as it turns out it also provide a
list of
"probably correct". I say "probably" in that report,
since there is no "smarts" to if it is correct for that feature
... much less if it is a "good" name ... to there's 911 for you
(or others) to scan though. I doubt if there is a heuristic that
would
be good at deciding if a name was "good" or not ... but ... at
least you get them all in one place.
And, that's just for the "Sim. Release" repo. Same report can
be generated for any repo, but nothing's automatic about that.
If you want
to "run on individual repos" see
http://wiki.eclipse.org/SimRel/Simultaneous_Release_Reports_Running_Locally
HTH.
From: Wayne
Beaton <wayne@xxxxxxxxxxx>
To: cross-project-issues-dev@xxxxxxxxxxx,
Date: 11/12/2013
01:56 PM
Subject: Re:
[cross-project-issues-dev] Feature descriptions
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
Is there a relatively easy means of dumping out the feature
names/descriptions
directly from the aggregate repository?
Wayne
On 11/12/2013 01:13 PM, Aleksandar Kurtakov wrote:
----- Original Message -----
From: "Wayne Beaton" <wayne@xxxxxxxxxxx>
To: "Cross project issues" <cross-project-issues-dev@xxxxxxxxxxx>
Sent: Tuesday, November 12, 2013 8:05:20 PM
Subject: [cross-project-issues-dev] Feature descriptions
So I got a little bogged down this morning helping a community
member install
some Eclipse software.
At one point, I was connected to a handful of p2 repositories
that contained
less-than-helpful descriptions. I assume that we actually want
people to
install our software, and so feel that providing a help
description that
compels them to do so is a reasonable thing to hope for.
Rather than pick on any individual project, I'd like to invite
projects
to
review your feature descriptions to see if you can be more
helpful for
potential users and consumers.
e.g. describing the feature named "XXX UI" as "XXX UI Feature"
is not
particularly helpful. Maybe include a little something to
describe why
somebody might want to install this rather than, say, the "XXX
SDK"
(which
is described as the "XXX SDK Feature").
Or I can start opening bugs.
Hi Wayne,
I would definetly welcome such bugs as keeping track of all
the features
is too hard and having bugs when someone spots something makes
it easier
to not forget it.
Alexander Kurtakov
Red Hat Eclipse team
Thanks,
Wayne
--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Wayne Beaton
Director of Open Source Projects, The
Eclipse Foundation
Learn about Eclipse
Projects
 _______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|
