GNOME.org
 

My proposals for Gnome

Here you go..,

I'm emailing a couple of proposals that might be of interest to Ximian that
I've posted in the past, that I'm curious if you happened to see.  They are
not related to the motivation/assistance side of things [refers to a
previous email exchange], but would, I believe, be valuable advancements for
Free Software, Gnome, and Ximian.

1) Feature Request/Marketing Survey system
2) An automated bug discovery and reporting tool
3) Highly advanced help and searching tools (The Ultimate Help system)
4) An advanced backup/storage service for Ximian

1) Feature Request/Marketing Survey system-


Back when the Evolution mailing list first opened I started doing a 'Feature
Request List' which I believe you are having Duncan do right now.  What I'd
like to do, is have a web page or program set up so that when they are using
a program they can request a feature right then.  I realize that the bug
tracking tools have this built in, but they are really to complex for a
typical user.  Also, features should be actively solicited - many users,
especially the less assertive - are uncomfortable requesting/suggesting
additional features because they feel that doing so is ungrateful.  Compare
the number of features suggested before and after my solicitation of
features on the Evolution mailing list.  We went from about 10 suggestions/
requests to about 200 or so (Which pared down to about 150 or so...) in a
very short period of time.

Thus what I suggest is a pop-up message that asks (after the user has used
the product a couple of times, or a week, or something), if the user has any
features that they wish were available, or if they have any complaints or
annoyances that they wish were changed.

Thus you would likely be getting feedback from 90% of your users, whereas
now, you probably only receive feedback from less than 1%.

The second stage of this is the survey.  This would popup once a month (or
so), and have users rate the feature requests that they and others have made
as to how desirable/important they are.  (The requests would likely be
sanitized and aggregated, etc. since many of the requests will be
duplicates).  The survey might also request some basic demographic
information (such as type of work/job) and ask for user skill level
information.  Then you will likely find for instance, that for some
demographics - say Administrators - a feature such as 'Bounce' (a command
for mail clients that forwards an email as if it were the original sender -
useful if you get a lot of mail that is directed to the wrong person) is a
Killer Feature for Admins, whereas it leaves Accountants and Secretaries
cold.

Since Ximian (I assume) plans to target businesses in the not too distant
future, this might be very valuable in finding features to entice business
users to switch from that 'Other Brand'.

Note that your corporate partners, such as IBM and Sun might be interested
in having their employees take such a survey.  Also, many Admins that
currently use Linux might be willing to have their users take such a survey.


2) An automated bug discovery and reporting tool

This should be a cooperative effort between Ximian, RH, SourceForge, and
everyone else under the sun.  What I'd like to see is Tinderbox set up with
additional functionality - so that upon CVS checkin a list of things happens

a) Runs Lint b) Runs a Pretty Printer (checks for white space
consistency...) c) Compiles software with a memory profiler debugger etc. d)
Runs the software with a memory shaker, a tool that gives garbage input,
etc.  5) Generates bug reports 'automagically' (just adding a comment to
previous bug reports that give the same error message), and sends an email
to whoever broke the CVS (assuming that it doesn't compile)

I emailed Leaf mozilla org and I've attached his response below.  (Basically
he says none of the above should be a problem to implement).  Also when I
posted the idea to gnome-devel, Havoc though it was a great idea, and that
getting the hardware wouldn't be a problem, but getting a script maintainer
for it might be.  Since many projects are already using Tinderbox (i.e.
Ximian, Mozilla, and Eazel) it would likely be valuable to centralize them
so that we aren't getting massive duplication of effort.  This should speed
development time for all of the projects and should result in bugs being
caught much sooner (and thus being less costly to discover and fix).

3) Ultimate Help System

I'll just attach the original emails.  Telsa suggested some clarification,
namely that the response system is not limited to IRC, but that IRC is a
example system that could be used. I've included the relevant quoted
material from my exchange with Telsa below.  I had lots of positive feedback
on this, I'm currently looking at the Gnome Doc list to see what I need to
do to try and implement it.

"In reality, I was thinking of an Admin setting up a local help channel.
The admin then requires all (most?) help requests to be submitted via the
help.

