Stream: t-lang

Topic: Design meeting: procedures


nikomatsakis (May 13 2020 at 17:00, on Zulip):

Hey @T-lang design meeting starting now

Paper document

nikomatsakis (May 13 2020 at 17:03, on Zulip):

The meeting invite seems to have a hangouts attached to it...?

nikomatsakis (May 13 2020 at 17:04, on Zulip):

Removed.

nikomatsakis (May 21 2020 at 09:51, on Zulip):

I started working on a draft RFC for this

nikomatsakis (May 21 2020 at 09:51, on Zulip):

I am wondering about something

nikomatsakis (May 21 2020 at 09:51, on Zulip):

@Josh Triplett we had always talked about the idea of people having a "short list" of ideas that they may wish to pursue once the active projects are done

nikomatsakis (May 21 2020 at 09:51, on Zulip):

I think this is a fine idea, but I am thinking that it doesn't necessarily make sense for that to be a "special status" for a proposal

nikomatsakis (May 21 2020 at 09:52, on Zulip):

i.e., it seems like we should keep those notes, but we should merge/close the proposal as we would any other proposal that is not getting activity -- simply because "the future never comes" ;)

nikomatsakis (May 21 2020 at 09:52, on Zulip):

but I'm curious if you envisioned some other active state -- e.g., making a zulip thread or something?

nikomatsakis (May 21 2020 at 10:13, on Zulip):

Draft rfc in this hackmd

Josh Triplett (May 21 2020 at 17:21, on Zulip):

So, two separate notions:
1) For "ideas" (not in proposal form yet and without someone specifically championing them) he team should have a wishlist, which belongs somewhere like the repository's README.md rather than open issues.
2) In my opinion, proposals that someone has actually proposed, that the team is happy for someone to work on, and that someone's willing to be the liaison for, but for which all volunteered liaisons are fully occupied, should stay open so that they form a visible "backlog".

nikomatsakis (May 21 2020 at 18:12, on Zulip):

/me thinks

nikomatsakis (May 21 2020 at 18:12, on Zulip):

heh so one way to do this would be to leave a comment every so often :)

nikomatsakis (May 21 2020 at 18:12, on Zulip):

"still thinking of doing this!"

nikomatsakis (May 27 2020 at 18:02, on Zulip):

So I updated this draft proposal today btw and I think it's getting close to move forward

nikomatsakis (May 27 2020 at 18:02, on Zulip):

The one major question I'm wondering about is whether to RFC project group creation

nikomatsakis (May 27 2020 at 18:02, on Zulip):

I'm leaning towards "no"

nikomatsakis (May 27 2020 at 18:03, on Zulip):

Though I think there is room for sometimes making a decision

lcnr (May 27 2020 at 18:09, on Zulip):

Something like:
If the MCP is a good fit, then a lang team liaison may opt to accept it and work with you.

lcnr (May 27 2020 at 18:13, on Zulip):

would _____

nikomatsakis (May 27 2020 at 19:39, on Zulip):

OK I made some major edits

nikomatsakis (May 27 2020 at 19:41, on Zulip):

In particular, after some discussion and thought, I've adopted a workflow closer to the compiler team:

This solves the "what is the formal decision point" question (the FCP'd PR) and also preserves what I think is a more familiar workflow (open an issue to represent an unresolved question, resolve with a PR). I think the idea of auto-merging PRs was nifty, but had some real downsides in practice (I left notes in the RFC about those).

nikomatsakis (May 27 2020 at 19:41, on Zulip):

I'm feeling good about the RFC now except that it doesn't include any diagram and I'd like one

nikomatsakis (May 27 2020 at 19:41, on Zulip):

At this point I think the RFC is almost ready to merge

nikomatsakis (May 27 2020 at 19:42, on Zulip):

One question I did hit: what is the "procdure" to decline a proposal?

nikomatsakis (May 27 2020 at 19:42, on Zulip):

In particular, I think fcp close doesn't make sense, given that we will also auto-close after enough time

nikomatsakis (May 27 2020 at 19:42, on Zulip):

I settled on something like

nikomatsakis (May 27 2020 at 19:42, on Zulip):
nikomatsakis (May 27 2020 at 19:43, on Zulip):

I do feel like if we're going to post rationale, we need to leave space for people to respond and for us to consider that feedback

nikomatsakis (May 27 2020 at 19:43, on Zulip):

but I also don't want to make it so that we're inclined not to post feedback because the procdural hassle is too much

nikomatsakis (May 27 2020 at 19:44, on Zulip):

I guess I tend to think we should just post rationale and close but "without prejudice" in some sense

nikomatsakis (May 27 2020 at 19:44, on Zulip):

though we could also just post rationale and let the auto-closed handle it :)

nikomatsakis (May 27 2020 at 19:45, on Zulip):

In any case, I think I'm going to open the RFC soon

Josh Triplett (May 27 2020 at 19:48, on Zulip):

I'm hoping that issues rarely get auto-closed.

Josh Triplett (May 27 2020 at 19:48, on Zulip):

nikomatsakis said:

I do feel like if we're going to post rationale, we need to leave space for people to respond and for us to consider that feedback

People can respond to a closed issue, and we can always reopen it. Closing doesn't prevent us from considering feedback, it just gets something off of our "we need to do something about this" queue.

Josh Triplett (May 27 2020 at 19:49, on Zulip):

(And, of course, someone can also post a new proposal.)

Josh Triplett (May 27 2020 at 19:50, on Zulip):

I'm hoping that the lighter-weight proposal process, and in particular that we only have to agree "we're likely to accept a solution for this" without having to agree on a specific solution, will make it easy for us to either accept or reject proposals.

