I am on the fence regarding this.

I refrained from enabling certain cops (ones concerned with patterns and numbered parameters) in the aforementioned pull request because they were related to Ruby 3 syntax which Jekyll has not yet adopted.
The remaining ones revolving minitest and rspec seemed noisy.

I refrained from enabling certain cops (ones concerned with patterns and numbered parameters) in the aforementioned pull request because they were related to Ruby 3 syntax which Jekyll has not yet adopted.

Aha I see. Is there a problem enabling them even if Jekyll's syntax is still following ruby 2.x? They will not be triggered until someone tries the new syntax, right?

The remaining ones revolving minitest and rspec seemed noisy.

Do you mean noisy as entries in rubocop.yml, the cop recommendations themselves?

I am not very opinionated when it comes to which cops should be enabled or not (especially since I'm new to the codebase). The main point of this PR is to have a warning-free script/fmt. Another way to achieve this can be to run rubocop with --disable-pending-cops which disables all the new cops, do you think it's a more fitting solution?

Is there a problem enabling them even if Jekyll's syntax is still following ruby 2.x?

Personally, I feel enabling unnecessary cops means redundancy.

Another way to achieve this can be to run rubocop with --disable-pending-cops which disables all the new cops

I like this alternative. Especially since that is your primary goal with this PR.
Let us go with adding this flag to the shell script and updating the PR title and description to reflect the intention.

Personally, I feel enabling unnecessary cops means redundancy.

I buy the argument 👍

I like this alternative. Especially since that is your primary goal with this PR.
Let us go with adding this flag to the shell script and updating the PR title and description to reflect the intention.

Done :)

Thanks @yboulkaid
@jekyllbot: merge +dev