Re: Question to the candidates.

On Tue, May 26, 2015 at 2:42 AM, Josh Triplett <josh joshtriplett org> wrote:
First, while I'm extremely impressed by the huge variety of UI design
ideas that GNOME has experimented with, and many of them have been quite
successful, I think GNOME needs some mechanism to recognize when an idea
isn't working or doesn't really appeal to the majority of users, and say
"well, that was a fun experiment, but let's drop it".  For instance, I
rather strongly suspect many GNOME 3 users would sigh with relief if
alt-tab went back to "switch windows" and alt-` became a
backward-compatibility synonym.  As far as I can tell, though, design
ideas only really tend to get dropped when they get replaced with some
other, newer design idea; for instance, the notification tray gave way
to the excellent new notification mechanism in the latest release of

I think it would make sense to have a convenient way to float design
experiments as extensions or branches, rather than as part of mainline
GNOME, until they become less experimental.  And in the meantime, I
think we need a way, as a community, to decide that a UI experiment was
unsuccessful and should be reverted.

I just want to say that these two paragraphs is just full of win.
There is absolutely needed a mechanism that lets us figure out when
something is not working.  In GNOME, I think we have problems with
either 1) communicating how features are implementing in GNOME 2)
communicating how features (if you want to call them that) are removed
in GNOME.  When features are removed, they do cause regressions and it
is important that at least we have some kind of historical reason why
we removed it in the first place.  While people might object to the
removal or adding, that doesn't matter, only that there is a story.
Maintainers who remove or add features should provide good notes to
the release team on why something was removed or added so that we can
provide a good story to the story.  I sometimes feel that we don't
take into account users who use our systems.  Maintainers might have a
vision of the end state, but end users may not and when the story is
murky it leaves people with vivid imaginations to tell the story.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]