Define triage role criteria and process

[handrews]

Once its own new membership is established, @OAI/tsc needs to define

• The process for adding to @OAI/triage
• The criteria for being considered for @OAI/triage
• The scope of what @OAI/triage members can, should, and should not do

Various other current Process issues, particularly around defining issue closure criteria, are likely relevant.

[handrews]

After attempting to further classify the large number of "security" issues and talking with folks more knowledgeable about that space, I think we need to recruit a security person into the triage group. Out of all the issue areas, that's the one Im least comfortable attempting to organize.

[handrews]

One thing that the triage team (and by extension, the maintainers team) needs is the ability to transfer issues to other repos, specifically:

• learn.openapis.org (most requests for examples, clarifications beyond what is necessary for the spec, more documentation in general, and probably also the "please help me with X" questions as they are most likely to be relevant to improving the learn site)
• Toolling (sometimes people announce their tools in the spec repo)
• Outreach (the occasional issue about community engagement rather than the spec itself)
• sig-moonwalk (beacuse Moonwalk)
• sig-workflows (hasn't really come up, but eventually someone will file something that belongs here
• Overlay-Specification (should be sig-overlay? we have several overlay issues to move)
• (probably all the other sig-* repos?)

Basically, I think triage folks should have the same permissions across all of the repos that might be better homes for issues people file on OAI/OpenAPI-Specification

[miqui]

@handrews - what about managing labels?

[handrews]

@miqui that's already enabled for the triage group.

[handrews]

Some thoughts on what you need to show that you understand in order to join the Triage group, some of which is still being worked out:

• what the various labels, milestones, and projects mean and are used for (see Audit, reorganize, and document labels (and probably also milestones) #3509)
• what goes in issues vs discussions (see Define criteria for filing/closing issues vs discussions #3518)
• when it is OK to close issues or discussions for various reasons (also Define criteria for filing/closing issues vs discussions #3518)
• what can go in a patch, major, or minor release in order to properly use milestones (see 3.x.y patch release approach #3528 and 3.x minor release approach #3529)
• when to route issues to specific other repositories (see an earlier comment of mine in this issue)