Just putting some more notes here, but I think if we can just document the rules we’ve been discussing, and amend the documentation so that committers know the rules, I would suggest we give this idea a trial period (also given @driazati’s PR implements almost all suggestions so far), so that we can revisit in a few months time, as a community.
It needs to be very explicit (guaranteed by the underlying systems/CI) that CI was skipped for a given patch. We can’t rely on committers going and checking the Jenkins job manually to verify that not a full round of checks was done on a regular day-to-day PR.
On this, I think an automated tag on Github that makes it very explicit is a good first step. Perhaps also notifying on some Discord channel, would be another idea.
I agree with @areusch and also worry that the mechanism will be abused, not by bad intentions but because people will be sure that their one-liner PR to fix a typo in a documentation is safe and so much quick to go without CI, and it will bite is in future.
So we need to be strict on who can actually submit this sort of PR in the first place, and clearly delimit the cases in which is OK to use such practice: I like the ideas in [RFC][CI] Add a `[skip ci]` tag to shortcut builds and tests - #3 by areusch.
To the original questions:
I think at least linting is mandatory and cheap enough to be always run. It is a very easy mistake to make in an emergency PR.
I feel this should be limited to committers, but have no strong opinion.
Given the normal case for a skip ci PR is an emergency fix, I think local verification done by committer, locally, is a good start.
I would like also to propose that we give this mechanism a trial period, and agree on revisiting it’s efficacy in a few months time.