I’ve been thinking about how to manage the UCG discussions. Here is a proposal.
TL;DR
The basic idea is simple: we try to focus discussion on one area at a time. The discussion begins with a proposal outlining the goals (here is an example of such a proposal). From there, we open up various threads that are discussing “mostly independent” topics. Over the course of the discussion, a “discussion lead” will periodically collate the details into a document living in the unsafe-code-guidelines repository, so that people can get up to speed more quickly. At some point, when we feel like we’ve gone as far as we can go, we “wrap up” the discussion and select another thing to talk about. The rest of this post kind of goes into a bit more detail on how I envision that working.
Starting a discussion
To start a discussion, a lead (or group of leads) prepares a
“discussion proposal”. This has the form of a PR against the unsafe
code guidelines repository. This PR adds a file like
active_discussions/my_topic.md – to get the idea across, I’ve
drafted an example concerning data structure representation. The
idea is that this proposal will:
- outline the topic to be discussed and the goals of the discussion,
- highlight some interesting questions and background reading,
- and propose an initial set of threads.
On the PR, we can discuss whether this is a good thing to talk about and what changes we might make. For example, maybe we want to narrow the topic, or add some more examples.
Repo and Threads
When we’re happy, we’ll merge the PR, and we’ll update the README.md
so that it describes the active area of discussion. At that point, I
thnk we’ll also open up the various discussion threads. We can create
a unique label for the area of discussion (e.g.,
A-representation-invariants) so that they are easy to find.
(I debated about suggesting we create a subcategory on internals for this, but it seemed like it might be simpler to consolidate things on GitHub. I’m open to thoughts here, however.)
The point of updating the README.md is that when you go [the repository] it should be very easy to:
- find out the current area of discussion
- come up to speed (by reading the discussion proposal)
- This relies on the discussion leads keeping the proposal up to date. See the “regular meetings and schedule” section below.
- get to the threads and join in (via a github issue search for the label)
Ending a discussion
At some point, we can decide that the discussion is “over”. The leads can then take the final summaries and kind of move that content into our “reference”, which basically collates all the results from prior discussions.
Note that discussions don’t have to reach firm conclusions: it is ok
to end with “these things are known” as well as “these things need to
be settled in the future”. As an example, when it comes to data
structure representation, I expect we will all agree that
Option<&i32> is guaranteed to be represented as a nullable pointer.
But is the same true for Result<&i32, ()>? What about a user-defined
enum with the “same shape” as Option? In the case where the right
answer isn’t clear, we should summarize the arguments pro and con. In
short, I see the job of the UCG team right now as being to document
and uncover constraints.
Regular meetings and schedule
In order to keep things moving along, I propose that every two weeks we have a regular meeting, probably on a Thursday or Friday. The purpose of this meeting is procedural, not technical – basically, we want to assess the state of the current area of discussion and decide whether to move on to a new one. The meeting will take place on Zulip, time and date to be decided via this doodle poll.
The meeting is intentionally supposed to be short and not that interesting. Instead, on Tuesday of that same week, the discussion lead will do a survey of the conversation and update the “discussion area proposal” – this will be another PR, to be merged during the meeting. This way, if you want to give your two cents, you can comment on the PR.
@avadacatavra has generously offered to act as a facillitator. What that means is that on the Monday prior the meeting, they’ll ping the discussion leads and make sure that they are selecting topics, as well as possibly other similar tasks.
Relationship to rust reference, making things official
As I wrote, for the time being, I am expecting our first goal to be to document consensus and uncover constraints – not necessarily to resolve the “hard questions”. Essentially, I see this team as trying to form a kind of “recommendation”. For that to become “official”, I think we should eventually write a T-lang RFC.
That said, I think that we have more in common than we have differences! By this I mean: I think there are tons of things that are widely agreed upon when it comes to unsafe code, but very few of those are written down. I think that rather than dive headlong into relatively controversial topics like the aliasing rules, where consensus may be difficult, we should try to start out with things where we expect to be able to reach some conclusions.
Thoughts?
