Re: taking features away (compact view removed from Nautilus)

[Emily Gonyer <emilyyrose gmail com>]

On Mon, Jul 2, 2012 at 4:38 AM, Allan Day <allanpday gmail com> wrote:
> Adam Dingle <adam 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.
>
> Allan
> --
> IRC:  aday on irc.gnome.org
> Blog: http://afaikblog.wordpress.com/
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list

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
 [1] 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?

 [1] https://bugzilla.gnome.org/show_bug.cgi?id=676842

Emily

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