Re: Proposed Memebership Guidlines

[Dan Mueth <dan eazel com>]

It is certainly important to get feedback from GNOME users and to
effectively use it to improve GNOME.  I have been thinking about how this
could be done through a GNOME User Feedback Project, which doesn't
currently exist.  The idea is to have a small team take care of
accumulating feedback from users and then analyzing it to identify the
most significant improvements which can be made.  The results could be
periodically written up and given to developers. (Bart did this for
Nautilus 1.0 by analyzing all the emails on slashdot, Gnotices, and the
mailing lists and came up with a top twenty wish list for Nautilus users,
much of which was implemented for Nautilus 1.0.3. He also set up mailing
lists for users to express their wishes and complaints.)  The data
collection can be done through various schemes, such as mailing lists, web
applications, surveys, etc.  Analysis could be done by hand or by the web
application which collects the data. (eg. Users could submit items and
other users could vote on them.)

I think this would be a better forum for users to give their input on
GNOME than by voting for the Board of Directors.  Most GNOME users do not
know the primary GNOME contributors and do not know which ones would be
the best Board members.  I'm afraid that our board would be elected based
upon their popularity, name recognition, and campaigning skills and not
based on their reputation they've established and work they've done
directly within the GNOME community.

Dan


On 3 May 2001, Adrian Custer wrote:

> Hello everyone,
>
> {NB This has been made obsolete because the proposed guideline has been
> adopted. However, the foundation should still address this issue.}
>
>
> The GNOME foundation membership guidline as it now stands will be
> superbly useful in the near term, the next few years, but, by alienating
> the very people GNOME intends to help, will be detrimental to the GNOME
> project over the long term. The foundation needs input from "pure users"
> so as to plot a direction and encourage work on parts of the platform
> that are most critical to users but might be less obvious to the
> "anarchic community" of developers and other contributors.
>
> In the near term, getting to GNOME 2.0 and even beyond is so much a
> question of infrastructure that the needs of the platform are perhaps
> clearer to the programmers than to anyone else. However, for GNOME to
> address user needs or move beyond the duplication of current kinds of
> software to develop new tools for users, GNOME will have to include
> those users in its very core. As a non-developer but knowledgeable
> computer user, I can see a gap between the desires, interests and
> enthusiasm of developers and the needs of users. The GNOME foundation
> must take it upon itself to bridge that gap because no one else will.
>
> The opening paragraph of the Membership policy is set as a response to
> the question of who is elligible for membership. This paragraph balances
> quite nicely the desire to include only those who make "non-trivial"
> contributions against the reluctance to exclude anyone in the community
> who might belong for any reason. Since the membership committee is able
> to review any application and make exceptions for any interested user,
> there is little danger that anyone be excluded despite being interested
> in the platform over the long term. My concern is over the explicit
> committment that the GNOME foundation makes to be driven by the users as
> opposed to assuming it is capable of guessing what their needs will be.
>
> Now developers are obviously users so they can easily identify many
> needs that all users may have. There is also a very good line of
> communication between users and developers albeit through bug
> submissions and mailing lists which require a relatively sophisticated
> user. I can already see a problem arising either when a computer user
> has a pressing or overwhelmingly important need which never makes it to
> the developers or when there are user needs that developers do not
> share.
>
> I have two examples of user needs that I realized developpers would
> never run into, a non-gnome example and a gnumeric example . The library
> system in this university allows you to renew your books online through
> a telnet interface. This requires you to enter a bunch of information
> and then type "ren #" for each book in the list of books you have
> checked out. I met a historian grad student with 200+ books checked out
> who would spend an hour every month renewing her books. At the school's
> "linux user's group I asked why no one had ever writen a client or
> expect script to do this automatically. It turned out none of the coders
> ever went to the library. To this day, there is still not a nice client
> available for all the students to use--it makes me hang my head in
> shame, knowing there is a better way to do things, one that's just
> beyond my capabilities.
>
> As a second example, I've spent a lot of the past year playing with
> gnumeric and using it for my research. The developers are doing an
> absolutely amazing job with the spreadsheet. From the perspective of
> linux users in the scientific community, the lack of a good spreadsheet
> has been the biggest drawback to the use of a free software based
> platfrom over the past seven years. So a user from the scientific
> community might tell the foundation that a spreadsheet is overwhelmingly
> more important to their adoption of the platform than a component
> architecture. (I know this is not the only perspective---it's just an
> example of developers not sharing the same needs as users.)  Consider
> also a particular use of a spreadsheet when a user  inputs 8000+ lines
> of data. I doubt any developer has ever spent two weeks just inputing
> data into a computer. There are some serious issues which arise during
> that kind of work, the kind of work users actually do, which make a
> spreadsheet usable or useless. From a users' prespective, these elements
> will make or break the ability to use the software and yet may be so
> trivial and boring from a developer perspective that it won't get
> addressed until the big issues are resolved. This is fine while there
> are massive other needs but does have costs in terms of getting users to
> the GNOME desktop.
>
> These examples merely illustrate that there are times when developers
> are going one way and users needing something else. Since the users
> cannot develop on their own, and the developers are busy doing other
> important (or fun) work, there is a real threat that a gap opens up. I
> think the GNOME foundation should address this gap as the effort
> matures. Part of this may include trying to open other channels of
> comunication to new users, reaching out to the older users to find the
> most needed pieces, encouraging work which is less interesting but more
> useful and possibly encouraging an active part of the user community to
> join the foundation.
>
> I hope that these thoughts help the foundation consider where it is
> headed. Thanks for all the great work and congratuations on getting off
> the ground.
>
> cheers,
> adrian custer
>
> dept of entomology
> uc berkeley
> acuster nature berkeley educational
>
>
>
>
>
>
>
>
> _______________________________________________
> foundation-list mailing list
> foundation-list gnome org
> http://mail.gnome.org/mailman/listinfo/foundation-list
>