Add more information about core team processes

[wouterj]

No description provided.

[Kocal]

Thanks for adding such informations, that's really helpful!

[javiereguiluz]

Wouter, thanks a lot for contributing these improvements. Thanks to reviewers too.

---

I like everything except this change:

"minor change" --> "peripheral change"

Minor is self-explanatory and everybody is used to it. Peripheral is an euphemism that needs to be explained in order to know exactly what it refers to. I don't think "minor" is offensive or problematic at all. Some changes, some work, some ideas, etc. are minor compared to others. I think that's fine.

[wouterj]

Minor is self-explanatory and everybody is used to it. Peripheral is an euphemism that needs to be explained in order to know exactly what it refers to. I don't think "minor" is offensive or problematic at all. Some changes, some work, some ideas, etc. are minor compared to others. I think that's fine.

See #20720 (comment). This doesn't have anything to do with offensive wording, but rather using 2 separate definitions of "minor change". One is when you should merge a PR as minor/bug/feature, and the one I changed to "peripheral" is what is referred to as typo fixes/cs fixes that core team members are allowed to push to the repository directly (e.g. after a merge).

[fabpot]

Minor is self-explanatory and everybody is used to it. Peripheral is an euphemism that needs to be explained in order to know exactly what it refers to. I don't think "minor" is offensive or problematic at all. Some changes, some work, some ideas, etc. are minor compared to others. I think that's fine.

See #20720 (comment). This doesn't have anything to do with offensive wording, but rather using 2 separate definitions of "minor change". One is when you should merge a PR as minor/bug/feature, and the one I changed to "peripheral" is what is referred to as typo fixes/cs fixes that core team members are allowed to push to the repository directly (e.g. after a merge).

Maybe "insignificant" changes would do? Or "unsubtantial"?

[javiereguiluz]

I disagree about the need to split the current "minor change" concept into two concepts: minor and peripheral/insignificant.

I think we need simpler processes and rules, instead of making them more complicated.

[wouterj]

We don't change any rules, the document as it currently is live uses "minor change" for 2 different definitions. This is just to remove confusion by making sure each term only has 1 definition.

[javiereguiluz]

That's where we disagree. The current document only has one type of minor change that comprises this:

Minor changes comprise typos, DocBlock fixes, code standards
violations, and minor CSS, JavaScript and HTML modifications.

This has served us well for so many years that, in my opinion, we shouldn't make any change about it.

[wouterj]

We have two:

The first one allows more changes than the second one. Currently, the document can confuse new team members into thinking that only PRs containing exclusively "typos, CS, docblock fixes, minor CSS/JS/HTML modification" should be merged as "minor". Which is not the case and results in a more convoluted changelog. This is why I think it's important to disconnect the two of them.

[javiereguiluz]

Ah, I see my misunderstanding now. Thanks 🙏

I consider both the same. To me, all the things listed in both cases are "minor things that don't need to be listed in the CHANGELOG file":

• Typos
• Changes in Markdown files
• Adding test files
• Adding or updating translations
• Docblock fixes
• Code syntax fixes
• CSS/JS/HTML updates

[wouterj]

But I don't think we want core team members to push PHP logic changing commits to the version branches without PR, which would be the case if we combined it into one definition.

[chalasr]

Once comments resolved. Thank you!

[nicolas-grekas]

typo: pointing :)