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
