Currently when a packager requests a new branch for a package, the RelEng tooling is set up to allow the request in the following scenarios:

• the requestor is an admin (or in a group that has admin) on the package
• the requestor has commit (or in a group that has commit) permission on the package
• the requestor has collaborator (or in a group that has collaborator) permission on the package via a branch matching pattern

We intentionally don't allow members of the provenpackager group to request epel* branches to avoid maintainers feeling like they're forced to maintain EPEL packages.

However, there is a special scenario that needs further consideration: a package already has an epel* branch but needs a corresponding epel*-next branch. In theory the existence of the epel* branch means that an admin, committer, or collaborator has already agreed to maintain the package in EPEL. I think we should allow members of the epel-packagers-sig to request epel*-next branches on any package that already has the corresponding epel* branch (i.e. epel9-next when epel9 exists). I've seen instances where a bug is reported for an EPEL package that doesn't install on CentOS Stream, meaning an EPEL Next build is needed, but the maintainer is unresponsive or doesn't understand the problem. This results in an unnecessary delay in fixing the installability bug. I think we should allow this via the RelEng tooling, and create an EPEL policy similar to the proven packager policy that states epel-packagers-sig members should try to communicate with package maintainers before taking action.

If anyone reading this needs clarification on when an epel*-next branch is needed, please refer to the docs.