Closed robrap closed 3 months ago
We are moving towards a model of maintainership of OEPs where we no longer merged if they are not agreed upon with the community as Provisional or Accepted. We are currently working to draw down the OEP issues and move OEPs to Obsolete in the coming weeks so the OEP documents are a source of truth, not a confusing mixture of "what's this?". We are going to be much more active maintainers on this repo to enforce that.
I don't think adding linting is the right solution in most cases, as OEPs should mostly describe process (like Core Contributors) or architectural changes (eg event bus, a move to TypeScript) that don't lend themselves to linting. Perhaps more targeted ADRs would be the level at which linting a particular change could be effected.
If you feel strongly against this, please reopen with some examples of where linting could have been built, how it would have helped, and describe the amount of help versus amount of effort that caused.
All good. Thanks. I do wish we have more linting to backup our decisions, but if this moved forward, we'd need a linter to catch missing linters. ;) Thanks for cleaning up these old PRs.
We've found that some OEPs like OEP-9 are proposed and agreed upon, but without anything enforcing the decision, it can sit and be ignored. Note that linting + lint-amnesty could be used to ensure that problems don't grow, even if we don't refactor everything to match some new decision.
The idea here would be to update OEP-1 and educate engineers to consider introducing linting where possible to help enforce decisions. It could provide examples or links to how-tos, etc.