Migrate some content regarding process out of the governance document back into charter document.

Specifically around decision making and voting.
With thanks to Julian for assisting in this revision.

Author: Relequestual

CHARTER.md

@@ -82,9 +82,22 @@ In joining the TSC, members commit to communicate on a regular basis and respond
 ### 4.1 Project Operations & Management
 The TSC and entire technical community will follow any processes as may be specified by the OpenJS Foundation Board relating to the intake and license compliance review of contributions, including the OpenJS Foundation IP Policy.
 
-#### Decision-making via consensus and voting, and documenting decisions
+#### Decision-making
 
-See GOVERNANCE.md
+The TSC follows a consensus-seeking decision making model in which joint decisions are agreed upon by all members whenever possible.
+In some situations, a vote may be preferable, however a formal vote is expected to be an infrequent occurrence invoked only when consensus cannot be reached after multiple attempts to reach TSC consensus.
+TSC discussions and decisions are to be assumed public by default, unless otherwise decided upon on a case-by-case basis by the TSC.
+Precise criteria for which decisions are to be left private are left to the TSC's discretion and assumed to include security-related reports or discussions with a third-party who wishes their interactions to remain private, such as when they concern yet unpublished case studies or partnerships which are not yet ready for announcement.
+
+The TSC is expected to agree upon and maintain specific process and procedure which facilitate labelling or communicating which decisions have been formally decided upon by the TSC.
+This process should include a mechanism for identifying ongoing TSC discussions and decision-making.
+When concluded, decisions should include reasoning and/or justification of the TSC, as well as indication of the consensus of the committee, or lack thereof in the case of a voted decision as indicated above.
+Private decisions should also be documented in a private location accessible to parties expected to have access to them.
+
+## Code of Conduct Findings & Violations
+
+Code of Conduct incidents must be reported to the TSC by the Code of Conduct committee.
+Reports must remain anonymous, as per the Code of Conduct, but should be documented in a manner similar to private TSC decisions as mentioned.
 
 ## 5: Definitions
 

GOVERNANCE.md

@@ -31,17 +31,8 @@ There may be other grounds for removal from the TSC, such as seriously violating
 
 ## Decision Making
 
-### Decision-making and Voting
-The TSC follows a formal consensus seeking decision making model.
-In some situations, a vote may be preferable, however a vote will not be used to make the vast majority of decisions.
-In the unlikely case where it seems that consensus cannot be reached after multiple attempts, the decision process may be moved to resolve via a vote. This is not expected to happen, but defined as a backup.
-
 ### Decision-making via consensus
 
-When a TSC member looks for an issue to be discussed and a decision to be made, they must start by assessing if they feel it warrants potentially being a private discussion and decision. The TSC member must reach out to the TSC chairs to request a private discussion and decision. A discussion and decision will be private at the discretion of the TSC chairs. It is expected that decision discussions and voting will only be private in rare circumstances.
-
-The kinds of discussions which should be private include security reports or discussions with an entity where it might not be desireable to be made public knowledge to either party. This could include details of case studies or partnerships which are not yet concluded or published, where either party may need a final approval for publication or wishes for coordinated or scheduled public publication.
-
 Both the Quick and Standard consensus process require the creation of an Issue in the TSC GitHub repository.
 The Issue must:
 - Include brief introductory information about the decision that needs to be made
@@ -55,6 +46,8 @@ In addition to the requirements above, the Issue must be labeled `expedited`.
 
 While an associated Discussion is not required, if one is used, it must be clearly linked in both directions, and be labeled with `tsc-decision`.
 
+#### Quick consensus process
+
 A vote is called to see if other members agree. The vote takes place on the opening comment. This vote is different from the decision-making voting process, and only requires 3 (additional) votes in favour and none against to carry. If the vote carries, the quick process is started, otherwise the standard consensus process is started.
 
 The quick process is designed for small trivial issues where the resolution feels likely obvious, and the member who proposes the decision discussion has at least one clear resolution to present. The decision discussion owner should present the possible solution they are advocating for (in a follow up comment on the Issue. Not in the opening comment.), and ask to test for agreement. If consensus is not clearly reached, the quick process is ended and the standard consensus process is started. (Label `expedited` should be removed and `stage-1` added.)