Re: taking features away (compact view removed from Nautilus)
Emily Gonyer <emilyyrose <at> gmail.com>
2012-07-02 14:06:37 GMT
On Mon, Jul 2, 2012 at 4:38 AM, Allan Day <allanpday <at> gmail.com> wrote:
> Adam Dingle <adam <at> yorba.org> wrote:
>> I realized recently to my surprise and dismay that the compact view has been
>> removed from Nautilus:
> Adam, if you wanted to discuss this change, you could have done so on
> the bug or on the Nautilus mailing list, or by asking on
> #gnome-design. I would have been happy to have given you some
> background on why the decision was made.
> Jon has been doing some fantastic work on Nautilus recently. It was
> getting very little - if any - developer attention and he has stepped
> up to make dramatic improvements, including addressing long-standing
> complaints. I'm really excited about the next release of Nautilus
> thanks to his work; instead of having no movement whatsoever, we are
> going to have lots of great improvements to talk about.
> There has been a bunch of discussion around these changes. Not the
> mailing list approach that you seem to want, but the existing Nautilus
> maintainers have been involved and a range of design people have been
> consulted. I personally agreed with removing compact view - I think
> it's a good change.
>> I'd like to end on a constructive note. I propose that GNOME adopt the
>> following policy. No major feature will be removed from a core GNOME
>> application before a discussion has occurred on a public mailing list such
>> as this one (or on a Bugzilla bug, with a prominent mailing list
>> announcement pointing to the bug in question). I also propose that all such
>> feature removals that have occurred in the 3.6 development cycle be reverted
>> until such discussion has occured .
> I strongly disagree with that suggestion. I don't think it would be
> workable, and I don't think it would make GNOME a better place to
> work. There is still time to discuss changes that have been made; we
> don't need to wrap ourselves up in policies.
>> The features in core GNOME apps are the result of years of hard work and
>> consensus building by our community.
> There is no consensus. There are features that some people have gotten
> used to, and there has been a long period of adding features without
> considering how they fit into the whole.
> No one objects when you add a feature, yet features can ruin a design
> if you keep adding them. Nautilus has been at saturation point for a
> while; it's at the stage where it's actually very difficult to improve
> it without taking something away.
> IRC: aday on irc.gnome.org
> Blog: http://afaikblog.wordpress.com/
> desktop-devel-list mailing list
> desktop-devel-list <at> gnome.org
Then I guess the question becomes how we can involve the greater GNOME
community in these sorts of decisions. Existing designers and
developers may have been consulted, but they are not the only ones
affected. The choices that a handful of people are making affect
everyone who uses GNOME, though the community is rarely consulted or
even notified until the change has been made and all but finalized. I
suspect that I am not the only one disturbed and disappointed by what
seem like rapid changes to existing projects without public
discussion. If there was discussion regarding the removal of compact
view and later icon mode with text, I'd like to know when and where it
occurred as well as when and where I should keep an eye out for future
changes and removals.
As I understand it (and I'm rather new to the development community,
so I may be wrong), adding features, new modules, etc to GNOME is an
often lengthy (and perhaps more importantly, transparent) process of
proposal, review, design and re-design, which seems proper. It serves
to keep GNOME running smoothly and the community at large involved in
development. Unfortunately though, the process for removing features
doesn't appear to be nearly as robust and/or transparent.
A handful of developers and/or designers talk amongst themselves and
decide to remove features without consulting the community at large.
As a result changes like the ones above occur rapidly over an hour or
perhaps a day, without any sort of public discussion or even
notification (aside from postings on bugzilla and git, which
apparently occur after discussion). And then on release day we are
surprised that feature XYZ has been removed. Since the removal
occurred a month or more back, we are told that we had ample time to
disagree and since we failed to do so, tough luck. However, since the
removals are done quietly without so much as a blog posting this seems
disingenuous at best - even when posters replied within a few hours
 to the change on bugzilla, they were all but ignored (at least
publicly) by those affecting the change.
I have long been under the impression that since GNOME is a free
software project, development is (or at least should be) done in a
public, transparently and with inclusion as a primary goal. Recently
it would seem that transparency has been severely lacking in GNOME's
ongoing development. As a result, feelings are hurt and minor
disagreements spiral out of control. What Adam, Holger, myself and
many others are advocating for is a more open development process so
that the community who uses GNOME software can be included in the
future with regard to both feature additions and removals. Set up a
dedicated (public!) mailing list to feature removals and additions if
you like where any and all additions and/or removals must be posted to
a week or two in advance and where discussion can occur. What would be
so wrong with such a policy?
Whatever you can do, or dream you can, begin it. Boldness has genius,
power and magic in it. - Goethe
Be who you are and say what you feel because those who mind don't
matter and those who matter don't mind. - Dr.Seuss
Not everything that can be counted counts, and not everything that
counts can be counted. - Albert Einstein