[Kst] Style guide, modifications, and review

[Barth Netterfield]

Hi,
There has been some discussion as to what modifications to other people's 
commits are appropriate, and what aren't.  

** coding style guide violations. **
-We have a coding style guide in devel-docs.  Read it.  Follow it.  If you 
don't like it, convince the list to change it.  But lets stay consistent.

-Do not make changes to the code just for the purpose of fixing someone else's 
style guide modifications, because it breaks cvs annotations, and forces 
re-compiles.  BUT: if you are working on some code anyway, feel free to fix 
things local to what you are doing.  

** review, trivial fixes, optimizations **
-It is appropriate to review other people's commits.  I expect it.  It makes 
for better code.

-If you see a trivial error, or an easy optimization, and you are *sure* you 
are right, feel free to fix it.  If you are not sure, ping the commiter.  

-If someone fixes something you commited, don't be offended!

-If someone pings you, respond!  If you don't in, say 24 hours or so (be 
reasonable...) you are giving implicit approval of what they want to do.

** class structure for new projects **
-If you are making a big change, or adding new features, discuss what you are 
going to do, including new classes and what they do on the list before you 
start.  While a lack of comments may imply implicit approval, it may also 
imply that it just got missed.  All relevant parties really ought to comment!  
If you aren't getting responses, be persistent.  (and don't make people be 
persistent with you).

-While UI considerations come first, Class Cleanliness is also mandatory.

-As much as possible, discuss things on the list.

If you disagree with any of these guidelines, discuss it with me.  I want this 
to work!

cbn