Re: GUP Proposal Organization

[Gregory Merchan <merchan phys lsu edu>]

On 30 Jul 2001 11:06:39 -0500, Paul Joseph Thompson wrote:
> Hmmnn. I have an idea concerning the way the GUP goes about making 
> proposals for changes, etc, to the Gnome project as a whole. This 
> idea is the result of a small idea that built into a larger idea, and 
> then into this idea.
> 
> The Smaller Idea
> ----------------
> 
> The small idea was to change the term Applet (as we currently use it) 
> to something else. My point is that Applet is confusing to the type 
> of user we need to think of as our average user. The average user is 
> going to see the term Applet and think, "Oh, that must be Java. What 
> does that have to do with the Panel?"
> 
> As a matter of fact, I am not sure why the term Applet was ever 
> chosen by Gnome in the first place as it was already widely known to 
> mean something else. Let's fix that problem.
> 
> I don't necessarily know what I think would be better. I did see a 
> suggestion somewhere to change Applet to Gadget, which I think is 
> pretty good. The important point to me here is just that Applet is a 
> bad term to use and I'd hope we might consider switching.
> 

Applet is, afaik, a recently coined word and although often used to
describe Java applets its meaning is not limited to those. However,
insofar as it is jargon and confusing jargon at that, it use in end-user
documentation and applications should be eliminated.

> The Middle-Sized Idea
> ---------------------
> 
> My medium sized idea was that we create a GUP Proposal for 
> terminology changes within the Gnome project. I have seen many such 
> changes suggested around here recently. For instance, the changing 
> of "Terminal Emulator" (or whatever it was called) to "Command 
> Prompt" (or whatever was decided upon). I think that terminology 
> changes are one of the high-level categories of changes that we will 
> come up with for Gnome.

There is a word list & glossary being developed for the GUP.

http://www.phys.lsu.edu/students/merchan/GUP/ghci-gloss.html

Please see the notes at the top of the list and also note that the first
one appears to be a point of contention thusfar on IRC.

> The Real Idea
> -------------
> 
> Now, finally, the big idea I wanted to throw out there. This idea 
> concerns the organization of GUP Proposals.
> 
> As the GUP progresses, we will come up with a variety of changes that 
> we feel should be made to different aspects of the Gnome user 
> interface. Some of these will be 'Look & Feel' type changes (i.e. the 
> way a dialog looks, presents information, etc). Some of these will 
> be 'Terminology' changes (like I mentioned above). Some of these 
> might be suggestions for how a particular application, dialog, etc 
> might be reworked on a higher-level to make it more usable, etc.
> 
> I want to suggest that we use a relatively structured format to 
> organize our proposals. This format should include the following 
> pieces of information.
>

I think this is a good idea and we should perhaps write a DTD or
xml-schema to encourage it. (Someone could probably write a very simple
editor/mailer/etc. to simplify following procedure even further.)

>   Name: A simple, descriptive name for the change proposal
> 
>   Category: Look & Feel (id prefix = 'LF')
>             Terminology (id prefix = 'TR')
>             Application Organization (id prefix = 'AO')
>             (more categories as needed)
> 
>   Proposal ID: This would be code that would identify a specific
>          change. It should identify first the category, then the
>          specific change within the category. For example,
>          LF-0001, LF-0002, TR-0001, TR-0002, etc...
> 
>   Status: Describes the status of each change proposal.
>           One of {New, In Progress, Approved, Rejected} (etc)
> 
>   Version: Starts out with 0.1 for new proposals, moves to 1.0
>            when approved. Increase minor revision number when
>            changed. For instance:
>               0.1, 0.2, 0.3, 1.0, 1.1, 1.2, 2.0, 2.1 ...
> 
>   Author(s): GUP team member(s) who created the original proposal.
> 
>   Signatories: Those who sign on to the change.
> 
>   Editor(s): Other GUP team member(s) involved in the authorship
>          of the proposal. These are the other people who helped
>          the change get to it's final state.
> 
>   Scope: This item defines the applications, modules, components
>          of Gnome that are impacted by the change proposal
> 
>   Summary: Brief summary of the change proposal
> 
>   Description: This is a detailed, verbose, description of the
>          change. It can contain ASCII or graphical mockups, charts,
>          or whatever else is needed to get the point across.
> 
>   Reasoning: This is the reason this change should be implemented.
>          This better be good, as it is the section that tells the
>          world why this particular idea is important.

(Rationale is perhaps a better word.)

>   Graphics: This is just a collection of the graphics that are
>          needed to get the point across. Since this will be pretty
>          common, I thought this should be a separate category.
>          These images are probably also linked or show inline in
>          the description section.       
> 
> This could be implemented just by creating documents with this sort 
> of structure.
> 
> What would REALLY be cool (which may be something that could be 
> implemented later) would be to create a web application that would 
> keep proposals in a database, automating the creation, modification, 
> presentation, and signing of these documents.

Though I see that a web application is presently the simplest solution
to implement, I favor development of a simple application.

> 
> Ok, now for MY reasoning for using these type of documents. I think 
> that there are lots of areas that the GUP can help Gnome improve. In 
> order to be effective at our job, we need to make sure that we 
> structure our work in some logical, well presented, format. The 
> format I have suggested above will accomplish this task nicely.
>

Indeed. I think the first step is to have a working environment with
some internal documentation for the GUP and whatever tools we need to
speed the process along.

> Please respond to this email with thoughts, comments, criticisms, 
> etc. If you have any items you think should be added to this format, 
> please toss them out here. Or, if you think it is a terrible idea, 
> tell me that, too. :)
> 
> Also, please feel free to make suggestions for alternative and 
> additional options for the Category and Status items. The ones I 
> listed above are just what I came up with off the top of my head.

Only thing that comes to mind is keeping with RFC-style where
appropriate.

> Thank you for your time...
> 
> --
> 
>             Paul Joseph Thompson
>             captbunzo squirrelmail org

Cheers,
Greg Merchan
(auspex on GimpNet)