Re: GNOME Style Guide, was: Re: Uniformity?




> Hello,

Aloo!:)


> Actually, I think another way to try and make something useful happen  
> without (possibly) devolving into another flame war is to kind of establish  
> some ground rules.  If the people involved didn't follow the ground rules, I  
> don't know what recourse there would be, but at least maybe something like:
> 
> 	* if you flame someone for expressing an opinion, you will be
> 	  filtered
> 	* realize that everyone has a right to their opinion and you can
> 	  either agree, disagree or ignore it, but we ARE trying to do
> 	  something more constructive than host a flame war.

This is what we were trying to do, originally..until Vogt and a few others
decided they were going to de-rail the creative process by forking the
development effort off into a poorly chosen and ultimately unnecessary
direction. This blew the focus off the real development effort to a point
where the feedback we were getting was so distorted and confused that
nothing of substance could get done. What began as an efficient process
got muddled down by a pack of people who insisted they knew better,
despite the fact that had zero experience, and zero clue.

To make matters worse, no one from GNOME stepped in to prevent it early
on, despite repeated attempts to notify them of the problem at hand.
Perhaps they'll be a little more attentive next time around the barn. :)
The sad thing is, the people who were actually part of the effort knew
full well ahead of time that the entire effort was going to collapse if
Vogt and the others were to continue defocusing the development effort..
Even more sad, looking back, I dont think anyone within the core of GNOME
was even >paying attention< to the mailing list, until it was already too
late.

If youre going to work on such a project, let the above serve as an
example to learn from. If no one with real authority is going to put their
foot down until things have degenerated so much they have nothing to put
their foot down *ON* , its time to find someone else to work for. ;)

> Also, in order to get something resolved, instead of trying to tackle the  
> whole problem of the style guide at once, break it down into more manageable  
> chunks and associate a "target date of completion" to them.  Now, I realize  
> that we're talking about a vast variety of different schedules to coordinate,  
> but if things are split up into smaller pieces, maybe something useful will  
> be done in a more timely fashion.

This is also what we were trying to do. A good start.

> 
> I think that the existing style guide is a good start, but I think that we  
> may want to add some additional information for background which does more to  
> describe the concepts and ideas we want to see GNOME and GNOME applications  
> exhibit and then talk about the actual "nuts and bolts" implementation  
> details of each interface component.  After that, maybe the special features  
> that will define GNOME like the integrated CORBA and the Baboon architecture  
> should be discussed.  Among these could also be information about the  
> different application styles (SDI/MDI/Dialog) and how each one should be  
> implemented or at least behave.  How the integration with the help system  
> should be accomplished, and a discussion on how the user applications and  
> settings for both the system and the user environment are stored, organized  
> and modified.
> 

The existing style guide needs to be overhauled, not just fleshed out, as
you suggest. A good start.

> These are just opinions about some other things which I haven't seen in the  
> style guide as yet.  I think the most important ones to define first are the  
> overriding GNOME-isms which will define the environment.  I know that this  
> information is spread around all over the place and the FAQ does a pretty  
> good job of touching on it, but I think that a high-level discussion about  
> what is GNOME, how is it different from other environments and what can a  
> user expect from GNOME and GNOME-compliant applications independent of things  
> like layout and text capitalization would have a good home in the style  
> guide.  Also, this guide should be heavily illustrated, as much as possible,  
> to allow someone to get the "feel" of GNOME without necessarily  
> building/compiling/installing the environment.

Agreed.

> 
> This turned out to be a bit longer than I had intended, but I am interested  
> in helping out as well.  I'm also open to suggestions as to how to break  
> things down into smaller, more easily-attainable chunks.  I'm also  
> cross-sending this to the gnome-gui list (so my apologies for anyone who gets  
> it twice) because I agree with Nils that it kinda belongs there as well.

Having parallelized, open development of a style guide (as nice and as
equitable as it sounds) will result in an inconsistant document which
lacks a proper undergirding. Sure, you could do it this way, but, you
should then also be prepared to do huge revisions to it a few years down
the road, once those inconsistancies come to the surface.

I dont work that way. If i'm going to build a tank, its going to be made
from steel, not cardboard. What Nils suggests is a good start. Such things
cannot be decided by a comittee of thousands, but rather by a small
control group which takes its milk and honey from the consensus, and does
what it needs to do, to make a coherent, consistent document.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]