On Jun 12, 2016, at 7:50 AM, Михаил Страшун via dmd-internals <dmd-internals@puremagic.com> wrote:

Proposal
--------

I have described my vision of new process here:
https://github.com/Dicebot/DIPs , check
https://github.com/Dicebot/DIPs/blob/master/README.md for actual
description.


Regarding the “draft” stage, I think “draft” really can just be PR. I think we should not involve a separate system (i.e. D wiki) for this process at all.

If you give permission to others to pull or reject the drafts, it’s likely Walter/Andrei never see frivolous or unworkable PRs. Essentially, we can collectively screen such DIPs to lessen the burden of the DIP manager himself, leaving the task of managing the DIPs past draft.

DIPs aren’t happening 10 a day, like PRs or bug requests, so we can probably find time to review them.

I’d say a DIP draft should not be pulled for at least 1 week (month?) to allow others to provide feedback (overrides by W/A of course are possible).

Note that this will be a huge improvement over the current DIP system where the DIP itself retains prominence in the wiki, but the discussion around it generally happens lost in the forums. Having comments/discussion right in the PR is a huge improvement.

I’ll point out that Apple uses github for swift community-driven language improvements, with pretty good success (not that I agree with all the improvements): https://github.com/apple/swift-evolution .

-Steve