I'd like to spend an hour or so cleaning up the enhancements page if
this (I guess it is not a necessity, but if it should be done anyway
then this is a good time). If I get thumbs up for the following I'll get
at it.
I propose the following scheme:
Number each document with a CEP number. Numbering scheme:
CEP1xx: "Frontend". User experience CEPs and meta-CEPs; high-level goals
that drive development process ("better C++ support", "better numpy
support") as well as build system, command-line interface, usage as
library etc.
CEP2xx: Better support for compiling non-extended Python code
CEP3xx: New features for the Cython language that doesn't overlap with
Python (templates, code in pxd files)
CEP4xx: Optimizations -- things that doesn't change the Cython language
but which changes C output. For instance for-in => for-from transform.
CEP9xx: Cython implementation things (transformation pipelines,
development of new parser, etc.)
The important thing isn't that we cover every case now, but that
documents that's numbered now doesn't have to be renumbered.
Each document has the following fields (guidelines only):
- CEP status: Anyone can submit a CEP with status to "Idea" (working on
it) or "Proposed" (believe it is ready for getting accepted), project
administrators can set status to "Accepted"
- Implementation status: "None", "Prototyped", "Patch ready", "Committed
in #...." etc.
Author field is not necesarry (one can check wiki info), however if
under development the developer "owning" the implementation initiative
for it should be noted. Also the CEPs that goes into a GSoC application
should note that in a Comment field.
In the wiki:
- Pages keep their current URL, but the CEP number is noted on the
enhancements page and in the title
- The enhancements page has a link to a description of this system, then
CEPs by overall category. However the CEPs are NOT necesarrily sorted,
as one might want to create subgroups of CEPs
- A brainstorming section at the end of enhancements contains stuff that
is on their way to become a CEP but is not specific enough (however the
bar shouldn't be too high if it is evident that the idea is an isolated
concept that doesn't need to be broken up, such as "better local
variable handling")
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
