On Organizing Proposals and Lexicon

[verdverm]

Ideas:

1. 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.

2. 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

• currently, conversations become split between the discussion and pull request. We could start with a discussion, move to PR for the proposal, and then a separate PR for the implementation. This is a pretty standard workflow
• changes are sometimes made in follow on comments, other times edits to the original post. This becomes confusing and inconsistent
• when in an issue / discussion, they become lost to time and/or difficult to find. In VCS it is easy to see them all and their history

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

[steveklabnik]

I really like how TC39 does this: https://github.com/tc39/proposals

It's similar to what you've suggested in ways.

[essential-randomness]

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.