Josh Triplett (May 27 2020 at 19:51, on Zulip):

We do need a path for "accept in principle but nobody has time", as well, and I'm hoping the github "board" and queues/labels help us with that.

nikomatsakis (May 27 2020 at 20:08, on Zulip):

OK, I updated the text, although I do think leaving a comment and closing (without giving people a chance to respond) is a bad look.

nikomatsakis (May 27 2020 at 20:08, on Zulip):

I think it'd be fine though to leave the comment, wait a bit, then close in a day or two

Josh Triplett (May 27 2020 at 20:09, on Zulip):

I think leaving a comment and fcp-closing might be fine. Maybe even with a shorter time bound.

nikomatsakis (May 27 2020 at 20:19, on Zulip):

We can revisit, but I think it's overkill.

nikomatsakis (May 27 2020 at 20:19, on Zulip):

We've seen that we suck at closing RFCs

nikomatsakis (May 27 2020 at 20:20, on Zulip):

OK, I think the hackmd is good now

nikomatsakis (May 27 2020 at 20:43, on Zulip):

https://github.com/rust-lang/rfcs/pull/2936

nikomatsakis (May 27 2020 at 21:17, on Zulip):

Revised and simplified flowchart

nikomatsakis (May 27 2020 at 21:25, on Zulip):

Added some links into the RFC for it

nikomatsakis (May 29 2020 at 17:28, on Zulip):

I was talking to @boats about the question of issue vs PR and I'd like to get a few more opinions. I've sketched out the two proposed workflows here (there are some question marks).

nikomatsakis (May 29 2020 at 17:29, on Zulip):

I'm feeling a bit uncertain. I'm also wondering (separately) how important it is to have compiler team and lang team MCPs work in the same way (e.g., compiler team currently uses issues -- should it change to PRs to match?)

pnkfelix (May 29 2020 at 17:30, on Zulip):

Hmm. One would think a consistent process would be beneficial for both groups.

pnkfelix (May 29 2020 at 17:30, on Zulip):

but on the other hand

pnkfelix (May 29 2020 at 17:31, on Zulip):

the tradeoffs may diff

nikomatsakis (May 29 2020 at 17:31, on Zulip):

Yes, I agree.

nikomatsakis (May 29 2020 at 17:31, on Zulip):

On both perhaps :)

nikomatsakis (May 29 2020 at 17:31, on Zulip):

but that said

pnkfelix (May 29 2020 at 17:31, on Zulip):

in terms of e.g. lowering barrier to entry

nikomatsakis (May 29 2020 at 17:31, on Zulip):

right

pnkfelix (May 29 2020 at 17:31, on Zulip):

(where I assume an issue is much easier than a PR to fire up)

nikomatsakis (May 29 2020 at 17:31, on Zulip):

I have been feeling though that I"d like to keep a record of MCPs in compile team

nikomatsakis (May 29 2020 at 17:31, on Zulip):

a better record, that is

nikomatsakis (May 29 2020 at 17:31, on Zulip):

and be able to link to them etc

pnkfelix (May 29 2020 at 17:31, on Zulip):

I suppose tooling could auto-convert an issue into a PR

nikomatsakis (May 29 2020 at 17:31, on Zulip):

also, a side note, but I do find that the MCP template for compiler team makes it hard to find "the meat" -- a PR might help with this

nikomatsakis (May 29 2020 at 17:32, on Zulip):

because you can "view diffs"

pnkfelix (May 29 2020 at 17:32, on Zulip):

(with a fresh number, of course)

nikomatsakis (May 29 2020 at 17:32, on Zulip):

it's also not that hard to prep a PR...

Josh Triplett (May 29 2020 at 17:32, on Zulip):

PRs give you a proposal that you can merge and save

I think I just don't see the value in merging an archive of rejected proposals. But if we want to, I also think it'd be preferable to do it with tooling.

pnkfelix (May 29 2020 at 17:33, on Zulip):

nikomatsakis said:

it's also not that hard to prep a PR...

the github web UI does not make it easy to do in-browser

Josh Triplett (May 29 2020 at 17:33, on Zulip):

I feel like the set of issues (with labels) will serve as an effective archive.

nikomatsakis (May 29 2020 at 17:33, on Zulip):

In the variant where you have the issue body contain the full proposal

nikomatsakis (May 29 2020 at 17:33, on Zulip):

rather than moving it out of line

nikomatsakis (May 29 2020 at 17:33, on Zulip):

this seems true

pnkfelix (May 29 2020 at 17:33, on Zulip):

pnkfelix said:

nikomatsakis said:

it's also not that hard to prep a PR...

the github web UI does not make it easy to do in-browser

(or is that something you can enable, much the way you customize the workflow for "new issue" ?)

nikomatsakis (May 29 2020 at 17:34, on Zulip):

and is maybe the best of both worlds ins ome way

Josh Triplett (May 29 2020 at 17:34, on Zulip):

(Also, if we're concerned about our data being locked into GitHub, there are tools to archive issues.)

nikomatsakis (May 29 2020 at 17:34, on Zulip):

heh we're so far beyond that point

nikomatsakis (May 29 2020 at 17:34, on Zulip):

that is, we're so locked in anyway :)

Josh Triplett (May 29 2020 at 17:34, on Zulip):

In the variant where you have the issue body contain the full proposal

I would be all for requiring this.

nikomatsakis (May 29 2020 at 17:35, on Zulip):

yes, that's the "variant 1" I wrote up int he hackmd

Last update: Jun 05 2020 at 23:15UTC