Re: GUP Proposal Organization

[Seth Nickell <snickell stanford edu>]

> 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.

Yes, we do need to fix that.

> 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.

Gadget is a more descriptive term, and avoids the naming confusion, but
I hope we can come up with something even better than this. If you saw
"Gadget" in a menu, would you have any idea what it did? After trying it
maybe, but it would be preferably if people saw the menu item and had a
good guess as to what it did. Of course, gadget is a really cool term
for it ;-)

> The Real Idea
> -------------
<snip>
> 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

sounds good.
 
>   Category: Look & Feel (id prefix = 'LF')
>             Terminology (id prefix = 'TR')
>             Application Organization (id prefix = 'AO')
>             (more categories as needed)

No point in using archane prefixes. They help if our objective is to
sound like a big annoying standardization body, but otherwise they're
just going to get in the way. Lets not weight ourselves down with
unnecessary beuracratic conventions. Category is fine, but just use
"Look & Feel".

>   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...

I don't understand why we need this? We can move to a convention like
this if we find ourselves dying under a giant giant mass of UI
proposals. But I don't think that is going to happen. What might be
advisable is to use Bugzilla and to provide a standard route for
bugzilla UI suggestions to turn into a writeup, which can then be
approved as a proposal. But that all depends on how much involvement we
get.

>   Status: Describes the status of each change proposal.
>           One of {New, In Progress, Approved, Rejected} (etc)

good

>   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 ...

ok

>   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.
<snip>

> 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.

We also need to avoid burdening ourselves unnecessarily though.

cheers,

-Seth