Do we want something complex or simple? BTW we can use something from Packagist. I've just searched trying to find an independent ones and have found some that could be useful for us:
1. https://github.com/alexshelkov/SimpleAcl
2. https://github.com/fsi-open/acl

Did not explore them deeply though.

Do we really need an acl?

Surely the github api can handle all the repo permissions. Login via github and you get the same privs on the tracker for each tracked repo as github gives you.

If you don't have a github login then contributing will be hard, but for those who really don't want a github login there could be a 'guest' level setting with the ability to create and comment on the tracker -

1. but the issues and comments are not sent to github automatically.

So the repo owner, or someone with committer privs, just logs in and can forward the guest users' contribution with an additional flag (like tracker guest post) and the comment or issue text is prefixed with the tracker username/email

OR

1. The issues and comments are sent to github using a 'special' account, but the comment or issue text is prefixed with the tracker username/email for traceability purposes.

This way the tracker is simply replicates the github acl, anyone with owner or commit privs on the tracker repo is a super-admin (to use the CMS terminology) on the tracker app. Anyone with owner or commit privs for one of the other repo's the tracker app is tracking is a manager (again using the CMS terminology)

Chris.

The app will wrap the GitHub API, but there will also be some data saved to it that isn't saved on GitHub. As for GitHub's ACL, they only recognize public or private for repos and enabled or disabled for issues. If it's public and issues are enabled, you have the ability to open new issues, comment on all issues, and close your issues. Additionally, it's intended that there would be more than just the tracker later down the road, like reporting tools, and there's thought of possibly moving the security tracker to the app too (which we obviously wouldn't want to be public).

This has been resolved as part of #111