I agree, that the descriptions should be informative rather than the completely spelled out name of the project or so. IMHO the main problem is the number of features provided. Eike gave us a good example of that and it's similar for most projects. The common CDO user usually just wants to install CDO and isn't able to tell easily which of the features he will need.
I think it would be good, to be able to mark features as "secondary" and have the install dialog filter those out by default. So there would only be one CDO, EGit, or Xtext feature to choose by default. (I know that would involve some new code to be written, tested and maintained.) Sven On Nov 13, 2013, at 4:41 PM, Wayne Beaton <[email protected]> wrote: > 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 <[email protected]> >> To: Cross project issues <[email protected]>, >> Date: 11/12/2013 03:44 PM >> Subject: Re: [cross-project-issues-dev] Feature descriptions >> Sent by: [email protected] >> >> >> >> 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 <[email protected]> >> To: Cross project issues <[email protected]>, >> Date: 11/12/2013 02:17 PM >> Subject: Re: [cross-project-issues-dev] Feature descriptions >> Sent by: [email protected] >> >> >> >> 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 <[email protected]> >> To: [email protected], >> Date: 11/12/2013 01:56 PM >> Subject: Re: [cross-project-issues-dev] Feature descriptions >> Sent by: [email protected] >> >> >> >> 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" <[email protected]> >> To: "Cross project issues" <[email protected]> >> 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 >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >> >> >> _______________________________________________ >> cross-project-issues-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >> >> >> >> -- >> Wayne Beaton >> Director of Open Source Projects, The Eclipse Foundation >> Learn about Eclipse Projects >> <Mail Attachment.jpeg>_______________________________________________ >> cross-project-issues-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >> _______________________________________________ >> cross-project-issues-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >> _______________________________________________ >> cross-project-issues-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >> >> >> >> _______________________________________________ >> cross-project-issues-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > -- > Wayne Beaton > Director of Open Source Projects, The Eclipse Foundation > Learn about Eclipse Projects > <Mail Attachment.html> > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
