Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Feature descriptions

I don't mind opening a few bug reports here and there, but (frankly), my sense is that I'll end up opening a bug report for every single project :-)

In my mind, the description should be a one- to three-sentence paragraph (no bullets) that describes why somebody would want to install that particular feature.

e.g. "The Slartibartfast UI provides views and editors that assist in the management and organizational aspects of planet forming. Install this feature if you need to build planets with particular focus on fjords."

It would be great if we could make them all have a similar tone. I don't necessarily believe that what I've suggested is the right tone, so I am open to suggestions.

Wayne

On 11/12/2013 03:42 PM, John Arthorne wrote:
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
EclipseCon
          Europe 2013_______________________________________________
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

--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
Learn about Eclipse Projects
EclipseCon
          Europe 2013

Back to the top