> On Jun 12, 2016, at 7:50 AM, Михаил Страшун via dmd-internals
> <[email protected]> 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
<https://github.com/apple/swift-evolution> .
-Steve
_______________________________________________
dmd-internals mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/dmd-internals
