Jump to page: 1 2 3
Thread overview
June 12
As I have briefly mentioned in the NG before, I'd like to take over DIP management and turn it into something more transparent and powerful compared to what we have now.

Rationale
---------

There are two major goals that motivate me here:

1) Lack of reliable communication mechanism with language authors.

Existing DIP list is simply a collection of ideas that may or may not be looked at - not as easily lost as NG topic but not much different in all other regards.

But of course it is impossible for Andrei and Walter to put enough attentions in all proposal to guaranteed response and decision for each of them - it takes too much time to dive into the context to only discover that specific DIP lacks some crucial bit of information.

2) Necessity to have a centralized place to track major language/process changes.

One of greatest issues of using D at work for me is a constant fear that upstream will make a major language change that harms our projects without noticing it timely. It is not reasonable to expect for all commercial D users to regularly read through NG and Github issues to provide feedback on matters important for them.

DIP system can be a great way to fix it. If all major changes are required to undergo DIP approval process, it becomes possible to simply subscribe to the feed of approved DIPs to figure out what is coming upstream.

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.

Essentially it tries to address transparency issue by minimizing routine information digging effort on Andrei and Walter side and make the process more stable by introducing regular short meetings and/or mail discussions for DIP review.

If new process is to be approved, this repo is to be moved to dlang organization and becomes the main place for DIP management.

@Andrei / @Walter
-----------------

Crucial point of new proposed system is your commitment to schedule regular time for DIP review. It is not that important how rare such review happen and what exact format (mail thread or skype call or whatever) it takes - the goal is to do it in a way most convenient to you. However it does needs to be regular and reliable which makes this proposed system only feasible if you can agree to such commitment.

@all
----

Please express your concerns ;)



June 12
I worry about a process that requires regular time commitments from Andrei and myself. We always start out with good intentions, but eventually reality sets in. I don't have a good answer.


_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals
June 12
On 06/12/2016 10:57 PM, Walter Bright wrote:
> I worry about a process that requires regular time commitments from Andrei and myself. We always start out with good intentions, but eventually reality sets in. I don't have a good answer.

It is important though, otherwise it will only differ from existing system in fancy decorations. Note that "regular" doesn't mean "often" - we can schedule it even once a year if needed. It just needs to have some reliable rarity margin to ensure some slow consistent progress.

As it was already mentioned before, DIP process is special in a sense that no matter how much routine volunteer can take care of, in the end it is still you and Andrei who need to make the decision and that part simply can't be delegated - we can only try removing the burden of getting to that point (which is exactly what I am trying to do here).

I all open for any tweaks that make the process more convenient to you but I am afraid at least some commitment is unavoidable.



June 13

> 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 <https://github.com/apple/swift-evolution> .

-Steve

June 13
I agree. Probably a skype call now and then will do it.


On 6/12/2016 1:15 PM, Михаил Страшун wrote:
> On 06/12/2016 10:57 PM, Walter Bright wrote:
>> I worry about a process that requires regular time commitments from
>> Andrei and myself. We always start out with good intentions, but
>> eventually reality sets in. I don't have a good answer.
> It is important though, otherwise it will only differ from existing
> system in fancy decorations. Note that "regular" doesn't mean "often" -
> we can schedule it even once a year if needed. It just needs to have
> some reliable rarity margin to ensure some slow consistent progress.
>
> As it was already mentioned before, DIP process is special in a sense
> that no matter how much routine volunteer can take care of, in the end
> it is still you and Andrei who need to make the decision and that part
> simply can't be delegated - we can only try removing the burden of
> getting to that point (which is exactly what I am trying to do here).
>
> I all open for any tweaks that make the process more convenient to you
> but I am afraid at least some commitment is unavoidable.
>

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals
June 14
My opinion in the matter is: there must be some protocol that guarantees consideration by the leadership. Can it be abused? Yes, just like standardization processes can and are, just how legal systems are, etc. But by and large they are a good thing, and we need to have one. For my part I'd be hypocritical if I can afford time to participate in the meandering chatter on the forums, yet refuse to devise a way for the appropriately determined to get my attention.

Of course there needs to be appropriate filtering, otherwise anyone can put obfuscated or just poor content into standard DIP format and transform DIP reviewing into an inefficient full-time job. This is what seems to be missing from the current proposal. I think a DIP should reach some form of consensus in the community discussion before it being eligible for formal review.

Another thing we should add is a structured form of interaction. Say there's a DIP there and the core team has a number of proposed changes and also a number of questions. The changes seem to be a good fit for pull requests against the DIP. How about the questions? What is a good mechanism for asking and addressing them? From what I see in the proposal the DIP manager is the middleman in that, presumably using email for communication. (Things should be clearly formalized even if that's the basic structure.)

