tc39 / how-we-work Goto Github PK

Documentation of how TC39 operates and how to participate

how-we-work's Introduction

TC39 - How We Work

Ecma International's TC39 is the committee which defines ECMAScript (JavaScript) and related standards. This repository provides documentation into how TC39 works.

For an introduction to getting involved in TC39, see CONTRIBUTING.md.

Proposals

Meetings

Admin

Other

how-we-work's People

Contributors

Stargazers

Watchers

how-we-work's Issues

Make a new TC39 website

Navigating esdiscuss.org, ecma-international.org and various GitHub repos is a bit complicated; it's not clear where to start. @codehag is leading an effort to make a new initial TC39 destination site, based on detailed user studies.

How to do a Stage 3 proposal review

To go from Stage 2 to Stage 3, proposals need official reviews from committee delegates. Describe what goes into such a review, how to sign up for it, how to give the signoff, etc.

Terminology: "metaobject protocol (MOP)"

More elaboration on normative definition

I found @allenwb’s definition to be more useful, could we have something more elaborate on "normative"? Or something with more context?

Currently we have:

Statements that constrain the observable behavior of implementations (i.e., the behavior that conforming implementations are allowed to exhibit).

A better definition could be:

Regarding "normative". Generally, when we say "normative" in TC39 we mean something that is an actual requirement expressed in a specification. These can be big like "Promises are part of all ECMAScript implementations". To tiny, such as the ordering of specific actions within a single specification algorithm.

Most of the text in TC39's specifications is normative and most of the work of TC39 ultimately leads to decisions about new normative requirements. This includes all of the proposals going through the staged process. Deciding upon normative requirements is so fundamental it is seldom mentioned in that context.

When "normative changes" are explicitly discussed at meetings, this is usually about some very minor change to the specification of some larger feature that is already in the specification. Like swapping the order of algorithm steps or adding (or removing) a required error check. Often such changes are specification bug fixes. Sometimes they are are needed to bring the specification into alignment with what implementations actually have implemented. Regardless, they require TC39 consensus because in some way they change a requirement that will have an observable (put usually minor) impact on implementations and in rare cases could impact real world code.

Taken from https://dev.to/bnb/my-first-experience-attending-tc39-bpn#comment-a5eg

figure out how to get superlinter to use markdownlint config file

I tried in vain to move markdownlint rules to a config file (.markdownlint.json / .markdownlint.yml) -- instead of having to specify rules to ignore in every single file) but superlinter wasn't picking it up. surely there must be a way...

I did not try an .mdlrc file though because it appeared that superlinter uses markdownlint for node, not markdownlint for ruby

doc on note taking is woefully out-of-date

define "observable behavior"

This term is used here, and also here, and a number of other places. It seems like it'd be good to define it here in a detailed way.

Consider adding a short "Spec History" Section?

@waldemarhorwat gave a great, short overview of the history of the spec/committee evolution and pointed out that a lot of that history is encapsulated in some of the old spec intros. Could be cool to pull some of that and edit it for the site.

Terminology: Web compatibility/"Don't break the web"

This was requested for the TC39 website in tc39/tc39.github.io#57 .

How to transfer proposal to tc39 org

cc @ljharb

Add "viral syntax" to terminology.md

Viral syntax is something that was brought up multiple times in the top-level await discussion. I personally believe I know what it means but it would be nice to have an explicit definition 👍

Feedback + Volunteer for GA Presentation?

Context: During the ExeCom meeting in April, I was/we were asked to do a short (< 20 min) presentation at the GA meeting in June about "How We Work." The ExeCom is happy with the way we work, and the ask was to share this info with the other TCs during the GA meeting. Hopefully we can help other TCs adopt new, more iterative/productive working styles!

If you have a minute, I would really love some feedback/editing on this short Google presentation... The audience is other TC Chairs + the GA reps for our member companies, so they really don't have a lot of knowledge about our Web-based, open source working styles (See speaker notes for more context):

