Skip to content
This repository has been archived by the owner on Jul 1, 2024. It is now read-only.

Requiring owner approval for critical-to-an-ecosystem types #248

Open
chriskrycho opened this issue Dec 2, 2020 · 2 comments
Open

Requiring owner approval for critical-to-an-ecosystem types #248

chriskrycho opened this issue Dec 2, 2020 · 2 comments

Comments

@chriskrycho
Copy link

Picking up a thread from this Discord discussion from about a month ago (!)—

Per @elibarzilay, the current bot system has a danger level and a popularity level, which combine to allow lower-popularity (non-"critical" or "popular") type definitions to be merged by any reviewer. While this makes a certain amount of sense, hinging on popularity means that type definitions which may be critical to a given audience can have changes slip through.

As the motivating example, the types for ember, @ember/*, ember-data, and @ember-data/* are critical to the experience of the entire Ember ecosystem—including JS users, courtesy of VS Code's automatic type acquisition. Ember is relatively low in popularity compared to e.g. React, but its core types still need owner review to be allowed through, because of their impact to the whole system.

For our use case, it would be helpful to be able to mark that a given set of types always requires owner approval, regardless of popularity; or to otherwise simplify the rule sets in some way. We're fairly agnostic on the details of the solution; we just don't want random well-intentioned reviewers to accidentally get code merged!

cc. @dfreeman @jamescdavis

@elibarzilay
Copy link
Contributor

cc @RyanCavanaugh, @orta.

@jpoehnelt
Copy link

This is also important for types that do not have an associated npm package and thus no popularity level.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants