This Week in D

DIP DIP part 2: the user side

Blog
Posted 2022-11-28

A while ago, I wrote up a proposal to improve the maintainer's side of the DIP process. More recently, I wrote up some thoughts on how to improve the user side of it, which is here following the stats.

Core D Development Statistics

In the community

Community announcements

See more at the announce forum.

DIP DIP, Part 2

Formal meeting often seem silly when you have a small group of people who mostly agree. Going through processes without objection feels like a waste of time. But once you have open adversity or direct contention, the formal processes provide a way back to productivity. Since we work online, formal processes can be implemented, in part at least, by a computer.

One of the rules the current DIP process has is that no replies are permitted in the feedback thread. This is not well enforced, and if it were, it'd leave a real problem open of trash feedback being posted and unanswered. We'd want a process to make this work better, giving both a requirement and an outlet for discussion while keeping the feedback thread clean.

What I envision is that DIP feedback posts would only be made as a result of a discussion thread, and DIP discussion threads take place in a special-purpose, temporary forum instead of using one unstructured thread on the regular forum.

Here's how it'd work: first, the DIP manager announces a new dip discussion. This opens up the new forum for the discussion. People who have something to say about the DIP can create threads in this new forum. Each thread gets an associated editable document, like wiki page or a google doc or similar, that people can suggest changes to and vote yes or no on. This editable document is the draft feedback post.

All discussion threads will stay open for at least a couple days to give people a chance to weigh in. They can discuss changes, suggest changes, or place a simple vote on the document: yes, this is feedback I want posted to the DIP or no, this post should be dropped. People can also vote on the thread as a whole: to keep it open or to close it. When enough people have voted to close the thread, no further posts are permitted and the feedback document is considered finalized. If it had the yes votes, it is now formally submitted as DIP feedback and the author will have to consider it. If not, it is dead.

What, exactly, qualifies one to vote? And what constitutes a quorum, when you can count the votes? In a formal meeting, this is the recognized members at the meeting. But online, you can't just take attendance. I think we can do it with just any registered forum user can vote and the vote stays open based on some math: the guiding principle is to just look at the number of votes taken in the last day and ask if keeping it open for one more day is likely to change the outcome. You don't want to close it prematurely before the people have spoken, but you also don't want a slow trickle of votes to keep it open forever.

I don't know the exact math, but I know there's ways to calculate this with a decent probability of accuracy. And we can have people empowered to overrule the algorithm if needed.

While you might still want an appointed moderator to oversee it, I think such a thing would achieve the following goals:

  • Making sure DIP feedback is well-discussed before it is posted. This makes it practical to ban other replies and maintain strict separation.
  • Keeps the feedback thread itself clean. This means DIP authors can be mandated to reply to feedback without wasting much of their time.
  • Isolates and closes unproductive discussions so they don't go on forever.
  • Provides a chance for everyone to be heard before a thread is closed.

It would be interesting to see what kind of UX we can get with computer assist to implement this. If I had the time....

maybe someday. but first I have touch input in simpledisplay and synth in simpleaudio to finish!

Blog Articles
Page generated by adrdox