https://docs.google.com/presentation/d/1bYAgc4wo7tX6iRseBp8irlcnUumBIPdz3mvKaX5k7A4/edit?usp=sharing

We do A LOT, but I want to make sure that what we share here is what ya'll feel makes the biggest impact. How can we help others learn from what we do, and apply it productively for themselves?

Also, if you are planning to be at the GA meeting and would like to be part of giving this presentation, please let me know! I would be happy to hand it off.

ps - on the 'numbers' section I am really trying to think of metrics that will be impressive to other TCs. I welcome better ideas!

Timebox is 404

The link here https://github.com/tc39/how-we-work/blob/main/how-to-participate-in-meetings.md#timebox to timebox.now.sh forwards to https://timebox.vercel.app/ which gives a 404 error. (It also looks like there's some timebox features in progress in TCQ but they don't fully do counting on their own?)

Add link to the proposal repository template to the champions.md doc

I just spent much longer than expected trying to find where the template repository for proposals is.

Could someone add a link to it in the champions.md doc? That's where I'd have expected to find it.

I'd do a PR, but I'm not familiar enough with the process to be sure I'd put it in the right place.
Perhaps some some rewriting in that doc is needed to make it clear at which point a proposal repository should be created?

Thanks.

Add a definition for "reify"

I'd like the term "reify" to be added to the terminology document. I'm happy to make the PR, but given that I didn't actually know what the term meant before asking for clarification in IRC, I wanted to collect folks' thoughts on a definition here before opening a PR.

tc39/proposal-pipeline-operator debate concern

I would like to express my concern on tc39/proposal-pipeline-operator debate.

I am a TS/JS functional programmer, and waiting "pipeline operator" in JavaScript for a long time because it's extremely important for Functional Programming that is essentially algebra.

In algebra, operator is everything, that I can say. In my understanding, most of the TS/JS functional programmer have been using F# style pipeline-operator taking advantage of Babel or TypeScript experimental support.
microsoft/TypeScript#38305

As a functional programmer, I've just waited for landing F# style, and the day before yesterday, I've noticed it's now proceeded in Stage2.

Firstly, I thought it's a good news, but investigating more, I noticed some "Hack-style" is
chosen that so far I had only known mimimal/F#/Smart.

Hack-Style is a nightmare for the most TS/JS functional programmers and can destroy the healthy eco, many are mathematicians and I also admire the Algebra including F# pipeline-operator(F# is a strong functional language).

Yesterday,
@kiprasmel started a new issue that is basically against Hack implementation, and the claimed decision process is very unclear:

tc39/proposal-pipeline-operator#205

Thus, I invite everyone to discuss this Pipeline Operator thing further, and in no way rush into Stage 3.

In particular, I'd like at least the following concerns to be addressed, especially by members of the TC39 committee, especially those involved with pipeline operators, whichever side they're favoring (but everyone else is just as welcome too):

