[core] Reference commits in changelog when no PR

[oliviertassinari]

I occasionally, or quite frequently, push commits on the master branch of Material UI, Base UI, MUI X, Pigment CSS, etc. anytime I see a change that:

• a. Has no knowledge-sharing needs, not much room to delegate it, or at least it doesn't feel like the added latency in the PR review time. I don't want to overwhelm the PR review capacity of the team, when it feels like it would overload it.
• b. Is trivial, no much value is having a second pair of eyes.
• c. Is safe, no much value in running the CI against it.

(I get this balance wrong sometimes, I should likely be more moderate with this). In any case, there are use cases, I think ones that could be open to more team members.

Here is the value of this change, better DX for developers in the GitHub release page:

 - [code-infra] Link to production app for bundle size (#44076) @oliviertassinari
 - [core] Remove [website] from changelog (#44069) @oliviertassinari
-- [core] Apply #44052 to the latest release as well @oliviertassinari
-- [docs] Fix 404 link to Next.js @oliviertassinari
-- [examples] Avoid git diff when playing with examples @oliviertassinari
+- [core] Apply #44052 to the latest release as well (82a8253) @oliviertassinari
+- [docs] Fix 404 link to Next.js (a25a365) @oliviertassinari
+- [examples] Avoid git diff when playing with examples (bfe28ad) @oliviertassinari
 - [website] Fix outdated references to XGrid (#44046) @oliviertassinari

[mui-bot]

Netlify deploy preview

https://deploy-preview-44115--material-ui.netlify.app/

Bundle size report

No bundle size changes (Toolpad)
No bundle size changes

Generated by 🚫 dangerJS against 0e80eb2

[aarongarciah]

Nice

[mnajdova]

I am ok with the change, but honestly I would advocate against this in general.

a. Has no knowledge-sharing needs, not much room to delegate it, or at least it doesn't feel like the added latency in the PR review time. I don't want to overwhelm the PR review capacity of the team, when it feels like it would overload it.

If the PR is trivial the PR review time would be very short, so I don't think we should worry about this. On the other hand if the PR is not trivial, we likely want a review anyway.

b. Is trivial, no much value is having a second pair of eyes.

Yes, but if people see you fixing similar stuff a few times, they may catch up on the idea that this is important and keep an eye for it themselves. So yes, it's trivial or it wouldn't teach people a lot, but it may bring awareness of some issues that people tend to ignore.

c. Is safe, no much value in running the CI against it.

This is valuable if you need to do a quick release/publish the docs, otherwise, I don't see the value.

[aarongarciah]

Agree with @mnajdova's points. Even the simplest changes can leave master in a bad state e.g. a documentation change that introduces a Vale lint error.

[oliviertassinari]

If the PR is trivial the PR review time would be very short, so I don't think we should worry about this. On the other hand if the PR is not trivial, we likely want a review anyway.

@mnajdova I Agree, the problem is that it: 1. usually takes days. context shifting cost 2. PR overhead (I could look into CLI automation)

Maybe the solution is to go back to the PR review timeline that we used to use during v1 to v4 era with Sebastian: 3 days. If no reviews and you have a positive review balance (more reviews left than PR opened), you can merge after 3 days. e.g. I should merge mui/pigment-css#277 before the end of the week (I hesitated to make a direct commit, but wanted to benefit from the opposite of point a.)

I would also do batch PRs at that time, e.g. #28381 has 12 small ones. It had a few cases where I was frustrated that it made git blame harder. But I was doing so many of them, x4+ more than today, that it was probably the best compromise.

Yes, but if people see you fixing similar stuff a few times, they may catch up on the idea that this is important and keep an eye for it themselves. So yes, it's trivial or it wouldn't teach people a lot, but it may bring awareness of some issues that people tend to ignore.

This sounds about a. I would ideally not work on those but, if the problem, in the opportunity cost referential, look like nice value / low effort, and especially if it has been here for a while. I might as well go for it. I think that seeing (painful enough to be seen) something unsolved for a long time (team spread thin) that can be fixed quickly (<15 minutes) feels like a signal enough that I should prioritize it.

This is valuable if you need to do a quick release/publish the docs, otherwise, I don't see the value.

With infra items, we sometimes need to push small changes to Base UI, Pigment CSS, MUI X, MUI Private, MUI Public, and Material UI. 6 PRs. It's tough.

I will continue to try to refrain myself on making those direct commits 👍

Even the simplest changes can leave master in a bad state e.g. a documentation change that introduces a Vale lint error.

@aarongarciah Yeah, this is definitely a case of overreach for those commits when it breaks the CI.

[oliviertassinari]

I have created https://www.notion.so/mui-org/GitHub-PRs-7112d03a6c4346168090b29a970c0154?pvs=4#129cbfe7b66080319e93d2d79126dd0a to reflect this discussion.

@hasdfa https://github.com/mui/mui-private/commit/84be4928b0cbf7dcb82e37b77094a0811d24bff3 can fit under this policy, but the other ones don't, e.g. https://github.com/mui/mui-private/pull/649, which propose to revert/partially-revert two of those direct to master commits.