# MCP Retrospective survey summary

* [Zulip thread](https://zulip-archive.rust-lang.org/238009tcompilermeetings/01013designmeeting20200918MCPRetrospective.html)

## Results

Overall, do you feel the MCP process has been positive?

| Rate | Meaning | Count |
| --- | --- | --- |
| 1 | Bad for the team | |
| 2 | | |
| 3 | | `x` |
| 4 | | `xxx` |
| 5 | Good for the team | `xxxxx`|

One of the goals of the MCP process was to help people feel more informed about what's going on. How well do you think you are able to keep up with major changes occurring in the compiler?

| Rate | Meaning | Count |
| --- | --- | --- |
| 1 | I cannot keep up | `x` |
| 2 | | |
| 3 | | `xx` |
| 4 | | `xxx` |
| 5 | I feel like I am able to follow along | `xxx`|

Another goal of the MCP process was to be lightweight. Do you feel like creating MCPs or getting them accepted has been an obstacle or burden?

| Rate | Meaning | Count |
| --- | --- | --- |
| 1 | Creating MCPs is a burden | |
| 2 | | |
| 3 | | `xx` |
| 4 | | `xxxx` |
| 5 | Creating MCPs is not a burden | `xxx` |

## Good

* The focus on solely tracking status in the github issue (and driving any technical discussion to take place in Zulip) has been great, I think.
* Sets a bit of a roadblock for wide-sweeping changes, permitting discussion without the effect of "my PR is accumulating merge conflicts" hanging over that discussion
* It also encourages us to have some amount of documentation for larger changes, which helps with updates to more permanent documentation (e.g., in rustc-dev-guide).
* I can now better follow all the things happening outside my immediate area, though it's still a lot of stuff obviously, so I still wouldn't say I am following along well.
* integration with team meetings

## Room for improvement :)

* No system in place for discarding MCPs / MCP limbo
* No system for registering or resolving concerns
* New concerns sometimes arise in the PR after MCP has been accepted; difficult to know how to deal with these, especially when they are minor. There is some feeling of "we have already gone through a week-long waiting period", where were you then?
* Useful to have some kind of veto to shut down an MCP quickly
* A project board might be more effective way to help people stay on top of what's going on
* The "renaming of directory" MCP felt a bit messy, I wonder if there is a pattern we can learn from that.
* When I (nikomatsakis) submit an MCP, it sometimes feels like I have to go "fishing" for someone to second it, not sure how to engage a bit better there, maybe not even a problem.

## Meeting agenda

The clearest bit of feedback was that we need to revise the system to help in **discarding** MCPs and registering/resolving concerns. Let's focus on that.

* 5 min announcements
* 5 min questions or clarifications on comments
* 40 to discuss a system for discarding/registering concerns for MCPs
* 5 min wrap-up

## Notes from meeting

- Feedback on MCPs after being seconded can be difficult to deal with. [(link)](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210523197)
- Some feelings of "where were you a week ago" as aluded to above
- We do want to encourage feedback even if it's late but we should weigh some kinds of feedback more heavily than others "late" in the process.

- Most common feedback was: [(link)](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210523836)
- the problem of "MCP limbo", where there are MCPs that are not accepted but not clearly rejected
- the problem of how we know if a concern is present and when it's "resolved" (who decides?)
- the question of what to do about feedback after an MCP is accepted, and in particular MCPs for sweeping changes

- We should probably be closing un-seconded MCPs after some amount of time [(link)](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210524064)
- There should probably be a way for a contributor to keep an un-seconded MCP "alive". Possibly by leaving a comment to that effect.
- That would extend the time before the MCP is closed but not indefinetly. Contributors would have to keep leaving comments if they want the MCP left open (this "friction" is probably a good thing).
- @**pnkfelix** points out there isn't a good way to track these ideas after an MCP is closed.
- Meeting participants generally seem ok with that.
- There is ["fragile consensus"](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210525878) for auto-closing after a set amount of time has passed.

- Discussion about "it's hard to track concerns" [(link)](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210526028)
- "Obvious" fix is to use rfcbot concerns
- rfcbot concerns may not scale to such a large group as compiler-team + contributors [(link)](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210526615)
- A possible solution would be a small group of people whose responsibility would be to determine if concerns have been resolved sufficiently for the MCP to proceed. This likely overlaps a lot with the Technical Steering Committee idea which has been talked about before. [(link)](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210526748)
- Discussion of specific rustbot commands [(link)](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210529314)
- rustbot second -- marks this for approval after time elapses
- rustbot close -- marks this for close after time elapses, unless a contributor leaves a comment
- rustbot keepalive -- cancels a close
- rustbot concern foo -- raises a concern, any team member/contributor can do it? (or anyone?)
- rustbot resolve foo -- resolves a concern, any team member/contributor can do it
- if an issue goes N weeks without activity (on the github thread), there is an automatic rustbot close

- Discussion about MCPs that perhaps don't get enough attention [(link)](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210530507)
- The biggest example of this is probably the recent MCPs that changed the `rust-lang/rust` repo directory structure and the `x.py` defaults. [(link)](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210530930)
- Some people didn't find out until after the fact and were unhappy with the approved changes.
- For "large" or "controversial" MCPs, we may want to require a full FCP instead of simply a second. [(link)](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210531323)
- @**simulacrum** notes if there are conflicting veto/second comments, perhaps this should trigger a full FCP either immediately or within a certain amount of time if those concerns are not resolved. [(link)](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210531397) [(link)](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210532435)

- @**nikomatsakis** noted that the feedback from the survey showed nearly everyone agrees the MCP process is good for the team. [(link)](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bdesign.20meeting.5D.202020-09-18.20--.20MCP.20Retrospective/near/210532311)