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
