I found the following snippet of docs related to matrix based authentication:

"organization - give permissions to every user that belongs to a specific GitHub organization. You have to be a public member of the organization for the authorization to work correctly."

Does this mean that team members will have to be public members of the organization in order to have access?

Nope, switching a user between public and private has no effect.

Hi Andrew, the GitHub committer authorization strategy is not very good.  I personally don't use it at all.  I use matrix authentication based strategies instead (I updated the wiki to document them).  Other than that, there's a definite need to overhaul the GitHub committer based authorization strategy.

You're welcome to contribute a fix.  I'm currently looking to the matrix authorization plugin to possibly support authorization akin to it.  I'd prefer a user to define what permissions a Jenkins user would have via a matrix based on their role in the repository and organization.

Sounds like a reasonable solution. Maybe you want to remove the github committer authorization strategy from the code since it is "not very good" and point people at the matrix, which looks like it might be a better all around solution.

Ok, I added matrix-auth plugin and now have a working, maybe even elegant solution. Thanks for the pointer!!!

I've submitted a PR which I hope addresses this issue - as we run into this ourselves. I'm not 100% certain it covers all the use cases though.

Specifically I think this fixes when a user is a collaborator on a private repository that they don't own and is owned by an org they're not a member of. If the repo doesn't fall into the "my repository listing" (repos owned by the user or the orgs they belong to) then it loads the repo itself and looks at the admin/push/pull access for that user on that repo.

https://github.com/jenkinsci/github-oauth-plugin/pull/91

I think that if the repo is a public repo (regardless of who owns it), then any authenticated user should be able to READ already. This may fix BUILD/CANCEL/other permissions for write/admin collaborators on public repos too.

Closing this issue in favor of JENKINS-27844 to completely overhaul this authorization strategy.  Subscribe and vote there so we can track it all in one place.