digitalmars.D - Up-to-date DIPs list
- Seb (87/87) Mar 12 2016 Hey all,
- ZombineDev (13/17) Mar 16 2016 +1
- Martin Tschierschke (17/29) Mar 16 2016 +1
- Mike Parker (7/16) Mar 16 2016 This is not an independent forum. It's a web interface to a
- Martin Tschierschke (16/34) Mar 17 2016 The forum is sorted by time, latest first.
- Mike Parker (7/15) Mar 17 2016 There's a search box at the top of the page.
- Seb (6/9) Mar 17 2016 Don't be offended, but I think we are a bit off-topic here - my
- Martin Tschierschke (7/17) Mar 21 2016 You are right, its getting off-topic, ;-)
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: 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? 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
Mar 12 2016
On Saturday, 12 March 2016 at 12:49:42 UTC, Seb wrote:Hey all, tl;dr: D's DIPs seem not maintained. A couple of ideas are proposed to tackle this state. [...]+1 The formal process required for library additions to std.experimental was a step in the right direction, IMO. Rust also has well written document on this topic: https://github.com/rust-lang/rfcs/blob/master/README.md I think you should structure your proposal as a DIP. For example: http://wiki.dlang.org/DIP75 http://wiki.dlang.org/Review/Process You also probably link it from the overview page (http://wiki.dlang.org/DIPs). BTW all documents describing formal processes (review, release), design rational, etc. should be better organized.
Mar 16 2016
On Wednesday, 16 March 2016 at 14:28:10 UTC, ZombineDev wrote:On Saturday, 12 March 2016 at 12:49:42 UTC, Seb wrote:[...]Hey all, tl;dr: D's DIPs seem not maintained. A couple of ideas are proposed to tackle this state. [...]+1You also probably link it from the overview page (http://wiki.dlang.org/DIPs). BTW all documents describing formal processes (review, release), design rational, etc. should be better organized.+1 I think there should be the possibility to up-vote a post in the forum, so that it gets more clear what topics are of high interest and which not. Even if no additional comment is made. So very useful threads can be found and used as information starting point even if they get out of focus by time. Posts with high ranking, can be detected and used to optimize the general language documentation. And DIP discussions. Same for DUB packages, my suggestion was to show the GitHub Stars and the number of watchers and or number of downloads, Sönke said he will look at it, if he finds the time... Just my 2 cent. mt.
Mar 16 2016
On Wednesday, 16 March 2016 at 16:26:02 UTC, Martin Tschierschke wrote:I think there should be the possibility to up-vote a post in the forum, so that it gets more clear what topics are of high interest and which not. Even if no additional comment is made. So very useful threads can be found and used as information starting point even if they get out of focus by time. Posts with high ranking, can be detected and used to optimize the general language documentation. And DIP discussions.This is not an independent forum. It's a web interface to a newsgroup server, which also has a mailing list interface that many people use. Yes, it would be possible to implement something like that for the web interface alone, but I don't see how that would add any value.
Mar 16 2016
On Thursday, 17 March 2016 at 03:58:49 UTC, Mike Parker wrote:On Wednesday, 16 March 2016 at 16:26:02 UTC, Martin Tschierschke wrote:The forum is sorted by time, latest first. But what if you are new to the language? Like me. Which threads are worth reading even if they are older? Or if a discussion is going on since many month/years do I have to read all? What are the best arguments? Isn't the forum full of hints and best practice tips which should be available easier? Keeping it in the way it is in the moment, makes it difficult to find the treasures inside. But you need both, the possibility to vote and an overview of threads and post with highest votes. Best regards mt.I think there should be the possibility to up-vote a post in the forum, so that it gets more clear what topics are of high interest and which not. Even if no additional comment is made. So very useful threads can be found and used as information starting point even if they get out of focus by time. Posts with high ranking, can be detected and used to optimize the general language documentation. And DIP discussions.This is not an independent forum. It's a web interface to a newsgroup server, which also has a mailing list interface that many people use. Yes, it would be possible to implement something like that for the web interface alone, but I don't see how that would add any value.
Mar 17 2016
Mike Parker <aldacron gmail.com> On Thursday, 17 March 2016 at 10:11:14 UTC, Martin Tschierschke wrote:Isn't the forum full of hints and best practice tips which should be available easier? Keeping it in the way it is in the moment, makes it difficult to find the treasures inside.There's a search box at the top of the page.But you need both, the possibility to vote and an overview of threads and post with highest votes.I understand your reasoning, I'm just of the opinion that if it can't be implemented across all of the interfaces (and it really can't), then it doesn't make sense to do it. If we had a wholly contained forum, it would be a different story.
Mar 17 2016
On Thursday, 17 March 2016 at 10:11:14 UTC, Martin Tschierschke wrote:But you need both, the possibility to vote and an overview of threads and post with highest votes.Don't be offended, but I think we are a bit off-topic here - my suggestions were about better ways to manage DIPs. What do you think about putting them into a Github repo for a first start so that potential tooling or standardization gets a lot easier?
Mar 17 2016
On Thursday, 17 March 2016 at 19:03:31 UTC, Seb wrote:On Thursday, 17 March 2016 at 10:11:14 UTC, Martin Tschierschke wrote:You are right, its getting off-topic, ;-) unfortunately I am not very familiar with all Git tooling, but I appreciate the idea that better tooling is needed and so Git should be a good solution, because it is used anyway by the "D-crowd". Regards mt.But you need both, the possibility to vote and an overview of threads and post with highest votes.Don't be offended, but I think we are a bit off-topic here - my suggestions were about better ways to manage DIPs. What do you think about putting them into a Github repo for a first start so that potential tooling or standardization gets a lot easier?
Mar 21 2016