Clarify the purpose and/or remit of the Technical Steering Committee

[jlapeyre]

The document ./governance.md doesn't say explicitly which decisions are in the TSC's jurisdiction. Nor does it describe which kinds of topics are of high priority.
Some items are mentioned. For example the last sentence of the paragraph describing the what the TSC idoes includes

The TSC has authority to make all decisions regarding OpenQASM (including amendments to this governance document),

The (one line of markdown) paragraph referred to above

openqasm/governance.md

Line 32 in e5a4397

The TSC responsibility is to balance a desire to allow a voice to the broad OpenQASM community with lightweight processes to enable moving fast and maintaining a consistent philosophy for the language. Thus, for example, this governance document does give the freedom to the TSC to make decisions without calling a meeting and explicitly involving contributors, but the idea is that the TSC should make use of this power judiciously. The TSC aims to build consensus among **Contributors** prior to voting in most cases. Voting to resolve disagreements is ideally expected to happen less often than voting to accept the consensus. The TSC has authority to make all decisions regarding OpenQASM (including amendments to this governance document), but should apply more process and seek more community input on constitutional changes than for simple fixes to the language specification.

is mainly about balancing TSC decisions with the broader community.

It would be useful if a first paragraph gave a concise description of what is within the TSC's purview. A second paragraph would describe how the TSC interacts with the community.

For example here are a couple of brief descriptions of the Rust "Technical Steering Meeting": one and two. Note that these documents open with a description of the steering meeting's function:

The compiler steering meeting is the place for high-level discussion and planning.

Unlike the existing triage meeting, the purpose of this meeting is to be “proactive” – basically to take a look at the priorities for the upcoming release, take stock of where we are with respect to our larger goals, and make sure we are on track. It would also potentially be a place to bring up other longer-term topics.

Of course the purpose of the OpenQASM TSC would differ from these examples.

Summarizing, it would be useful if the section on the TSC opened with a concise description. Two categories mentioned above that might be included are:

1. What is the TSC's purpose? E.g., to Debate language features? Identify areas where consensus has been reached and formalize that consensus? Introduce long range plans?
2. Identify artifacts that are directly affected by TSC decisions. For example, the language specification or the structure of the reference parser.