Default Desktop Experience for 11.04

[Ted Gould]

On Fri, 2011-04-15 at 13:52 -0700, Bryce Harrington wrote:
> On Fri, Apr 15, 2011 at 11:17:32AM -0500, Ted Gould wrote:
> > On Thu, 2011-04-14 at 13:16 -0700, Bryce Harrington wrote:
> > > On Thu, Apr 14, 2011 at 12:41:22PM -0700, Kees Cook wrote:
> > > > On Thu, Apr 14, 2011 at 02:17:47PM -0500, Ted Gould wrote:
> > > I don't think we should do this unless we also have the manpower
> > > resources identified to bring apps up to meet the standards.  There are
> > > a lot of otherwise good, powerful applications which simply haven't kept
> > > up with the latest GUI technologies, and it would be shooting ourselves
> > > in the foot to simply drop them.
> > 
> > Well, I don't think we'll ever have the manpower to change all of Open
> > Source for any particular vision.  I'd love that, but I think the
> > expectation is unreasonable.
> 
> Yes, I completely agree there.  Thus I think the tactic of dropping
> applications that don't change to meet our requirements would simply be
> detrimental to our own goals.  In a way it's sort of a blackmailing
> strategy -- do something or else we'll do something to diminish your
> project.  It might work in a few cases, but it's also going to piss
> others off who may choose to do differently just for orneriness, and
> there's going to be a huge number of projects that just won't care one
> way or the other.  I think in the end we'd find ourselves in a difficult
> position of having to either drop a lot of software from the archive
> that we'd actually prefer keeping, or break with the policies.

I think that it depends on how the requirements are seen.  If they're
seen as onerous or arbitrary there'll be rebellion.  If they're seen as
really making the Free Software world better, there'll be general
support.  For sure we should be prepared to remove projects we love if
they don't meet requirements -- it's hard, but necessary.  We shouldn't
start (or really ever) have requirements that'd "drop a lot of software"
from the archive.  It's more about consistently good rather than empty.

> > > If the goal here is to motivate projects to implement particular
> > > technologies that we want to see more consistent across applications,
> > > there are way more effective tactics to employ for that...
> > 
> > Like? :-)
> 
> I'm glad you asked.  :-)

I should have expected that.  :-)

> * Visibility in USC.  Like the blackmail approach but we're using a
>   carrot instead of a stick.  Apps that don't meet the requirement will
>   still be available via apt, but won't be findable through USC.  (Or
>   maybe a checkbox buried deep in a menu allows for non-compliant
>   software.)  Or it could be a factor in determining "Preferred" apps.

+1, perhaps even we could use this for future requirements.  For
instance, you have to have a man page in two releases, but now we're
just going to remove you from USC.

> * Barn raising.  Like a cross between BugDays and Ubuntu Developer Week,
>   you'd arrange a week where each day you'd have a session to discuss
>   and explain one of the requirements, and encourage community people to
>   engage in implementing that functionality for various applications.
>   You build a list of suggested apps to work on, and let people sign up
>   for one to work on (individually or small teams).  Show them how to
>   submit patches to the regular sponsoring process, give some tips or
>   help forwarding the patches upstream.  Look at how well received the
>   PaperCuts project has been; here we're using basically the same
>   approach.

+1, I think that this should be used to help projects meet the
requirements.  It doesn't preclude them existing though.  We should be
helpful, but stern.

> * Publish a Ubuntu Human Interface Guideline.  You'll remember in
>   Inkscape early on we paid a lot of attention to HIG compliance even
>   though we weren't even a GNOME project.  Having that guideline
>   available for reference settled a lot of arguments.  Make it well
>   written, well thought out, and backed by design and usability experts
>   and testing, and I should think it would sell itself, no need for
>   carrots or sticks at all.

While some of these are not about HIG type stuff though, I think that
everything we're asking should be well documented with rationale.

> * Split the archive.  Instead of Main/Universe, you'd have
>   Main/Galaxy/Universe, where Galaxy is the subset of universe that
>   meets the new Ubuntu policies.  Universe still exists for those who
>   really need it, but most people would be encouraged to stay within
>   just Galaxy.

Isn't Galaxy here effectively the Debian archive?  Why duplicate?

> * Roadmap it.  Create a list of all the apps you want to support the set
>   of requirements.  Prioritize and organize them into a sequence of
>   steps, easiest/most-important first, and hardest/least-important
>   later.  Don't attach any due dates, but imply that achieving one phase
>   per Ubuntu release would be desirable.  Then, start from the top
>   implementing the functionality into the first group.  Encourage others
>   to hop in and join the effort at whatever point in the roadmap they
>   feel motivated to work on.  Let the projects on the roadmap know that
>   they're on it; indeed that alone may be enough motivation for them to
>   do the implementation work themselves rather than wait for someone to
>   do it externally.

I think there has to be due dates, but they shouldn't start out as
"tomorrow" and should have escalating consequences.  i.e., requirement
for main in 11.10, requirement for USC listing in 12.04, requirement for
universe in 12.10.  Without due dates you're not really requiring
anything you're just saying "we kinda like this."

> > > If the goal is to clear out clutter from universe and/or main that we
> > > have to support, I would think Debian already should have processes for
> > > this?
> > 
> > It's less about trying to "clear out" as much as "make better."  I
> > imagine that most projects would have the examples I listed as a goal,
> > that they'll get to at some point.  We'd just be establishing a deadline
> > or requirement for that.
> 
> Good luck with that.  ;-)
> 
> Seriously though, surely you remember how much trouble we had in
> Inkscape with *internal* requirements and deadlines...  As I recall it,
> when external people came to us with external requirements, we were
> basically like, "Yeah, if anyone feels like working on it maybe..."
> 
> Setting requirements with deadlines is only *maybe* going to work for
> type (b) projects, and even there I'd be rather skeptical given that so
> many people are doing development in their own freetime and have their
> own priorities they'll tend to first.  It's a more corporate oriented
> tactic that doesn't always fly so well in open source projects.

Sure, some projects really don't care about things like man pages.  They
don't care about a lot of things and will rebel at being asked to do
them.  That doesn't mean we shouldn't strive to work with the projects
that have the same goals as us in building a great user experience.

		--Ted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20110422/e793ce4a/attachment.pgp>