Project: Update code owners (Parser modules, RichText component)

[aduth]

This pull request seeks to make a few additions to the code owners file:

• Add @dmsnell as code owner of parser packages (block-serialization-spec-parser, block-serialization-default-parser)
• Add @aduth and @iseulde as code owners of RichText component (see Project: Update code owners (Parser modules, RichText component) #13820 (comment))

The latter of these is interesting to implement. Since at most one code owner match can be made in the CODEOWNERS file, it's necessary to duplicate the entries from the /packages/editor "fallback". I think it may be more something to consider more often to include ownership over more granular paths within a package (e.g. specific editor components, or specific blocks), but hand-crafting these is potentially error-prone. It may be worth considering some automation of CODEOWNERS being directory-specific, and aggregated up through ancestry to the top-level directory (e.g. combine packages/editor/src/components/rich-text/CODEOWNERS, packages/editor/CODEOWNERS to generate the root CODEOWNERS file)

[nerrad]

It may be worth considering some automation of CODEOWNERS being directory-specific, and aggregated up through ancestry to the top-level directory (e.g. combine packages/editor/src/components/rich-text/CODEOWNERS, packages/editor/CODEOWNERS to generate the root CODEOWNERS file)

I like how this idea allows for making things really granular. The downside however, is the maintenance overhead is greater for remembering what file people have their "ownership" applied in. This maybe could be mitigated by any automation adding a comment block listing the path the ownership was retrieved from.

[aduth]

I discovered the RichText entry had already been added in #13734, under the "Rich Text" categorized heading (rather than as a sibling following the entry for /packages/editor).

On this point, I commented at #13734 (comment) and #13734 (comment) with some concerns about how we currently categorize things:

I think it could speak to the difficulty in maintaining this file when the entries are categorized the way they are (vs. a file listing) since I was inclined to add it after the existing /packages/editor entry.

Another issue we'll encounter with organizing file paths into categories is that order has an impact for priority, and it'll be hard to maintain both prioritization while keeping things organized within categories.

[ellatrix]

I'm fine with moving the line to wherever you'd like. :)

[gziolo]

Since we discuss some changes. I would also love we create a new section where people interested in reviewing *.scss files could opt in. In many cases I got notifications about such changes and I would be fine skipping them as usually, they require some design feedback anyways.

[gziolo]

Fine as is with @dmsnell added :)

[aduth]

I would also love we create a new section where people interested in reviewing *.scss files could opt in. In many cases I got notifications about such changes and I would be fine skipping them as usually, they require some design feedback anyways.

Is it the sort of thing where we adopt what we did with native files, assigning them to @ghost until someone chooses to take ownership?

[gziolo]

Yes, I think it would be good for start. I’ll open PR today. 👍

[gziolo]

Opened #13854 as discussed.