The GitHub Committer Authorization strategy needs a complete overhaul in my opinion. I don't use it at all because of challenges I faced around it. I use a Matrix-based authorization strategy. The authorization options are documented in the wiki.
Regarding your question, how I have configured Jenkins is to set up Jenkins much like GitHub. For instance, if you have an organization named jenkinsci in GitHub and a project named github-oauth, then in Jenkins the project is organized with jenkinsci/github-oauth. Use the project-based matrix authorization strategy and you can restrict the jenkinsci folder only to members of the jenkinsci organization.
From there, I essentially created the following GitHub teams:
- jenkins-owners (highest privilege) - permission to delete the entire GitHub organization folder and delete any job in the folder. Inherits perms from jenkins-admins and jenkins-developers
- jenkins-admins - Update builds with additional information and add/delete views. Fully manage credentials and delete builds from jobs.
- jenkins-developers - Execute/Cancel builds. View job configuration (read only). View credentials (read only).
Here's how I set up the permissions for the GitHub organization folder (assuming your organization is jenkinsci with the above described teams):
- jenkinsci permissions - Item.Read
- jenkinsci*jenkins-owners permissions - Item.Read, Item.Cancel, Item.Delete, Item.Build, Item.ExtendedRead, CredentialsProvider.View, CredentialsProvider.Create, Run.Update
- jenkinsci*jenkins-admins permissions - Item.Read, Item.Cancel, Item.Build, Item.ExtendedRead, CredentialsProvider.View, CredentialsProvider.Create, Run.Update
- jenkinsci*jenkins-developers permissions - Item.Read, Item.Cancel, Item.Build, Item.ExtendedRead, CredentialsProvider.View, Run.Update
- anonymous - Item.Discover, Item.ViewStatus
I don't give any user the ability to create jobs. That's offloaded to the Job DSL plugin. Folders and permissions are created per organization using Job DSL scripts as well in my install.