Up-to-date DIPs list

[Seb via Digitalmars-d]

Hey all,

tl;dr: D's DIPs seem not maintained. A couple of ideas are 
proposed to tackle this state.

I really like the List of D Improvement Proposals 
(http://wiki.dlang.org/DIPs), however it seems to me that they 
are lacking a maintainer.
Let me briefly state what I found:

1) Many DIPs have already been implemented and merged or at least 
they are in progress.

http://wiki.dlang.org/DIP22 Private symbol (in)visibility
http://wiki.dlang.org/DIP29 Unique pointers
http://wiki.dlang.org/DIP43 Objective-C (in progress, partially 
merged?)

2) Moreover I found a couple of DIPs that turned out to be 
unfeasible or too much work for the author.

http://wiki.dlang.org/DIP63 Operator overloading for raw templates

3) There are also DIPs that have been superseeded by other:

http://wiki.dlang.org/DIP36 Rvalue References (by #69)

This list is not complete by any means. The general summary is 
that for draft DIPs only the author really knows its current 
status and well most DIPs are drafts...

As I really like those DIPs and it's sad to see them in such a 
careless shape, I have a couple of ideas that might help to avoid 
this in the future:

Idea 1 Have a bit more "formal" DIP protocol
--------------------------------------------

Currently everyone can add his/her new proposal and imho that's 
very nice - however it leads to the problem of stalled DIPs. 
Introducing a "Stalled" state and having an (automated) process 
that looks over it could help too see which DIPs are in work and 
closed (stalled is very similar to closed).

I) Have a maximal draft period of six month
II) After draft there can be four states: "In progress", 
"Rejected",  "Stalled", "Superseded".
III) Define these follow-up states:

Approved = positive approval of the implementation by the 
community and merged into master [end state]
Rejected = negative approval by the community (e.g. major flaws 
or too complicated) [end state]
Stalled = No activity within six months (most likely an end state)
Superseded = Replaced by a newer DIP [end state]

Draft ---> In progress -->  Implemented  --> Approved
   |        ^    |  |            |
   |        |    |  |            |
   |-> Stalled <-|  |            |
   |       |        |            |
   v       v        v            |
(Rejected || Superseded) <------|


Idea 2 Use a version control system (aka git)
---------------------------------------------

Some troubles - like formal review & automated up-to-date status 
- could be easily solved by putting the DIPs into a git 
plain-text "database".


Idea 3 Getting back to the roots: PEPs
--------------------------------------

https://www.python.org/dev/peps/
https://www.python.org/dev/peps/pep-0001/

Their workflow is sophisticated, why not getting inspired again?
Short summary - read PEP #0001 for more details:

I) The PEP champion (a.k.a. Author) should first attempt to 
ascertain whether the idea is PEP-able. Posting to the 
[newsgroup/mailing list]
II) Idea proposal -- submitted to --> PEP editors (which have the 
right to reject PEP proposals if they appear too unfocused or too 
broad)
III) PEP editors -- assign --> a number to PEP
IV) Draft PEP may be discussed further
V) Once a PEP is completed a PEP, the author may request a review 
for style and consistency from the PEP editors. However, the 
content and final acceptance of the PEP must be requested of the 
BDFL [Benevolent Dictator For Life, Guido van Rossum], usually 
via an email. PEPs are reviewed by the BDFL and his chosen 
consultants, who may accept or reject a PEP or send it back to 
the author(s) for revision. For a PEP to be accepted it must meet 
certain minimum criteria:
  - It must be a clear and complete description of the proposed 
enhancement.
  - The enhancement must represent a net improvement.
  - The proposed implementation, if applicable, must be solid and 
must not complicate the interpreter unduly.
VI) When a PEP is Accepted, Rejected or Withdrawn, the PEP should 
be updated accordingly.

-----------------------------

Those are just some ideas I wanted to send out to you - feel free 
to combine, destroy, cherry-pick them or to add your own ideas ;-)

Cheers,

Seb