AiC: Adventures in consensus

The comprehensiveness expected of current RFCs is a high barrier to entry and as a result there are relatively few RFCs proposed each month. "Proposal issues" will be much easier to write and I expect they will be opened at a comparatively much higher rate, and probably rehashing old questions (eg. https://github.com/rust-lang/rfcs/issues/2831)

If the goal is for these issues to be periodically reviewed and individually discussed during meetings, they will need careful management and prioritisation to avoid overwhelming the lang team.

How do you see this prioritisation happening? It sounds like there may need to be a strict policy of closing issues to ensure the number of open issues is kept small, but it will be difficult for such a process to be fair and transparent.

4 Likes

Personally i feel it will be nice if the "proposal issues" can be organized into a tree or even graph structure instead of flat list, so there'll be "item grammars", "expressions" "types", "trait system", "ownership and borrow system" (just show the idea), "ffi", "std library", "platform support" etc, that might help reduce the repetitions of old topic.

I've wondered about this too. I think my expectation was that we would not "actively curate" issues. They might feel a lot like the RFC PRs section does today -- a mix of things at various stages. But when things were (e.g.) nominated, they would be added to a queue for discussion, and we would also have some meetings -- particularly when some effort is wrapping up! -- where team members can bring up candidates that they personally find exciting and where they would like to serve as the liaison.

In this model I sort of expect "minimal" triaging. We would probably have some tag like "Triaged" and we might review what the newly opened issues are and tag them as triaged, perhaps closing "duplicates", but we wouldn't necesarily be doing much beyond that.

In other words, having an open issue wouldn't have a lot of meaning.

However, it might make sense to do more of an active triaging, but indeed that will require more time/effort and I'm not sure it's a good expenditure of time. For that matter, I could imagine just having issues "expire" after some time and close automatically.

This part is definitely worth discussing more.

One thing I would like to see is something.. idk..maybe it's wiki-like, that kind of collects and summarizes design work that has occurred in various areas. This would be separate from a "proposal" in that I wouldn't expect it to be a place where desing work is taking place, more just an index into discussions and so forth that have happened.

Ideally it might live as files in the lang-team repository.

Then when we postpone an issue, we might "file it" into such files, so that if we ever do want to pick that back up again -- or someone else is interested -- they can find the previous discussions.

3 Likes

I'm hoping that we do more active tending of lang issues than that. But I would also expect that the effort needed to triage an issue will be much lower than the effort needed to disposition an RFC, so I don't think we'll have trouble keeping up with them.

1 Like

Something else that seems relevant:

As we've discussed, I would like to adopt a "design meeting" like the compiler team has. This would mean that most of the meetings would be not so much "proposals" but rather things like "so-and-so would like to spend some dedicated time on this thing that seems imporant" (e.g., unsoundness in Pin, perhaps?). That seems like it might also be well-managed with issues, but it's a different kind of meeting request, I guess.

1 Like