Bits for GNUstep policy

[Stefan Urbanek]

Hi,

Because GNUstep has no policy, here are two suggestions:

1. Discuss features before commit

Each new feature or removal of a feature should be discussed. Focus should be 
on:
- real need for new feature or existing feature
- alternative ways
- whether it helps us to acomplish GNUstep goal or not
- ...

There is the 'Support Request' page at savannah that should be used for that:
https://savannah.gnu.org/support/?func=addsupport&group=gnustep

On the savannah, there will be saved record with quite nice searching facility. 
Like for bugs there is bug-gnsutep, this shold be discussed on gnustep-dev 
mailing list.

2. Functional specifications

Larger projects for GNUstep should have a well discussed functional 
specification. This has several advantages:
- overall view of the functionalities features
- immediate documentation (including user docs)
- record for future developers

Place for specifications shold be GNUstep Wiki.

Both things have one important point: they are recorded and publically 
available. And because it is explicitly written and not only in current GNUstep 
development people minds, it can be shared with others. Therefore it is 
available for new GNUstep developers, that will come. Take an example: someone 
will find GNUstep, will want to learn of it a bit so he will want to write 
something. What? 
Yet-another-something-that-already-exists-in-fifty-seven-clones-app? No! Write 
part of a GNUstep! There is already written specification, and new developers 
can also learn from that.

Side effect is, as I have mentioned, preserving all GNUstep ideas before 
current GNUstep developers leave.

What do you think?

Stefan Urbanek
--
First they ignore you, then they laugh at you, then they fight you, then you 
win.
- Mahatma Gandhi