Repository navigation
Conversation
There was a problem hiding this comment.
cheatsheet should go under core.
glossary and public api should go into the public_api group at the bottom
There was a problem hiding this comment.
I assume you meant "glossary and styleguide" 😃
There was a problem hiding this comment.
I think of glossary and architecture docs as part of docs-intro, similar to getting started and tutorial. I suppose glossary could be public-api, but architecture is definitely similar to other intro materials.
There was a problem hiding this comment.
I think that all three of these should go under public api as they are the most visible terminology definitions, recommendations and "style" guides.
There was a problem hiding this comment.
let's move all of these into the docs-infra group
IgorMinar
left a comment
There was a problem hiding this comment.
responding to questions...
There was a problem hiding this comment.
cheatsheet should go under core.
glossary and public api should go into the public_api group at the bottom
There was a problem hiding this comment.
let's move all of these into the docs-infra group
7027a02 to
1853700
Compare
There was a problem hiding this comment.
It would be good to have a codeowners group(s) that alexE and hans can approve, for libraries, schematics, CLI overview page.
There was a problem hiding this comment.
libraries should likely be a separate category with a separate team owning it - the owners should be some folks on the tooling team and me. @alexeagle can give you the list of tooling team ppl
There was a problem hiding this comment.
and yesk, I previously said that we should reuse ngtools group, but now I'm thinking that reviewing library docs changes requires a very specific knowledge, so a custom group would be better.
There was a problem hiding this comment.
Hmm, I think it's probably @hansl, @mgechev, @alan-agius4
|
(Note: The CI failure in |
IgorMinar
left a comment
There was a problem hiding this comment.
the rest looks good.
please resolve comments and remove all TODOs and ??? and send for merge.
There was a problem hiding this comment.
I think that all three of these should go under public api as they are the most visible terminology definitions, recommendations and "style" guides.
There was a problem hiding this comment.
libraries should likely be a separate category with a separate team owning it - the owners should be some folks on the tooling team and me. @alexeagle can give you the list of tooling team ppl
caea04a to
cb61558
Compare
|
I made all necessary changes. @IgorMinar, you need to create the fw-docs-libraries GitHub group. |
cb61558 to
3fe3661
Compare
|
I found out I can create the GitHub team myself, so I created tools-docs-libraries. |
|
merge-assistance: @IgorMinar said I can send for merge (#28597 (review)). |
|
Note: The changes aren't applying cleanly to patch, so merging it into master now, and George has agreed to create another PR against the patch branch that resolves the conflicts. |
… have owners It is useful for manually checking that all guides/examples/images have owners in `.github/CODEOWNERS`, but is not used for automatic verification (e.g. on CI) for now.
3fe3661 to
652b911
Compare
… have owners (angular#28597) It is useful for manually checking that all guides/examples/images have owners in `.github/CODEOWNERS`, but is not used for automatic verification (e.g. on CI) for now. PR Close angular#28597
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Some guides/examples/images from
aio/content/did not have owners (in.github/CODEOWNERS) and fell back to the default owners.This PR adds owners for all guides/examples/images.