Lock Major Change Proposal issue #1858
Conversation
... and our bots as well, I imagine. Correct? I am more or less neutral on this change, my remembering is we don't have very often people discussing on the issue itself and ignoring Zulip. On the other end, why not 🙂 |
Yes, they also get "write" permissions.
I agree it's not very recurring but when it happens we are put in a bad state where the comment will likely be missed and if it isn't missed we have to remind people to post it on Zulip which IMO greats a bad taste (especially for newcomers). It greats a disconnect between the two place, which this PR makes it much harder to happen for IMO a small cost. |
This comment was marked as off-topic.
This comment was marked as off-topic.
| @@ -416,6 +416,18 @@ pub enum ReportedContentClassifiers { | |||
| Spam, | |||
| } | |||
|
|
|||
| #[derive(Debug, serde::Deserialize, serde::Serialize, Eq, PartialEq)] | |||
| pub enum LockReason { | |||
There was a problem hiding this comment.
Which of these reasons would apply to the use case "tracking issues are just not for discussions"?
There was a problem hiding this comment.
None of these apply/transmit the idea we want, so I wouldn't use any of them. The reason is optional anyway, I didn't use any of them for this PR.
|
Ok, so personally I am in favor of experimenting this, it's just for the Compiler MCPs so a relatively small audience - which I think it's safe to assume is already mostly on Zulip, so probably my concern about "where else would a discussion take place" is unfounded. I'll let T-compiler get a FIY about this. |
This PR makes it so that every new major change proposal issue is locked by default.
This is done to affirm more strongly that discussion should happen on the generated Zulip thread instead.
This is particularly relevant for outsiders who (I think) just skip the part about no technical discussion on the issue, as it will systemically prevent them from doing so.
The locking of the issue doesn't affect "collaborators", aka members of the repo with at least "write" access (which is the case for all t-compiler/t-types members).
cc @apiraino
r? @ehuss