GUP Proposal Organization

["Paul Joseph Thompson" <captbunzo squirrelmail org>]

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.

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.

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.

  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.

  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.

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.

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.

Thank you for your time...

--

            Paul Joseph Thompson
            captbunzo squirrelmail org