What you just read here - does it make sense, what are the shortcomings you see, what else could be improved and addressed?
Did you read anything new or was literally everything already considered?
Do you have any plans to carefully study the usability of the proposals, just like @runarberg highlighted that the Rust community has done? If no - why, if yes - how, and will it have any impact before we reach Stage 3? Or have you already done this and where can we find the results?
Do you have any concerns that the current proposal is incomplete / half-baked?
Do you have any concerns that if we move forward with the Hack proposal, without including the F#'s |>> operator together at the same time, it could lead to us missing some detail which would prevent |>> (or whatever other token choice for this functionality) from being possible, while the Hack's pipeline operator would already have shipped, and it would be too late to go back?
In general and in this case, do you think a half-baked solution is better than no solution at all -- even if there are ways to implement the solution already (Functors etc.), meaning the half-baked solution isn't necessary -- even after reading this and comments/arguments from other threads linked here -- even knowing the impact that it will have -- even knowing that we've made such mistakes in the past (nodejs callbacks vs promises)?
Do you know any people in the TC39 Committee who have a strong background in functional programming languages, e.g. Haskell, F#, Elixir etc? Did they participate in the discussions regarding Pipeline Operators?
Were there any experts in the FP field invited to participate/help make decisions with regards to the pipeline operator? Did they help? How did the committee handle their feedback, how much weight did it have?
Would it be possible in the future to be more transparent of how exactly the decision was made?
What members of the TC39 committee made the decision, what members were not present (e.g. @littledan because vacation? etc.)?
Do you believe that certain people not being present could sway the decision in one direction or another, why, and how do you make sure both sides are represented fairly and equally?
Is it still possible to switch from Hack's to F#'s proposal? Would you help facilitate the switch if you believed that F# is better over Hack, even if the switch could further delay the landing of pipeline operators, because in the long term it would be worth it?
Would there be a way to collect all information in one place (or at least clearly link to additional resources from the main source of thruth which probably should be the proposal repo README / RFC issue), as opposed to the current situation with 1) the proposal repo itself, 2) @tabatkins gist (!), 3) discourse, 4) @littledan's slides, etc.
What could I or any of the JavaScript community members do to further help with this? For this proposal, and in future ones?

I share his concern or crisis awareness, and most importantly as a JavaScript functional programmer I can't stand watching JS is mathematically disgraced.

This concern is expressed as:

7. Do you know any people in the TC39 Committee who have a strong background in functional programming languages, e.g. Haskell, F#, Elixir etc? Did they participate in the discussions regarding Pipeline Operators?

8. Were there any experts in the FP field invited to participate/help make decisions with regards to the pipeline operator? Did they help? How did the committee handle their feedback, how much weight did it have?

JavaScript is functional programming language, and the pipeline operator is extremely important, however I feel some small group of persons who do not share deep knowledge decide that critical part and destroy the JavaScript that is unacceptable.

I tried to participate the issue, but a few hours ago, @tabatkins closed.

I'm going to go ahead and close this thread; it appears to have run its course, and in any case is filled with unacceptable levels of hostility. As I've said in previous threads here, new information is welcome, or arguments one feels were unfairly passed over. But this repo has three years of arguments on this exact subject already; please review those before asking the rest of us to read twenty-three thousand words in one new thread.

Perhaps, one of the comment is

Hack style is a bad proposal that tries to combine two great proposals: F# |> + ? partial application.
For me there's no question. F# is the only way to go. Only people who have never used pipe will prefer the Hack way.

This is so true. 100% agreed.
In fact, "partial application" proposal issue is suggested in @tabatkins gist post page:

https://gist.github.com/tabatkins/1261b108b9e6cdab5ad5df4b8021bcb5#gistcomment-3692618

It's unfortunate that partial application proposal is not mentioned here, since it complements F# pipelines. F# pipelines practically has the burden that partial application as part of F# pipeline proposal is so easily to separate as a distinct proposal that no-one can really object to separating it. Hack-style #-placeholders can not be separated into a separate proposal. Thus I feel like it's unfair to do comparisons where F# pipelines don't additionally have the partial application to help them. It results in a weird situation where the robustness of partial application actually hurts F# pipeline argument.

However, @tabatkins never reacts to these questions.
For functional programmers, this pipleline-operator proposal is bundled with "partial application" proposal, and I observed Hack-style guys know nothing about it.

One of the reason he closed the thread is "unacceptable levels of hostility", but as far as I read, many comments are questioning their programming knowledge level.

I don't know him, but after a research of a couple of hour, he appears to be one of the leader of Hack-style, and I have observed he dominates the place of healthy-discussion avoiding the necessary debate perhaps because of his luck of knowledge, and force to proceed the TS39 level, and consequently could ruin the JavaScript.

We can't hold his autocratic behavior, and I strongly believe we don't have to.
Now, we need to re-open the issue.

I express my concern on tc39/proposal-pipeline-operator debate.

Thank you.

How to be an editor

As TC39 expands into an editor group, there are certain workflows that editors have, including

