Re: Question to the candidates.

[Sriram Ramkrishna <sri ramkrishna me>]

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
> GNOME.
>
> 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.




sri