The users aren't actually accessing IRC, nor do the admins actually need to
be in IRC to receive the message - any sort of messaging service would work
fine as long as there a is a way for the user to enter the question, and the
admin to send the response.

The admin then uploads his responses/mappings of various questions and
answers to a central repository.  The questions and answers are then updated
for use by those in the future.

It really wasn't meant to direct stuff to current gnome-help channels, just
allow admins to act collectively and allow companies such as Redhat, sun,
IBM, Suse, etc. that sell tech support - to add this as an option as a
'value-add' to their distributions (thus they would have a proprietary
channel to ask questions for their paying customers )."


4) Improved backup service

basically, most current back up systems have you back up everything to the
network, which is highly wasteful.  Instead, back up custom data and any
special configurations.  Restore the majority of the system from a Stock
Redhat/Debian/Whatever CD but the install would be guided by backup, which
would only install their previous software.  Then it would download the
custom configuration and data, and boom - your back in business.  Thus this
backup system could be used for those with lower bandwidth (I.e. - me
sharing a dual ISDN line with 6 coworkers), yet still allow a full system
recovery without the hassles of frequent manual backups.



Ok, I'm done, thanks for listening, and good luck with Ximian,

Tom M.
TomM pentstar com




-----Original Message-----
From: miguel ximian com [mailto:miguel ximian com]
Sent: Thursday, June 07, 2001 11:50 AM
To: Tom Musgrove
Cc: Sri Ramkrishna; Jonathan Blandford; Jeff Waugh; gnome-love gnome org
Subject: Re: [gnome-love] Code Auditing as Love



> Miguel have you had time to look over those proposals yet?

Nope.  what about posting them to the list, so we all can follow up on
them? ;-)

Miguel
--- Begin Message --- 
I have an interest in substantially improving the help systems that are
provided for Free software.  Specifically, I'd like to make them easier to
use, and more useful for both power and new users and reduce the number of
'stupid'/'repetive' questions that are asked in the IRC channels.

First my critique of current help systems

The reason users use help as a last resort, is that help is generally almost
USELESS to users who are not skilled at picking the search terms that the
help creator used.  Instead, they will ask someone who is knowledgeable
about what they want to do, or is good at searching help.  Another reason
that users use help as a 'last resort' is that there is a fairly good chance
that what they want to do may not be explained in the Help.  The third
reason is that help does not necessarily explain the answer in such a way
that the user can understand.

In order to solve the above problems, I propose the following

1) synonym mapping of search queries
If a trusted developer can map the search terms that a typical user types to
more accurate terms, then a large step towards eliminating the problem of
using different search terms from the help creator can be made.  I'd guess
that 50% of the time that naive users don't find the help that they are
looking for is because the term that they are searching on is not the same
as what the help document author used.

To make it even more useful, fuzzy matching can be used for misspelled words
(another common problem with searches by unskilled searchers...) or
alternatively offer other potential spellings (as is done on some of the
popular search engines such as google.)

2) help linked to IRC
If the query doesn't immediately find what the user was looking for, the
question can be submitted to a IRC help channel (one populated with
'trusted' respondents so that they don't get profanity, etc. as a response).
The IRC person then searches help and maps the question to the question
listed in the help (if the answer exists in help).  The question then goes
to a database to be added to the help system on the next update.

If the query does not exist, then the following can be done...

a)  Request more information - the IRC person creates a yes/no question for
the user to solicit more information
again, submitted to the database for future reference (this would be similar
to the Microsoft guided help...)

b)  Create a tutorial on how to solve the problem - this could be a script
description generated from actually doing the action, with comments
inserted.

Thus for 'how can I make my text bold faced' - I would select text, click on
the bold font character.
Two scripts would be generated, one a text description as above, the other a
visual hint system, that would highlight the next action to be done.  Thus a
small box near the text say 'highlight text'.  Then after the text is
highlighted, a box above the boldface icon 'click on icon'.  This would also
be amendable to text to speech (TTS) software as well.  This could also use
the custom mappings of the user, so they can use their keybindings in the
explanation...

This addresses all of the problems above, and could save tech people and
users many hundreds of hours.  Tech support at some companies would likely
voluntarily hang out in the IRC help room (or be required by management..).