Tagging issues
Reviewing issues and small PRs
Reviewing PRs for Stage 4 features
Applying standard practice for when PRs are ready to merge
How to manually check that a PR has appropriate IPR provenance

It'd be great to document these.

I would love to see a table of contents in the README sort of explaining what each single-word filename represents, presumably broken up into sections (i.e. proposal-related things, spec-related things, meeting-related things. not necessarily these categories, they are just examples)

`how-to-participate-in-meetings` and `champion` still refer to Freenode

There are some Markdown documents that still refer to Freenode, however it was replaced with Matrix:

how-to-participate-in-meetings.md:

We use the #tc39-delegates channel on Freenode during the meetings. This channel is open to delegates. It is not public due to IP restrictions. The public channel #tc39 is useful for outside communication that is not during meetings. You can find instructions for joining here.
champion.md (also sends to a now archived mailing list):

Unfortunately, TC39 doesn't have a comprehensive way for non-committee members to find committee mentors/champions for their proposals, but existing forums include TC39 discourse forum and es-discuss mailing list; another is the IRC channel #tc39 on Freenode (instructions). Many TC39 delegates can be found on Twitter as well.

It looks like these references need to be updated.

How to be a host

We have a really good checklist doc with a lot of great information. It would be great to see how this doc evolve to gather more information / unwritten rules about being a host:

https://github.com/tc39/Reflector/wiki/Requirements-for-ECMA-TC39-Meeting-Hosts

License

As I am adapting TCQ to be more generic/reusable, I've found that the best documentation for it is in this repo at https://github.com/tc39/how-we-work/blob/main/how-to-participate-in-meetings.md#queue

Can a license be applied to this repository so I can re-use that in some in-tree TCQ docs?

How to write tests for a TC39 proposal

Shared conformance tests in test262 are a core part of the TC39 process which anyone from the open-source community can participate in. Thanks to @rwaldron, @jugglinmike, @leobalter and @spectranaut, Test262 has a very good CONTRIBUTING.md which explains, at a technical level, how to write tests, but there's a process test authors go to to try to get coverage for a whole proposal, put it behind a new feature flag, coordinate with proposal champions, etc which is not directly covered as far as I can tell.

@kosamari volunteered to work with the folks at Bocoup to document the process better. Thanks, Mariko!

How to implement and ship a proposal

TC39 proposals are implemented at all different stages, in native implementations, transpilers, polyfills, tools and more. Early implementations play a significant role in TC39 processes, and it would be great to have a document targeting their role, including:

TC39 appreciates you! In addition to getting features to JS developers, the process of implementation gives detailed sense of the feature within the language as a whole and its various interactions, leading to important insights about the design.
It's never too early to draft an implementation, but different stages indicate different levels of stability and concreteness. Explain the stage process from that perspective for implementers, in a way which can help guide shipping/flag/semver decisions, including case studies of various projects' policies.
All kinds of feedback are appreciated from implementers, whether it's about the motivation, high-level design, integration with various other systems, implementation complexity, or the semantics of edge cases. The best way to give feedback is through filing bugs in the GitHub repository. Feel free to make PRs against the draft spec for suggested semantic changes, if you want.
Champions want to hear from you. If you're working on an implementation and, e.g., are having trouble understanding the proposal or want help with an edge case, get in touch with the champion, either by filing the question as an issue in GitHub, writing them an email, or even asking for a call to go over things.
It's highly appreciated if you upstream any tests you develop as test262 tests

cc some early implementers; would any of you be interested in helping with this sort of documentation? @caitp @gsathya @arai-a @hzoo @rbuckton @caiolima @jakobkummerow @kmiller68

Document TC39 glossary/technical goals

We have a lot of technical jargon and general design goals that we throw around in TC39, which would be good to have documented for proposal champions and other TC39 participants. @samuelgoto has identified this problem and is working on documentation for the issue.

Note, we've created a repository for this sort of purpose; not sure if it will be useful for this particular effort.

