On the manage teams piece, if we give anyone any level of access, they will have the ability to merge pull requests. Do we want to have the entire JBS able to do that? No offense intended to anyone who may read this, but I would not trust having that many people (or some of the people in that group) having merge permissions on our projects.

That's why, IMO, there has to be a finer ACL and tuning of that in the tracker versus GitHub. Out of the box, all the permissions should match what you can do with GitHub at the various levels (guest, logged in, elevated permissions, etc.).

That's why, IMO, there has to be a finer ACL and tuning of that in the tracker versus GitHub. Out of the box, all the permissions should match what you can do with GitHub at the various levels (guest, logged in, elevated permissions, etc.).

Yes that's right, but what I was saying is manage the "teams" through Github itself. So manage the JBS members on Github; they would have pull request rights only on Github itself, but the Issue Tracker would let them do more via the interface. Maybe one day Github adds a few extra layers of access control and you can just move the JBS team on Github into that new level and viola, you are golden.

Just to clarify, you have the option of making a team within and org "Pull Only".

And pull only is the same as "merge pull requests". If they had any level of ACL that was lesser (manage labels, milestones, assign individuals, close issues) it would be a totally different discussion. Until that happens, I'm not comfortable assigning everyone to that "lowest access" group.

Pull only does not have merge. See https://github.com/blog/674-introducing-organizations

Pull Only - This new permission level is useful when you want to give people access to see the code, participate in private issues/wikis, or work in their private fork. These members may not push to the organization owned repository.

That level is no better than someone not being on any teams. I moved my @jissues-bot account out of CMS maintainers and into a pull only team on the CMS repo. No ability to work with labels, milestones, etc.

No, no, you mis-understand. Use the pull-only teams as the point of truth for the "members of the groups". Use the Issue Tracker and its API to supplement the actual access control itself.

OK, that could be done. Without a UI though in the tracker to manage those mappings, that equates to hard coding it somewhere. Or am I missing another piece of this?

Regarding the rest of the proposal:

The labels could theoretically be done. The issue becomes how to distinguish between a label that is for priority, a label that is for category, and a label like PR-master to make filtering a little easier on GitHub? It would have to be a future friendly system too.

The milestone management could be within the application. Why would we need Jenkins to do something we can handle natively?

Testing requirements is a discussion outside the application IMO. Totally agree on that proposal though, far too much gets stuck in the system because we have a one size fits all ruleset with regards to patches. Technically, even unit test patches have to get tested before commit in the current workflow!

Cookie jar and backlog - That's a funny thing to think about. Do we let the tracker have a glorified TODO list built into it or continue using it for active reporting of issues or working out feature requests? Not something I think should be decided based solely on the application, but it can certainly be supported with ease. Remember also, the roadmap calls for eventual merging of the ideas pool into this thing.

Without a UI though in the tracker to manage those mappings, that equates to hard coding it somewhere.

Yes, you'd need some admin UI to make those mappings, but you don't have to add UI to manage the members of the groups themselves. I'm proposing just leave that up to Github.

The issue becomes how to distinguish between a label that is for priority, a label that is for category,

I use prefixes. Slash for a category (aka namespace, and you could nest them like /administator/com_articles). I use tilde to denote estimates of time/difficulty, etc.

Why would we need Jenkins to do something we can handle natively?

I'm proposing that people use hash tags for confirm (#confirm or #confirmed) or test (#test or #tested). If someone confirms an issue in a comment it can automatically move from no milestone to the "Confirmed" milestone. Similarly when a PR gets two #tested tags, it could move to "Review Ready".

Testing requirements is a discussion outside the application IMO.

Well I tried to bring it up on list and that was a dead-end discussion. Whatever the case, it's still part of the workflow that that we need to address.

Do we let the tracker have a glorified TODO list built into it or continue using it for active reporting of issues or working out feature requests?

I don't see why not. That would be my preference just as we've one with the Framework.

I would like the application to be able to manage trackers that are not managed on GitHub. E.g. a Joomla! security tracker, a feature tracker, etc.
So I think we need some form of "basic ACL"

Using the GitHub labels to implement things like priorities, categories etc sounds very good.
Maybe we can define some common prefixes (maybe / for categories, Pn- for priorities etc) that are just hard coded ?

I can not really see the advantage of using milestones. I think that's where our "statuses" come in - but yes, they are very project specific and there is currently no way to define them on a project level. Should we also use labels here ?

It will be interesting to see how a script intelligently parses the comments, if we go with the hash tag parsing thingy.
Don't try to be too smart - never trust the machines

In the end, the first thing to do IMHO is to shut down JCode and move to the GitHub tracker. When this is done we will see what's missing.

has not been implemented.