This Week in D

DIP DIP

Blog
Posted 2022-06-20

I wrote up the key ideas behind my proposal to improve the D Improvement Proposal structure.

Core D Development Statistics

In the community

Community announcements

See more at the announce forum.

What Adam is working on

I still have a lot of day job work to do, so don't expect me to write too much in the coming weeks again. But in the last couple weeks, I did a few small things:

  • dpldocs.info now only generates docs in a POST request, instead of doing it on any GET with a cold cache. This is meant to try to make the server only cache things people actually need instead of search engine bots populating everything, to keep me from running out of disk space again.
  • I am considering adding user comments to dpldocs pages, similar to php, after I get caught up on work. I'll decide later but there's been a few people asking and it is not to hard to do.
  • My video stream layout site got expanded for an event last weekend and it all went well. Did hit an unnecessary arbitrary limitation in cgi.d's event server, but was able to expand it in a few minutes and the code performed very well. I still want to write more details about this system when I have more time, but no promises as to when.

DIP DIP

I'm extremely critical of the dip process and want to see it overhauled. First, let's consider the goals of a DIP process:

  • Provide a path to get changes IN to the language
  • Provide a path to keep changes OUT of the language
  • Encourage better design work
  • Motivate and guide contributors
  • Keep most people with rejected ideas feeling they have been treated fairly

Achieving these goals means the DIP council needs to be in charge of language steering in general; DIPs shouldn't just focus on esoteric, individual proposals, but also providing a vision for D as a whole. Possible future DIPs might include, and not be limited to, examples such as:

  • Add/remove feature X to the language
  • Design goals for a new Phobos module
  • Moderation policy for the forum
  • Elevating priority of specific bugzilla issues

The idea is you'd want to make proposals to improve D as a whole in a variety of ways. Ideally, all work would be guided by an accepted DIP, and things not accepted would be blocked. As a practical matter, PR managers might need more autonomy in interpreting some guidelines, but the steering council could overrule them if necessary; any PR merged that is not in line with the language's intended direction can be reverted.

So, what is this steering council? It is simply a small group of respected D leaders who have final say on the direction of the language. Since it is important to have diversity of experience on the council, so they can intelligently critique proposals over the broad array of fields D can excel in, the council can't be too small. At the same time, it also can't be too big or it won't work too effectively. I think seven would be ideal, but five might be enough too.

Any DIP with at least two members of the council tentatively in favor will be considered. This gives would-be DIP authors some assurance of fair consideration, giving them a reason to sink the time into flushing out a proposal, and also serves as the first filter to reject ideas that have no hope of acceptance. The steering council can refuse to entertain a whole category of proposals and kill discussion of them.

Anybody is free to author a DIP, including the DIP manager, steering councillors, and random people on the forum. They just need to get another leader on board to get consideration. This maintains quality control against any overly enthusiastic individual while simultaneously not unnecessarily blocking any talented individual from making proposals.

Once something is considered, the goal is to ensure we have a document that is:

  1. Actionable
  2. Understandable
  3. Well-designed
  4. Consistent with itself and the language's goals

This is important: a DIP document is meant for contributors, not the steering council. Let me say that again: the primary goal of a DIP document is for contributors to know what to do. It is important for the steering council to understand the document too - the proponents will need to convince at least a majority of the others to accept it too - but ultimately, the purpose of the document is to guide work from the community.

That's why "actionable" is the first item on the list. People should be able to read it and know what they can do to help achieve this goal. This also why "understandable" is the second item: contributors, who are not necessarily experts deeply involved in the discussions need to be able to make sense of it so they can do work that helps get to the right answer. Of course, if need be, they can always ask for help and clarification, but the more independence contributors can have, the smoother things will go. We want code authors to know what to write. Code reviewers know what to look for in review. And PR managers to know what to pull and when to pull it.

The third item on the list is checking if the proposal is technically sound. This is where we diversity of subject matter experts on the council come in: if a DIP is outlining a web library for Phobos, for example, we want someone who knows how to judge web libraries specifically weighing in. If it is proposing an addition to the language, we will want the expertise of programming language theorists. Think "peer review". No one or two people are likely to know enough to intelligently guide the development of a general-purpose language like D.

The fourth item is consistency, and this is where the majority of any council ought to be able to weigh in.

Of course, other issues may be risen throughout the deliberation; ultimately, the decision is arbitrary, after all.

So, how does the deliberation work? How do we keep it on topic without the endless distractions that are liable to happen on the open forum, yet keep the reasoning understandable so people can rest assured they were treated fairly in rejection?

My proposal is that the steering council's discussion thread is private until a decision is made. Only after the decision is made to accept or reject does the thread open to the public - and then, only as a read-only archive.

Should DIPs include implementations?

Here, I've been talking about documents that guide future work, but it often helps prove that a design is useful and complete by simply providing an implementation that people can use. Furthermore, having an implementation ensures it can be implemented and lets an accepted DIP immediately get deployed, without waiting an unknown amount of time for the implementation to actually materialize.

While I do think having an implementation would be great, I don't think it needs to be required. Some implementations can be a huge amount of work that would be wasted if the DIP were to be rejected. It'd probably be something to consider on a case-by-case basis while looking for steering councillor champions.

Similarly, some DIP documents may be more or less detailed than others. They don't have to be set in stone; it reminds me of the waterfall vs agile debate. Remember, a DIP document's key goal is to guide work, not *be* all the work. They can be expanded and revised in the future. This isn't an excuse to accept half-baked ideas, but the peer review considerations also isn't meant to require everything be perfect up front, no, that'd raise the barrier to entry too high and risk people just giving up rather than take the chance they'd put in tons of work for something that is going to be rejected anyway.

Remember, we want to encourage and guide good work in a productive direction.

Blog Articles
Page generated by adrdox