DIPs should be more structured themselves. To the extent we preserve structure from the wiki DIPs that should be clearly stated and templated. Probably we need more than that, seeing as plenty of poor DIPs do follow the required structure. I'm thinking at least a PR against the language/library specification showing what changes to those would be needed in order to describe the proposed feature.

Generally, let's get this done. Thanks Dicebot for the initiative.


Thanks,

Andrei

On 6/12/16 4:15 PM, Михаил Страшун via dmd-internals wrote:
> On 06/12/2016 10:57 PM, Walter Bright wrote:
>> I worry about a process that requires regular time commitments from
>> Andrei and myself. We always start out with good intentions, but
>> eventually reality sets in. I don't have a good answer.
>
> It is important though, otherwise it will only differ from existing
> system in fancy decorations. Note that "regular" doesn't mean "often" -
> we can schedule it even once a year if needed. It just needs to have
> some reliable rarity margin to ensure some slow consistent progress.
>
> As it was already mentioned before, DIP process is special in a sense
> that no matter how much routine volunteer can take care of, in the end
> it is still you and Andrei who need to make the decision and that part
> simply can't be delegated - we can only try removing the burden of
> getting to that point (which is exactly what I am trying to do here).
>
> I all open for any tweaks that make the process more convenient to you
> but I am afraid at least some commitment is unavoidable.
>
>
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals
June 15
On 06/15/2016 01:04 AM, Andrei Alexandrescu wrote:
> My opinion in the matter is: there must be some protocol that guarantees consideration by the leadership. Can it be abused? Yes, just like standardization processes can and are, just how legal systems are, etc. But by and large they are a good thing, and we need to have one. For my part I'd be hypocritical if I can afford time to participate in the meandering chatter on the forums, yet refuse to devise a way for the appropriately determined to get my attention.
> 
> <snip>
>
> DIPs should be more structured themselves. To the extent we preserve structure from the wiki DIPs that should be clearly stated and templated. Probably we need more than that, seeing as plenty of poor DIPs do follow the required structure. I'm thinking at least a PR against the language/library specification showing what changes to those would be needed in order to describe the proposed feature.
> 
> Generally, let's get this done. Thanks Dicebot for the initiative.

Thank you very much for commitment. I got some valuable feedback, need to think about it and incroporate into another iteration of proposed process this weekend (sadly, as I have mentioned before, I can only afford large time commitment one day a week).

I will take this and earlier Walter reply as preliminary conceptual agreement - let's get to more technical details in that case!



June 17
On 06/12/16 13:50, Михаил Страшун via dmd-internals 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.
> 
> Essentially it tries to address transparency issue by minimizing routine information digging effort on Andrei and Walter side and make the process more stable by introducing regular short meetings and/or mail discussions for DIP review.
> 
> If new process is to be approved, this repo is to be moved to dlang organization and becomes the main place for DIP management.

Thanks, this really looks like it can revive DIPs.
Also PRs seem very appropriate as the review stage can raise the quality
of proposal and ask people to collaborate instead of adding lots of
competing DIPs.
And since PRs are open to public comments, people can already
participate in the draft reviews, great.

-Martin




June 27
I have updated https://github.com/Dicebot/DIPs readme with process tweaks based on the feedback and added new tool to generate sorted overview table for all DIPs automatically.

Main changes:

- Now all markdown documents are stored in single folder (to ensure
persistent URL) and for convienient navigation sorted table is generated
instead
- PR itself has become an initial draft/review stage, wiki suggestions
has been removed
- More emphasis on collaboration / community interaction

I also wanted to import all implemented DIPs from wiki but have some doubts about how better to proceed with it. Problem is that old DIPs are really of terrible quality by the standards we want to set up for new submissions - importing them as they are would give a very bad example to follow.

Would anyone mind if those are rewrited the retrospectively to contain more information about state of art?



June 27
> On Jun 27, 2016, at 5:00 AM, Михаил Страшун via dmd-internals <dmd-internals@puremagic.com> wrote:
> 
> 
> I also wanted to import all implemented DIPs from wiki but have some doubts about how better to proceed with it. Problem is that old DIPs are really of terrible quality by the standards we want to set up for new submissions - importing them as they are would give a very bad example to follow.
> 
> Would anyone mind if those are rewrited the retrospectively to contain more information about state of art?

I would say any DIPs that are already approved or implemented should be copied for historical reasons. Any other ones should be left alone, and if the author still wishes to pursue, they should open a new DIP using the new process.

-Steve
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals
« First   ‹ Prev
1 2 3