who gets in and why, aka the GNOME Desktop inclusion criteria

[Luis Villa <louie ximian com>]

After much discussion[1] these are the standards the release team
believes we should be using to judge requests for future additions to
the GNOME Desktop.

Like the rest of you, we want a GNOME Desktop that is a complete,
modern, asskicking desktop- a complete set of high quality, integrated,
Free applications that provide at least the functionality included in
equivalent modern proprietary desktops. Hopefully, these criteria will
help us figure out what applications we'll mix and match to get that
ass-kicking desktop.

It should be understood that, like everything else the release team
does, the assessment of these criteria will not be in a vacuum- the
advice of the usability team will be actively sought for usability
assessments, accessibility team for a11y assessments, etc. The final
call, though, will rest in the hands of the release team. 

On that note, the proposed criteria:

*improves overall desktop usability: 

New applications should make the GNOME Desktop a more useful place to
hack, work, and play in. That might include, for example, better feature
parity with other desktops, cool new things other desktops don't have,
feature upgrades from older GNOME versions, or better opportunities for
integration with other GNOME applications. The goal is not to include
every gtk2 application available, but to include the highest quality
applications that will make us competitive with the functionality of
other modern desktops, and which offer a stable platform for improvement
and integration going forward.
 
*developer attitude: 

the lead hackers of new modules have to be willing to work with other
teams, including UI, a11y, etc. We want to have a community committed to
working /together/ towards building the best possible desktop- where
best is not just 'coolest' and 'most powerful' but also 'most usable'
and 'most accessible.' That definitely means flexibility and compromise
are important, both for maintainers and team members- everyone has got
to be willing to work to find ways to make this /fun/ and easy for
everyone else.

*GNOME-ness: 

Apps must use gtk2 and other GNOME2 technologies, and have a GNOME look
and feel. Deprecated parts of the platform (like gnome-config) have to
be avoided, in favor of GNOME2 technologies (like gconf.) Glade should
be used whenever possible to aid in a11y and i18n work. The GNOME2
porting guide [ http://developer.gnome.org/dotplan/porting/ ] has more
details on making an app a GNOME2 app.

*Free-ness: 

While it is perfectly possible to write non-Free apps that fulfill
basically all of these requirements, apps must be under a Free or Open
license and support open standards and protocols. Support of proprietary
protocols and closed standards is of course part of the world we live
in, but all applications that support closed protocols should also
support open equivalents where those exist, and should default to those
if at all possible while still serving their intended purpose.


The following criteria must also be met before the app ships as part of
the desktop (but obviously aren't intended to be met when an app is
first proposed as part of the platform):

*quality: 

The app has basically no repeatable/repeated known crashers. Major
features/buttons/options/etc. work or are removed. The developers
are working to fix other bugs at a reasonable rate.

*UI: 

the hackers should cooperate as much as possible with the UI team to
improve the general usability of the app. This might be expected to
minimally include (but is certainly not limited to) UI issues like GNOME
look and feel, HIG compliance, careful choice of default settings, and
clean interface design. [HIG is at
http://developer.gnome.org/projects/gup/hig/ ]

*a11y: 

The app is compliant with a11y documentation to as great an extent as
possible, and the maintainers have made good faith efforts to fix all
a11y bugs filed in a timely manner by the a11y team. [Note that if a11y
docs are incomplete or not ready in a timely manner, this requirement is
obviously moot. The Release Team does not expect hackers to become
experts on topics outside of their domain- only to respect and act on
the knowledge of those who are experts.]

*i18n: 

all text is i18n-ized. [We use 'all' here because it is easy to get
right and we get extensive testing of this issue.] In addition, all
reasonable steps have been taken to localize other parts of the
application that might be region-dependent, like temperatures, times,
etc.

*using GNOME resources: 

if the app isn't in GNOME CVS, there had better be a damn good reason :)
Possible good reasons include (but not limited to) library with intents
towards usage by both GNOME and KDE and concerns with the speed of GNOME
anoncvs. Using other GNOME resources, like GNOME ftp and
bugzilla.gnome.org, is also encouraged.

Anyway, so, that's what we're thinking :) hope it clarifies things a
bit. Comments and thoughts, as always, welcome.

Luis, on behalf of release team

[1]mostly with pants on