3) submit more information
if the help person in the IRC channel does not have sufficient information,
then a button can be used that submits a screenshot of the users program.
Also, a brief listing of current software can be submitted (I.e. - I am
using Debian Potatoe version foo.bar with Gnome version fuz.baz, etc.)

This can avoid the problem of having the user look up the assorted
information themselves, and save the tech and the user time.

4) put my computer in the users state
The above info can be used to put the techs computer in a state similar to
the users computer temporarily.  (the degree to which this can be done will
certainly vary, but at least going to the same window manager with the same
programs open might be useful...).

Of course once the user has been helped, the question and the solution can
be added to the help system (if not automagically, then with a small amount
of clean up, or with a review by a 'trusted' developer).

I sincerely believe that this might cut the amount of time spent helping new
users and solving problems on free software operating systems substantially.
This would also give us a significant edge in ease of problem solving over
many of the commercial software systems.

I'd appreciate your thoughts and comments,

Tom M.
TomM pentstar com


_______________________________________________
gnome-devel-list mailing list
gnome-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-devel-list

--- End Message ---
--- Begin Message --- 
I apologize tremendously for not writing you back sooner, i've moved to
a different state, and am still getting caught up on my correspondences.

I've interspersed comments below...

Tom Musgrove wrote:
>
> Greetings Mr. Nunes,
>
> I've brought up on the gnome-dev, and debian-dev, the idea of setting up
> software to
> perform automatic testing for the various gnome and debian projects.
Havoc
> suggested that Tinderbox could be set up to do what I wanted (below are
the
> primary things I'd like it to do...).
>
> 1) Runs Lint
> 2) Runs a Pretty Printer to check for white space inconsistencies(Which
> generally denote that the programmer either misunderstood the syntax,
> mistyped the syntax or white space, or was being lazy, all of which should
> be checked.)

This can be added, pretty easily, to the existing scripts as a
pre-compile, post-checkout phase.

> 3) Compiles the software with a memory profiler/debugger (Electric Fence,
> checker, ccmalloc, etc.)

Provided this is easy to pass into the software's build configuration,
not a problem.

> 4) Runs the software, and utilizes assorted programs such as memory
shakers,
> programs that generate garbage input, etc.

We run some very basic tests (implemented as commandline options to the
program we're running itself; we're a bit project-focused with the tool,
but making it more general is a good goal).

> 5) If errors, crashes, etc. are generated, a bug report is filed, and an
> email to the person who did the last check is sent.
>

Currently, we don't send email on a failure, but it is probably a good
idea to do so. We rely on the policing of other people doing work on the
tree to regulate nastiness that causes red (build failure) or orange
(test failure) tinderbox results.

> So, what I'd be interested in learning about Tinderbox is the following...
>
> 1)  Once Tinderbox is set up, how much maintenance activity is needed to
> keep it up and running?

Once it's running there are a few things that need watching:
* updates and new features to the script itself
* different build methods for the project (using non-standard configure
  or something).
* cvs "issues," such as cvs removed directories/header files being
erroneously included in depend builds, erroneously added files
  (where case is the only differentiating factor), or
moved-in-the-repository source files (when/if refactoring of code
  occurs)

> 2)  How do the maintenance requirements scale?  Will running 30, 100,
1000?
> CVS projects through it be substantially more work than running one?
>

I think so, yes. We run 30 or so projects internally at netscape, but
the administrative/maintenance costs are distributed by the groups that
are running the tinderbox clients. The server is fairly easy to
maintain, it's been running, essentially unowned, for close to two years
internally at netscape. There are some things that could use touching
up, such as diskspace usage and ease of adding new projects to the
server through the gui. Security is something that hasn't even really
been considered, either.

> If you could take the time to answer these questions I'd greatly
appreciate
> it (or if you can point me to a FAQ that would answer those questions
> <grin>).
>

I can point you at the scripts, server
(http://www.mozilla.org/tinderbox.html) and client
(http://lxr.mozilla.org/mozilla/source/tools/tinderbox/).

> Thanks for your time,
>
> Tom Musgrove
> LetterRip
> TomM pentstar com

--- End Message ---
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]