Moving "How to read ECMAScript specification text" to this repo

Hi Everyone, I have been in touch with Timothy Gu, the author of "How to read the ECMAScript specification" -- he was wondering if this is something that could be moved to a TC39 owned repository. What do people think about making it part of this repo?

Add examples to feedback.md

As mentioned in #56 (comment), it would be nice to flesh out our "Actionable Feedback" document with some realistic examples of less effective and more effective ways of conveying the same thing.

doc on meeting participation needs updating

TC39 and corruption, abuse of power

The way that @tabatkins handled the discussion (htttp://github.com/tc39/proposal-pipeline-operator/issues/205) by effectively shutting it down, thus hurting it, preventing community members, including those of the committee, from further discussing and finding the best possible solution, is absolutely unacceptable.

The justification for it was that the rules of CoC were being violated. This is simply not true. Nobody was being mean to each other or whatever, it was a civil discussion. Like always with CoCs, their definition can be applied so broadly that it allows one to censor, silence, and do other harm, while blaming it all on someone breaking the CoC, e.g. being mean. This is absurd.

Even if anyone were to be mean to each other, how does that justify closing the whole discussion? If it's justifiable, it means that in order to shut down any discussion in control of TC39, one can get a few people, or just a few accounts, start talking sh*t to each other, and get the whole thread locked for everyone. How does this not sound completely absurd?

I argue that by shutting down the discussion, @tabatkins is abusing their power to sway the proposal. This should simply not be allowed. There is a clear conflict of interest. This is corruption.

How is this corruption? Well, the current status quo is the Hack proposal, which has advanced into Stage 2. If there is no further discussion, it will likely be the selected one. But when more discussion develops, it starts challenging the status quo. This is exactly what @tabatkins does not want, because as they've openly admitted themselves multiple times, they prefer the Hack proposal, and are biased towards it. Thus, by preventing the status quo from being challenged, they are pushing forward a proposal that they are biased towards, instead of discussing and finding the one that fits the community better as a whole.

This is clearly a conflict of interest.

Any comments?

Leaving TC39 document/guidelines?

There does not seem to be a document explaining what is actions are required, or who to contact if you cease to be an eligible tc39 delegate?

Incomplete description of copyright licensing of ecma-262, etc.

ip.md says:

The annual ECMA-262 and ECMA-402 are licensed under Ecma's text copyright policy.

This is incomplete, any code (including pseudo code algorithms) in the specifications are licensed under Ecma's software copyright policy using Ecma's BSD license. See https://www.ecma-international.org/ecma-262/8.0/index.html#sec-copyright-and-software-license

Also, all these rules also apply to TC39 created standards (ECMA-404, ECMA-415) that aren't updated annually.

Add TC39 management slides to Management document

It would be nice to have this slide deck in the Management document. I'm not sure what is the best place to add it. Any ideas?

link broken for "Sign the royalty-free patent agreement required for TC39"

this link redirects to this index page

how-we-work/join-tc39.md

Line 9 in e01a228

 - Sign [the royalty-free patent agreement](https://www.ecma-international.org/memento/Policies/Registration%20Form%20for%20the%20Ecma%20Royalty%20Free%20(RF)%20Patent%20Policy.pdf) required for TC39. 

< HTTP/2 301 
< location: https://www.ecma-international.org/policies/by-ipr/

Info on TCQ tool?

As someone who sometimes runs a similar scale of standardization meeting, I ran across the tcq app, which looks super neat, but there's literally like no information on it in its own pages, so I don't know whether it's open source, whether it's OK to use for other projects, if I can host my own instance if needed (which would be likely due to NDAs), etc.

I know this is effectively an "internal tool" so I don't want to add a lot of maintenance burden, but I would appreciate not having to re-write it :) This is the source repo, right? https://github.com/bterlson/tcq

Would it be open to MR's that would e.g. at least add some of these self identification answers ('who runs this cool thing? where is the source?')?

How to use the queue

There is a certain amount of confusion while using the queue. We should probably document how to use it. Things along the lines of (a) the difference between a point of order, a question and a clarification question, (b) how to access it, (c) how to find its link, etc.

Document TC39 communication tools

TC39 has a number of communication tools, for members and non-members, and it can be confusing to figure out how to access and use these. Although we have some explanations in CONTRIBUTING.md, I think things could be more clear. Some things which would be nice to have written somewhere include:

Feedback about existing proposals should generally be given in bugs on GitHub repositories
During meetings, there is the queue tool, and here's how to use it and what the various parts mean
Delegates use the GitHub Reflector to communicate; make sure you're added to the Delegates or Invited Experts GitHub group (ask anyone in management to add you), and watch the Reflector repository.
For TC39 delegates and invited experts, use the irc.freenode.net#tc39-delegates channel (include instructions for management to give people permission to join the channel, mention the use of NickServ)
For anyone in the community to have interactive discussion, use the irc.freenode.net#tc39 channel (include explanation of how management should operate this, giving status to delegates)
If es-discuss is referenced, include some sort of note of caution/discouragement

If he's available, I think @bterlson would be a great person to write this documentation, as he's been driving the engineering and operation of several of these tools over the years. This might make sense to divide into three different documents which are accessible to the relevant groups (community, delegates, and management). For now, we can draft this as a markdown file in this repo, while we work in parallel about the best way to surface it (#2).

is there mention of the TC39 calendar?

I don't see a link to the TC39 Events calendar or any information on how to manage events.

How to read specs

A lot of people expressed the need for documentation about how to read specs. Some specific things were how to understand what different parts of the spec mean, and how to navigate the spec

Guiding principles

It seems it would be helpful to have a document of "guiding principles" for newcomers to keep in mind when making a proposal or prioritizing concerns that arise when evaluating proposals. (Perhaps this would also serve to address some ES Discuss noise, as @waldemarhorwat and @ljharb were relating.)

My understanding is that such principles may not currently exist in an official sense, but even a simple list of the things "in the ether" among the committee would be wonderful to have.

Whether this should exist as its own document or as a preface to, e.g., #1 is an open question.

How to experiment with a proposal before Stage 4

For JavaScript programmers who want to be adventurous and give TC39 feedback on proposals, there are various ways they can try things out:

Invoke transpilers and polyfills at early stages; link to documentation for multiple of these (e.g., don't privilege Babel in this discussion), or use Node or browsers with new feature flags set
Understand the stability risk in using early stage features. Until a feature is at Stage 3, it is subject to significant change, and tweaks will continue after Stage 3.
When you have feedback, file it as an issue in GitHub

How to write documentation for a TC39 proposal

PR under development at tc39/js-outreach-groups#8 ; your comments would be welcome there. I want this to eventually live in how-we-work, but because this repository is private (https://github.com/tc39/Reflector/issues/191), and there are educators outside of the committee who could help write this article, I'm developing it there. I'd like to make this repository public ASAP so that we can avoid using these workarounds.

How to be a TC39 chair/management

There are a few things the chair group/editor group regularly does, which would be good to document in case other people take on the task in the future, including:

Scheduling TC39 meetings
Administering the queue tool during meetings
Administering the IRC channels
Administering the GitHub groups
Be elected annually

How to give actionable feedback on a proposal

Online and in person at TC39 meetings, we're always giving feedback on proposals. There are some best practices here that would be nice to document (maybe people disagree with me on these points.:

Whenever possible, give feedback ahead of a TC39 meeting in issues on the GitHub repository for the proposal. Search for existing issues which cover a topic before posting a new topic. It's helpful to give positive feedback, or feedback agreeing with a previous critique, as well as new points.
Feedback which is given in channels outside of GitHub and meeting discussions is more likely to be lost.
When in meetings, use the queue tool rather than interrupting the presentation to make a point.
Follow the code of conduct in all proposal feedback
Keep feedback respectful, constructive and actionable.
When you see a problem, explain the problem as much as possible, and avoid jumping to a particular solution.
When you don't understand the motivation for a part of a proposal, one good strategy is to ask a question about it.
We're all coming from different perspectives and have partial knowledge of the universe. Give your feedback from wherever you're at. For example, there is no need to dress up feedback in formal language if your thought process doesn't correspond to that.

It would be good to explain how the champion group is responsible for carefully considering the sum of all feedback and making a recommendation to the committee taking this into account. Champions will not always be able to find absolute consensus among everyone who voices an opinion, but they will listen carefully.

Would anyone be interested in writing up this sort of documentation? We may end up having multiple documents, for committee delegates and online contributions.

How to join TC39 as a delegate

This is the "sales pipeline" part of the website. I think we can make something friendlier and which also explains the business case more clearly than http://www.ecma-international.org/memento/join.htm

Terminology: "cover grammar"

Just noting one more item for the glossary. 😄

Guidance for proposals around new global constructors

As per the May 2021 plenary (https://github.com/tc39/notes/blob/master/meetings/2021-05/may-26.md#discussion-of-globals-and-guidance-for-future-proposals), this repo should contain a document providing guidance to future proposals that want to introduce new global constructors / namespaces.

Guide to developing well-written proposals

Building on @ljharb 's https://github.com/tc39/template-for-proposals , we could document how a well-written proposal should be made. @DanielRosenwasser wrote,

I've discussed with @bterlson and @rbuckton about the need for background, motivating examples, and potential usage for new proposal documents. Much of the time, it's not clear for outsiders what problems a given proposal is trying to solve.

I think this is a great idea. Ideally, a proposal's README or other supporting documents should describe those. In my opinion, those should be updated as a proposal advances. These can sometimes accidentally get out of date; issues and PRs from other contributors can be a big help here (this could be documented too).

Define/Describe Consensus PR Process

Esp. since this is becoming a bit of a 'grey area' - when do we use it as opposed to the staging process, etc. h/t @zenparsing @ljharb

coc md missing

Repeated abuse of power of moderation to proposal issues @tabatkins

I'm afraid that this is the second report for the repeated abuse of power of moderation to proposal issues.

The previous report is
#95 by @stken2050
#96 by @kiprasmel

@tabatkins is a champion of the current proposal and also a moderator of https://github.com/tc39/proposal-pipeline-operator/

I often observe he shuts down the discussion even middle of the debate once he feel it's against his own interest of the proposal.

What I report here is my own issue:
Does the current proposal override the Grouping operator ( ) with Hack |> ?
tc39/proposal-pipeline-operator#229

Surely this has a significant impact to JavaScript as a whole and should be investigate thoroughly taking time, however he had shut this down making invalid in very short period of the time (4 hours).

After the shutdown by him, the discussion or investigation continued in another issue:
Inconsistency of Type of the operator
tc39/proposal-pipeline-operator#227

However, @tabatkins appeared and commented:

tc39/proposal-pipeline-operator#227 (comment)

My closing of your previous thread is not an invitation to move the topic into another thread, @stken2050. I have marked this comment as off-topic; additional attempts to derail threads will be summarily deleted, and further CoC enforcement action may be pursued if you can't contribute productively.

This is pretty unreasonable threatening since I and other 2 or 3 members simply discussing the topic - Does the current proposal override the Grouping operator ( ) with Hack |> ?

Here's my last comment, please investigate, I have discussed pure-math structure:

tc39/proposal-pipeline-operator#227 (comment)

Then hiding around many comments at the same time

I firmly believe he is against code of conduct of the moderator and abuses his power shutting down the significant discussion is against the interest of community.

We feel @tabatkins is so impulsive, and the transparency and healthy environment to productive discussion has been lost.

How to take notes in a TC39 meeting

@rwaldron has developed great note-taking practices at TC39 over the years, but they are not always apparent to new meeting attendees who volunteer to take notes. @kosamari volunteered to work with him to document best practices. Thank you both!