After quite some preliminary discussions and preparations, new D Improvement Proposals handling process is finally happenning. Please read description and explanation here:

https://github.com/dlang/DIPs

## Rationale

There are two main goals for going this way:

1) Ensure communication between language authors and DIP authors, establish better sense of actually contributing as opposed to simply throwing ideas into the black box.

2) Improve overall quality of DIP documents to the point where language authors can reasonably review them without spending too much time on trivialities.

Additional benefit I am hoping for is to have a centralized place to subscribe to learn about all coming major changes coming to language for those who can't keep up with NG regularly.

## Old DIPs

Right now https://github.com/dlang/DIPs repository contains archive folder with already implemented proposals imported from wiki (please tell me if there are any other already implemented DIPs that were not marked as such in wiki).

All authors of existing DIPs who want to keep pursuing the idea will have to re-submit them as a pull requests towards new repo. This is required so that we can filter abandoned proposals and focus on documents that have active authors backing them.

## DIP manager

I will act as a DIP manager for the time being. Please note that role of DIP manager does not imply any decision power regarding DIP approval, it remains an exclusive domain of language authors.

On Saturday, 9 July 2016 at 12:56:48 UTC, Dicebot wrote:
> After quite some preliminary discussions and preparations, new D Improvement Proposals handling process is finally happenning. Please read description and explanation here:
>
> [...]

Sweet! A bit of noise:

https://www.reddit.com/r/programming/comments/4s08h4/the_d_language_has_a_new_dip_d_improvement/
https://news.ycombinator.com/item?id=12061181

On 07/09/2016 09:11 AM, Seb wrote:
> On Saturday, 9 July 2016 at 12:56:48 UTC, Dicebot wrote:
>> After quite some preliminary discussions and preparations, new D
>> Improvement Proposals handling process is finally happenning. Please
>> read description and explanation here:
>>
>> [...]
>
> Sweet! A bit of noise:
>
> https://www.reddit.com/r/programming/comments/4s08h4/the_d_language_has_a_new_dip_d_improvement/
>
> https://news.ycombinator.com/item?id=12061181

Thanks! Don't forget hackerne.ws looks at referrer and automatically bans posts that come from an explicit link (like the one above). What you need to do is post and then let people know what time the post was. Then they can see the post by going to the "new" section and look for posts around that time. -- Andrei

On Saturday, 9 July 2016 at 12:56:48 UTC, Dicebot wrote:
> After quite some preliminary discussions and preparations, new D Improvement Proposals handling process is finally happenning. Please read description and explanation here:
>
> https://github.com/dlang/DIPs
>
> ## Rationale
>
> There are two main goals for going this way:
>
> 1) Ensure communication between language authors and DIP authors, establish better sense of actually contributing as opposed to simply throwing ideas into the black box.
>
> 2) Improve overall quality of DIP documents to the point where language authors can reasonably review them without spending too much time on trivialities.
>
> Additional benefit I am hoping for is to have a centralized place to subscribe to learn about all coming major changes coming to language for those who can't keep up with NG regularly.
>
> ## Old DIPs
>
> Right now https://github.com/dlang/DIPs repository contains archive folder with already implemented proposals imported from wiki (please tell me if there are any other already implemented DIPs that were not marked as such in wiki).
>
> All authors of existing DIPs who want to keep pursuing the idea will have to re-submit them as a pull requests towards new repo. This is required so that we can filter abandoned proposals and focus on documents that have active authors backing them.
>
> ## DIP manager
>
> I will act as a DIP manager for the time being. Please note that role of DIP manager does not imply any decision power regarding DIP approval, it remains an exclusive domain of language authors.

Can the new DIP process be used to evaluate library proposals? That way a high level design could be fleshed out and approved before the contributor goes too far with implementing a design which would be rejected.

On 07/09/2016 09:11 PM, ZombineDev wrote:
> Can the new DIP process be used to evaluate library proposals? That way a high level design could be fleshed out and approved before the contributor goes too far with implementing a design which would be rejected.

It is quite hard. To reasonably evaluate library proposal one has to have at least proof of concept implementation showing intended API. It isn't easy to fit into abstract DIP format.

I can't advise much on this part because I have been trying to stay away from Phobos affairs for a long time and don't know existing status quo about it.

On Saturday, 9 July 2016 at 21:21:54 UTC, Dicebot wrote:
> On 07/09/2016 09:11 PM, ZombineDev wrote:
>> Can the new DIP process be used to evaluate library proposals? That way a high level design could be fleshed out and approved before the contributor goes too far with implementing a design which would be rejected.
>
> It is quite hard. To reasonably evaluate library proposal one has to have at least proof of concept implementation showing intended API. It isn't easy to fit into abstract DIP format.

It depends on the domain and scope of the proposal. See for example the C++17 file system API: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0218r0.html#class-path. I think you'll agree that such a proposal can easily be evaluated solely on its interface, without any need to look at the implementation.

In other domains, such as algorithms, metaprogramming and concurrency / parallelism a proof of concept is much more needed.

I think the main question is: Is this design feasible? If there's any doubt, a proof of concept should be required.

> I can't advise much on this part because I have been trying to stay away from Phobos affairs for a long time and don't know existing status quo about it.

The status quo is that all larger library additions should be approved by Walter or Andrei and new modules should go through the review process http://wiki.dlang.org/Review/Process. What I currently find missing in the review process is a way to get a consensus on the high-level design. If a larger design issue is brought up during the review process it may require a significant rewrite which is a waste of the contributor's time and can be very demotivating.

On Saturday, 9 July 2016 at 12:56:48 UTC, Dicebot wrote:
> After quite some preliminary discussions and preparations, new D Improvement Proposals handling process is finally happenning. Please read description and explanation here:
>
> [...]

On reddit Steve Klabnik from the Rust team mentioned that they are currently trying to refine their RFC process. It could be worthwhile to learn from their experiences:

http://aturon.github.io/blog/2016/07/05/rfc-refinement/
https://github.com/rust-lang/rfcs

I have added new "tips" section to the process readme (https://github.com/dlang/DIPs#advices-for-writing-great-dips) to make potential DIP authors less excited and more prepared to real work awaiting ahead :)