More elaboration on normative definition

[jasonwilliams]

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

[robpalme]

I think this is helpful - especially to convey that regular proposals are also normative by this definition, even though we rarely refer to them that way explicitly.