Update README.md

This commit is contained in:
Andy Friesen 2024-06-18 13:20:21 -07:00 committed by GitHub
parent 70871e7516
commit f71a7c5578
Signed by: DevComp
GPG key ID: B5690EEEBB952194

View file

@ -40,6 +40,8 @@ When the initial comment period expires, the RFC can be merged if there's consen
When revisions on the RFC text that affect syntax/semantics are suggested, they need to be incorporated before a RFC is merged; a merged RFC represents a maximally accurate version of the language change that is going to be implemented.
Each RFC will be assigned a shepherd. This person will support you in getting feedback, request necessary changes, and ultimately either accept (and merge) the RFC or turn it away.
In some cases RFCs may contain conditional compatibility clauses. E.g. there are cases where a change is potentially not backwards compatible, but is believed to be substantially beneficial that it can be implemented if, in practice, the backwards compatibility implications are minimal. As a strawman example, if we wanted to introduce a non-context-specific keyword `globallycoherent`, we would be able to do so if our analysis of Luau code (based on the Roblox platform at the moment) informs us that no script in existence uses this keyword. In cases like this an RFC may need to be revised after the initial implementation attempt based on the data that we gather.
In general, RFCs can also be updated after merging to make the language of the RFC more clear, but should not change their meaning. When a new feature is built on top of an existing feature that has an RFC, a new RFC should be created instead of editing an existing RFC.