Jump to page: 1 28  
Page
Thread overview
Preparing for the New DIP Process
Jan 18
zjh
Jan 21
zjh
Jan 21
zjh
Jan 21
zjh
Jan 21
zjh
Jan 21
Dom DiSc
Jan 21
zjh
Jan 21
Dom DiSc
Jan 21
zjh
Jan 21
zjh
Jan 23
Danilo
Jan 23
Dom DiSc
Jan 25
Ogi
Jan 25
Danilo
Jan 26
Ogi
Jan 27
Sergey
Jan 25
zjh
Jan 25
Sergey
Jan 25
zjh
Jan 25
zjh
Jan 25
jmh530
Jan 26
Meta
Jan 21
Dom DiSc
Jan 27
zjh
Jan 27
zjh
Jan 21
claptrap
Jan 30
mate
January 18

A few months back when I announced in one of our planning updates that we were freezing the DIP queue to focus on stabilization, I noted that the DIP process was going to get an overhaul. I've since learned that this message didn't stick, so I'll paste here what I said then.


The DIP process is getting a long-needed overhaul. Over time, I've had feedback from people who have authored DIPs and those who decided not to. There are a number of different opinions about how things can change, but there are some common themes among them.

I'll write in more detail about this later, but there are a few major goals I have with the overhaul:

  • reduce the burden on the author
  • reduce the amount of time a submitted DIP is in review
  • establish support for fleshing out ideas before a DIP is even written
  • establish support for developing initial DIP drafts before they are submitted

Previously, I'd always considered development of the DIP separate from the DIP "process", which I saw as beginning with the submission of a pull request. In reality, the process begins even before an author opens an editor to start typing. I hope that by recognizing that, and by providing support for discussing ideas and writing the DIP, we'll foster an environment that still maintains a relatively high bar for DIPs that get submitted, but also creates a filter such that potential DIP authors can be more confident that they aren't wasting their time once they get to the development stage. By the time they get there, they'll have no doubt if it's an idea worth pursuing.


I'm getting ready to open things up again. The new process is going to be much, much looser than before. I'll have all the details in the announcement when we reopen, and I should be able to give you a general timeframe after our planning session tomorrow.

I'm making this pre-announcement announcement now so that any authors with a DIP frozen in the PR queue can have a heads up. We'll need to treat these somewhat differently than new DIPs, but we'll be ready to get moving on them when the author is. It's entirely on the author's schedule, not ours.

And if any of you are thinking about submitting a new DIP, I ask you to start thinking about the details, but don't start writing it just yet. Once the new process is open, you won't have to sit and write it in isolation with no feedback from Walter or Atila. You'll be able to get feedback early from both them and the community, so you can know very early on if it's something you're willing to pursue, and you'll hopefully have a good bit of help to get it developed.

The process as it existed had a high bar with the intention of encouraging the production of quality DIPs and discouraging frivolous proposals. In practice, that high bar was a high barrier to entry and ended up discouraging even good proposals. I'm optimistic that the new process will lower the barrier to entry and still encourage quality proposals.

And by "quality" I'm not referring to the quality of the DIP's language. In the new process, the focus will be entirely on the details of the proposal and not on the language in which they're presented. I'm happy to clean that up myself once a proposal is accepted.

Just wanted to put out a heads up. More to come!

January 18

On Thursday, 18 January 2024 at 07:19:19 UTC, Mike Parker wrote:

>

Just wanted to put out a heads up. More to come!

I hope the new 'dip' process is as simple as writing plugins.

January 18

On Thursday, 18 January 2024 at 07:19:19 UTC, Mike Parker wrote:

>

And by "quality" I'm not referring to the quality of the DIP's language. In the new process, the focus will be entirely on the details of the proposal and not on the language in which they're presented. I'm happy to clean that up myself once a proposal is accepted.

Very cool development!

January 18
This is going to be a great initiative. Thanks, Mike!
January 20
On Thursday, 18 January 2024 at 07:19:19 UTC, Mike Parker wrote:
>
> * establish support for fleshing out ideas before a DIP is even written
>

It's 2024. That should have been the principle a decade ago

Remember how the so called 'discussions' about the 'privateThis' concept always got heaped on. People just wanted to shut it down rather that discuss it. 'Go write a DIP' was the response...remember.

> ...
> Previously, I'd always considered development of the DIP separate from the DIP "process", which I saw as beginning with the submission of a pull request. In reality, the process begins even before an author opens an editor to start typing. I hope that by recognizing that, and by providing support for discussing ideas and writing the DIP, we'll foster an environment that still maintains a relatively high bar for DIPs that get submitted, but also creates a filter such that potential DIP authors can be more confident that they aren't wasting their time once they get to the development stage. By the time they get there, they'll have no doubt if it's an idea worth pursuing.
>

Bring back the privateThis discussion, so we can put your newly discovered revelations to the test.

Maybe the folks over at openD can try discussing it too, and see what happens there ;-)

January 20
On Saturday, 20 January 2024 at 22:53:15 UTC, privateWHAT wrote:
>..

For those newcomers who don't know what that was all about..

https://github.com/dlang/dmd/compare/master...dkorpel:dmd:private-this#diff-8da4a723a20020bf5d1edf1a9f1344eb776c73a0ae35ccee95d3bc24cb0600a7R242

January 21
On Saturday, 20 January 2024 at 22:53:15 UTC, privateWHAT wrote:
> On Thursday, 18 January 2024 at 07:19:19 UTC, Mike Parker wrote:
>>
>> * establish support for fleshing out ideas before a DIP is even written
>>
>
> It's 2024. That should have been the principle a decade ago
>
> Remember how the so called 'discussions' about the 'privateThis' concept always got heaped on. People just wanted to shut it down rather that discuss it. 'Go write a DIP' was the response...remember.

The class vs module level of encapsulation was fleshed out a lot in the forums awhile back. I think it's fair to say most people where happy (or neutral) with the status quo, and were not convinced by the pro-class-level arguments.

I also suspect those that did prefer class level private (I believe this is what Atila prefers), it's not high on their list of priorities.

Jordan
January 21

On Sunday, 21 January 2024 at 07:11:50 UTC, Jordan Wilson wrote:
I think it's fair to say most

>

people where happy (or neutral) with the status quo, and were not convinced by the pro-class-level arguments.

So there are very few people in the D community. If you don't care about others, they don't care about you.

January 21

On Sunday, 21 January 2024 at 07:36:31 UTC, zjh wrote:

>

So there are very few people in the D community. If you don't care about others, they don't care about you.

here

A small feature that has no side effects at all.
They are just not merging it.

January 21

On Sunday, 21 January 2024 at 07:36:31 UTC, zjh wrote:

>

On Sunday, 21 January 2024 at 07:11:50 UTC, Jordan Wilson wrote:
I think it's fair to say most

>

people where happy (or neutral) with the status quo, and were not convinced by the pro-class-level arguments.

So there are very few people in the D community. If you don't care about others, they don't care about you.

What? I'm sorry, but being happy with module level != not caring about others.

Jordan

« First   ‹ Prev
1 2 3 4 5 6 7 8