Julien Danjou

Understaood. In practice, we do that already but we just follow your rule number 3 `is a member and part of a team and has write access`. We use `author=@devs`...

I'm afraid it's a bit too generic. Maybe `author-permission` being a string containing something like `admin`, `maintain`, `write`, `read` or `triage`. https://docs.github.com/en/graphql/reference/enums#repositorypermission

Ultimately might be even better to have `author` being its own object and having `author.permission`. Would make it easier to add more fields.

There are a few implicit rules on backports, such as deleting the base branch that Mergify has created once the PR is closed. You closed the PR, so Mergify took...

That sounds like a proper use case indeed and something that is not covered. We'll look into that. Maybe something like having a _passive_ strict mode where Mergify does not...

@diba1013 I'm not sure I understand what is wrong with using only `strict: smart` and not trying to command `dependabot` in any way? That's what we've been doing on this...

Hi @fabiocorneti There's no way to pass options to command for now unfortunately. We'll make our best to add this!

Hi @DanySK This is an excellent idea and is already on our roadmap. :)

It'd be cool to be able to do something like: ``` - name: notify the author if backport fails conditions: - label=conflicts # Optionally match on the branch name here...

@MangoSmoothie101010 would this "auto merge any pull request" or only certain pull requests? How would you identify them?