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.
David M Williams <david_williams@xxxxxxxxxx>
Cross project issues
11/12/2013 02:17 PM
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.
[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?
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
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"
particularly helpful. Maybe include a little something to describe why
somebody might want to install this rather than, say, the "XXX SDK"
is described as the "XXX SDK Feature").
Or I can start opening bugs.
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.
Red Hat Eclipse team
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects