new DIP1: DIP Template

[Leandro Lucarella]

Jason House, el  8 de julio a las 08:50 me escribiste:
> Lars T. Kyllingstad Wrote:
> 
> > Leandro Lucarella wrote:
> > > 
> > > [1] http://www.prowiki.org/wiki4d/wiki.cgi?DiPs
> > > [2] http://www.prowiki.org/wiki4d/wiki.cgi?DiP1
> > > 
> > 
> > 
> > I think this is a good idea. :) Regarding the template, I think there 
> > should be one more section, called "Description". Then each DIP would be 
> > organised as follows:
> > 
> > Abstract:
> >      Short summary of description, rationale and usage.
> > Description:
> >      Detailed description of proposal.
> > Rationale:
> >      Explanation of why proposal has been made, why the new feature
> >      should be included.
> > Usage:
> >      Examples, etc.
> 
> I agree, but think the description section should come after usage. That
> should be a more natural reading order...

About the order, I prefer the description first but I can live with the
usage first. But I think the rationale should be just after the abstract.
I think the order should be:

Abstract:
     Short summary of description, rationale and usage.
Rationale:
     Explanation of why proposal has been made, why the new feature
     should be included.
Description:
     Detailed description of proposal.
Usage:
     Examples, etc.
Other:
     Other sections as needed.

I don't even think the Usage will always be there (there could be DIPs for
removing a feature for example).

> Also, I think we should list the available values for status, and
> possibly add sections to the DIP as it gets more mature. Off the top of
> my head:
> 
> Draft
> ? Description section optional
> 
> Stable Design
> ? Detailed description required. Major design changes should become a new draft DIP.
> ? Reaction from Walter & Co. optional
> 
> Rejected
> ? Reaction from Walter & Co. required. Shouldlist specific faults
> 
> Soliciting Patches
> ? Implementation thought
> ? Submitted patches (with quality remarks about each patch)
> 
> Accepted
> ? Links - changeset, final docs on digitalmars.com, etc...  

I was thinking about the PEP statuses (to be honest I was inspired by PEPs
when doing this, I hope this doesn't make Python haters resistant to the
proposal now ;). But being a different language there could be different
needs so we can pick a new set of statuses of our own. I didn't wanted to
specify all these details for now to avoid bloat.

I think we should start with easy to write, not *too* formal proposals,
and increment the level of detail in the future, as the need comes more
evident, so we don't get too bureaucratic without reason.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
La máquina de la moneda, mirá como te queda!
	-- Sidharta Kiwi