Re: [cross-project-issues-dev] Question about the Branding requirement f

[David M Williams <david_williams@xxxxxxxxxx>]

I think you raise some interesting points, Dave, but I'm not sure we can 
come up with the right rules for granularity and will need to rely on each 
PMC to do what they think is best. As we evolve to this new style, 
community feedback can guide improvements in the guidelines. For now, the 
Planning council could only come up with these guidelines: 

Provider name should always start with "Eclipse ..." followed by project 
name. It is (still) up to each PMC to decide how best to describe their 
project in a meaningful, balanced fashion (either as one top level one or 
as multiple pieces). Avoid special symbols (e.g. ':' or "-") unless they 
are part of the project name. Avoid acronyms (unless in common use in 
software industry, such as XML, or PHP). Capitalization should follow 
"headline-sytyle capitalization": The only words that are not capitalized 
are articles (except as the first word), coordinating conjunctions (for 
example, and, but, and or), prepositions (except as the first or last 
word), and the to in an infinitive. ) 

For now, only the branding/primary feature is important to get right. Long 
term, all plugins and features should use the correct "Provider Name", to 
be the same as that branding plugin/feature, but we do not encourage a lot 
of last minute touching of plugins just to fix the provider name. It can 
be phased in when other changes are made to those plugins, as appropriate. 


Hope these help. 





From:
Dave Steinberg <davidms@xxxxxxxxxx>
To:
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date:
03/23/2009 11:08 AM
Subject:
Re: [cross-project-issues-dev] Question about theBranding requirement for 
Galileo
Sent by:
cross-project-issues-dev-bounces@xxxxxxxxxxx



It's almost enough to make one pine for the simpler days when everyone 
just used "Eclipse.org" as the provider, isn't it?

In all seriousness though, it seems unfortunate to me that we're talking 
about how to cram up to three pieces of information (Eclipse, top-level 
project, and subproject) into a single field. Leaving it to the projects 
to decide will probably result in a mess of inconsistency, while more 
rules will no doubt feel like straightjackets to some projects.

I think the best pieces of guidance we've seen so far were to start the 
name with Eclipse and to limit this only to "major projects (the top-level 
projects except for the Tools and Technology projects where it is the 
sub-projects)," as bug 252813 originally specified. I'm seeing mention of 
sub-project names in this thread (Equinox, EMF, JDT, etc.), which seems 
like a recipe for chaos.

My understanding of this requirement was that we were supposed to 
contribute a nice array of icons on the About Eclipse dialog, showing the 
major components in the running product, each with a suitably descriptive 
tool tip (which comes from the provider name of one of the associated 
features). So, I really don't understand why sub-projects that don't have 
their own icons (like Equinox, EMF, or JDT) should have their own provider 
names.

Cheers,
Dave

-- 
Dave Steinberg
Rational Software - IBM Toronto Lab
mailto:davidms@xxxxxxxxxx


Thomas Hallgren ---03/20/2009 04:58:01 AM---Ed Merks wrote: Thomas,


From:

Thomas Hallgren <thomas@xxxxxxx>

To:

Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>

Date:

03/20/2009 04:58 AM

Subject:

Re: [cross-project-issues-dev] Question about theBranding requirement for 
Galileo



Ed Merks wrote: 
Thomas,

Are you seriously suggesting that we come up with a better name than EMF? 
We've been using for the last seven years... 
Not really. I agree that EMF is a strong brand today :-)

What I'm serious about is that if project branding is important to Galileo 
and coming release trains, and if we really care about how things look 
when listed together and want to convey an impression that it all stems 
from the same family, then the frequent use of abbreviations is starting 
to become problematic. The problem gets worse over time since many new 
proposed projects continue in that vein.

- thomas
_______________________________________________
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