new DIP1: DIP Template

[Daniel Keep]

Jesse Phillips wrote:
> On Sat, 11 Jul 2009 14:22:28 +1000, Daniel Keep wrote:
> 
>> Jesse Phillips wrote:
>>> (stuff)
>> I'm beginning to get the sense that this isn't really appropriate for
>> the Wiki.  Maybe once we've got the design nailed down, we should look
>> at putting them up somewhere where all this organisation can be
>> automated.  I've had some experience with Google App Engine which might
>> work...
> 
> I think the idea is to get the design nailed down and a process for using 
> it. I don't know what the Google App Engine does, but the best example I 
> like was the TIP
> 
> http://www.tcl.tk/cgi-bin/tct/tip
> http://sourceforge.net/projects/tiprender/
> 
> If that was hosted on dsource it probably would be ok. I think the wiki 
> folders kind of give us the automation we need, not very pretty though.

Google App Engine basically lets you write a Python (and soon, Java) web
application that they serve from their servers.  The reason I suggested
it is that it gives you free hosting for smaller projects (and the DIPs
aren't likely to require a huge amount of traffic, CPU time or storage),
we can do whatever server-side processing we want, and it also gives us
authentication stuff.

The thought was to create a DIP app at, say, dip.appspot.com which lists
the DIPs, allows you to search or sort them, sends out email or RSS
updates, and lets people comment on DIPs directly, submit new ones if
they have permission, blah, blah, blah.

(The less altruistic reason is so that I can propose using
reStructuredText for the DIPs :P)

>> Incidentally, what is the process for creating a new DIP?  I think there
>> needs to be at least some level of editorial control, otherwise we'll
>> end up with a million "indexing should start from 1" [1] DIPs.
> 
> I think the idea of a DIP is to get people to create a more formal 
> proposal forcing them to give some extra thought.

The problem is that there's really no way to enforce that.  I tend to
automatically assume any freedom given to people will be abused either
maliciously or due to laziness.

Let's say someone decides that not being able to have templated virtual
methods sucks, and writes a new DIP for it.  Never mind that this is
more or less physically impossible, they could copy+paste the template,
fill it in with the minimal amount of effort, and create a new DIP.

Proposing improvements, even controversial ones, is important.  I just
worry that leaving it completely open-ended will net us something so
clogged with junk submissions that Walter won't bother looking at it.

Here's the section from PEP 1 on how you actually go about creating a
PEP: <http://www.python.org/dev/peps/pep-0001/#pep-work-flow>.
Basically, the editors act as gate keepers to ensure a minimum standard
of effort has been made.