Replies: 2 comments
-
I really like how TC39 does this: https://github.com/tc39/proposals It's similar to what you've suggested in ways. |
Beta Was this translation helpful? Give feedback.
-
Strong agree. We definitely need a formalized process to bring a lexicon from "proposed" to "experimental" to "accepted" (which roughly map to the categories proposed). Currently, we have at least some lexicon proposals made immediately as PRs with a lexicon defined, and that's just not a good process. It'll be hard for anyone to accept community lexicons as a good base to build on top of if they haven't gone through a real community review with stages, and given the broad name of this community we risk creating a lot of future problems if we're not careful about our process. |
Beta Was this translation helpful? Give feedback.
-
Ideas:
Proposals should be markdown documents added to a repository. This will enable them to be worked on and reviewed like any PR. A number of projects use this pattern. It could be an independent repository or a folder in the lexicon directory.
Organize lexicon into folders based on maturity (incubating, beta, stable). Helm Charts used to do this when they used a git repository for their registry. In can be an affordance to developers while we don't have a good story around versioning.
(related discussion on versioning: https://github.com/orgs/lexicon-community/discussions/30)
Other benefits to having proposals in VCS
More generally speaking, we should have a well defined process and minimum requirements to the contents of a proposal. We can draw on prior art here and provide a good template with the required sections
Beta Was this translation helpful? Give feedback.
All reactions