From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Konstantin Komissarchik
Sent: May-29-12 12:39 PM
To: 'Cross project issues'
Subject: Re: [cross-project-issues-dev] Target audience of Juno repo
Trying to fragment the repository around user profiles isn’t going to be easy or clean. Many users and use cases will not easily fit into neat profiles.
On the other hand, we already have a venue for presenting users with an easier to use course-granularity installation option… Eclipse Marketplace.
- Konstantin
From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Miles Parker
Sent: Tuesday, May 29, 2012 9:25 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Target audience of Juno repo
+1, but probably way too late to be asking people to make these kind of changes now. Something that people should be thinking hard about for Kepler. There is a major need for a higher level of granularity on the features. Ideally it would be one per project but that isn't practical in many cases.
On 2012-05-29, at 8:29 AM, Pascal Rapicault wrote:
Once in a while I go through the content of the Juno repo to see what's there; and I try to see if I can make any sense of what is made available. Unfortunately this year it reached a point where I just can't. There are way too many entries that are subtle variations around the same project and whose installation result in unexpected results or non functional additions to my install. For example there is 11 entries for Sapphire, 5 entries for windowBuilder, an infinity of Mylyn related entries...?
I understand that we are all trying to promote our project and brand, but I would argue that the plethora of entries has a reverse effect that let the user confused as to what to install.
So the main question is "what is the primary target audience of the Juno repo?"
- an eclipse user - e.g. a JEE programmer
- an eclipse extender - e.g. someone using eclipse technologies to build an app
At this point, the content of the repo looks like what we are addressing both audience which may be a convenience for us but a nuisance for the end users.
IMO, the Juno repo should be "end user" focused and only include entries whose installation will result in new functionalities to be added to the IDE. Also each entry should have
- a descriptive name (which include removing adjectives such as incubation, extender)
- a minimal number of entries returned when I search for the name
- be adequately categorized
How do we go about exposing the rest of the content for extenders?
- Different repo URLs (e.g. download.eclipse.org/releases/juno/developer)
- Addition of a developer focused category (with nested categories)
wdyt?
Pascal
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
______________________________
Senior Solutions Architect
Committer, Eclipse Mylyn and Virgo
Project Lead, Model Focussing Tools and AMP
