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?
