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

Re: Developers vs Grandmas



On Fri, 2008-10-24 at 10:13 -0300, Rafael Gomes wrote:
> I agree 100% too, but we can do one of the two options:
> 
> First, ask to upstream change this options to improve the life of
> end-users or change this options in Fedora.

The confusion I have reading the several replies you are all agreeing to
is this:

* People agree we need to work with upstream and not change their
software, but
* People agree we need to change the upstream software

For example, changing gconf default behavior is in fact changing the
upstream software.  Now Nautilus on Fedora would behave differently.
Any bug reports need to include a list of all the changes we made to the
defaults, giving Fedora more to maintain.  All based on some instincts
and reports that really should be made as bug reports and observations
directly to the upstream!

There is very little benefit to Fedora, our users, and the overall
community for us to focus on changes we can make to upstream to improve
our own user's experience.  If they change is valid and worthwhile, it
needs to happen in the upstream.

- Karsten

> 2008/10/24 "Jóhann B. Guðmundsson" <johannbg hi is>:
> > Luis Felipe Marzagao wrote:
> >>
> >> Exactly! It's clear it's not in the project objective to alter upstream
> >> software. And in fact I agree it shouldn't be!
> >>
> >> The trouble is the end-user doesn't even know what upstream means. In
> >> fact, I think the end-user won't even want to know what it means, as long as
> >> the system is running fine. For him, Fedora is an operating system. And the
> >> GNOME example is very good for this matter. There are somethings that don't
> >> imply altering the core of upstream projects in order to make the "out of
> >> the box" user experience more happy :)
> >>
> >> A single line, for example, could improve the user experience when
> >> entering GNOME on Fedora:
> >>
> >> gconftool-2 -s -t bool /apps/nautilus/preferences/always_use_browser true
> >>
> >> Bingo! A single line (maybe with some other adjustments) in any rc.local
> >> file or any other place specifically designded by Fedora Project should make
> >> the end-user experience a lot better. And it does not require any upstream
> >> intervention or any opinion change by GNOME upstream team. And is very
> >> simple to maintain. And that's it, the end-user would enter Fedora for the
> >> first time and would not complain about a zilion windows opening every time
> >> he clicks on a folder.
> >>
> >> It's just an example, but my point is there are small things that makes
> >> the user experience better and does not require huge changes on coding. I
> >> think this is the kind of problem Fedora Project should pay attention to, as
> >> you adequately put.
> >>
> > I agree 100% here.
> >
> > There are bunch of little things we could do to make Fedora more user
> > friendly to the end-user.
> > ( Actually basing on my own experience with end-users Gnome has begun going
> > backwards on usability
> > it has become so simple that is hard to use. End users expect certain
> > options, buttons to be there along
> > with hints if uncertain of how to do things )
> >
> > Gather faq statistics from the Fedora forum and #fedora channel and address
> > those issues.
> > ( if possible ).
> >
> > It also has to be realized that developers are end-users too and if Fedora
> > does not make
> > good enough first impression to them, how can the project expect them to get
> > involved?
> >
> > Best regards
> >                  Johann B.
> >
> >
> >
> >
> >
> > --
> > Fedora-marketing-list mailing list
> > Fedora-marketing-list redhat com
> > https://www.redhat.com/mailman/listinfo/fedora-marketing-list
> >
> 
> 
> 
> -- 
> Rafael Gomes
> Consultor em TI
> Embaixador Fedora
> LPIC-1
> (71) 8709-1289
> 
-- 
Karsten Wade, Community Gardener
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41

Attachment: signature.asc
Description: This is a digitally signed message part


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