new DIP1: DIP Template

[Paul D. Anderson]

Leandro Lucarella Wrote:

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

<snip/>

I hope we can avoid format wars -- surely we're flexible enough to evaluate DIPs without insisting on a particular order of presentation. Different proposals may benefit from different presentations. The template is a great starting point.

(I know the posters in this thread aren't insisting on a particular order, just tossing out ideas.)

I think one of the strengths of creating DIPs is to keep track of proposals -- both to keep us from re-inventing the wheel and to keep good ideas from getting lost in the NG. Some ideas that seem trivial generate a lot of posts and occasionally descend into flame wars, while other, meatier proposals languish just because no one responds.

I would suggest that the proposer also include, if applicable, which language version (or which component or library, etc.) their proposal would affect, and whether it is a breaking change.

The Java Community Process (which is very formal and glacially slow) uses a question based format that may be helpful here too. (I mean the list of questions -- not that we should use questions.)  One of their questions is "Why isn't this need met by existing specifications?". Proposers might consider this -- it could separate the bicycle shed ideas from more fundamental ones.

Paul