Expand `in-place` tags page
Not sure if this is the best way since the file name is quite long.
@Rageking8 : Thanks for your contribution! The author(s) have been notified to review your proposed change.
Learn Build status updates of commit e2e0da6:
:warning: Validation status: warnings
| File | Status | Preview URL | Details |
|---|---|---|---|
| docs/standard-library/optional-class.md | :warning:Warning | Details | |
| docs/standard-library/in-place-t-struct.md | :white_check_mark:Succeeded | n/a (file deleted or renamed) | |
| docs/standard-library/in-place-t-struct-in-place-type-t-struct-in-place-index-t-struct.md | :white_check_mark:Succeeded | ||
| docs/standard-library/utility.md | :white_check_mark:Succeeded |
docs/standard-library/optional-class.md
- Line 14, Column 43: [Warning: file-not-found - See documentation]
Invalid file link: 'in-place-t-struct.md'.
For more details, please refer to the build report.
Note: Your PR may contain errors or warnings or suggestions unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:
- Try searching the learn.microsoft.com contributor guides
- Post your question in the Learn support channel
Learn Build status updates of commit d2783ec:
:white_check_mark: Validation status: passed
| File | Status | Preview URL | Details |
|---|---|---|---|
| docs/standard-library/in-place-t-struct.md | :white_check_mark:Succeeded | n/a (file deleted or renamed) | |
| docs/standard-library/in-place-t-struct-in-place-type-t-struct-in-place-index-t-struct.md | :white_check_mark:Succeeded | ||
| docs/standard-library/optional-class.md | :white_check_mark:Succeeded | ||
| docs/standard-library/utility.md | :white_check_mark:Succeeded |
For more details, please refer to the build report.
For any questions, please:
- Try searching the learn.microsoft.com contributor guides
- Post your question in the Learn support channel
PRMerger Results
| Issue | Description |
|---|---|
| Added File(s) | This PR contains added files. New files require human review. |
| Deleted File(s) | This PR deletes Markdown or YAML files owned by another author, or json file(s). The pull request must contain a comment from the pull request author confirming that all the file deletions are intentional before the pull request can be merged. |
| File Change Percent | This PR contains file(s) with more than 30% file change. |
@TylerMSFT
- Can you review this PR?
- IMPORTANT: When this content is ready to merge, you must add
#sign-offin a comment or the approval may get overlooked.
Note: new articles must be submitted via the private repo so if you accept this, you'll need to move the commits (or we can help). Also, an article deletion requires an entry in the redirection.json (again in the private repo so we can verify that it works)
#label:"aq-pr-triaged" @MicrosoftDocs/public-repo-pr-review-team
@TylerMSFT Would having a separate page for each of the 3 types (in_place_t, in_place_type_t and in_place_index_t) be viable?
@TylerMSFT Would having a separate page for each of the 3 types (
in_place_t,in_place_type_tandin_place_index_t) be viable?
Hi @Rageking8: it's viable, it's just a question of which tradeoff(s) you want to accept. Writing an article is only the first part, and sometimes the smallest part, of the work that an article will require over its lifetime. There's maintenance, metrics, portfolio weeding, etc. Having lots of tiny files makes that harder, adds to the table of contents which might then make it harder to navigate. When they are related, it makes the reader do more work to pull together the overall picture because they have to click around to different articles. It's a subjective call in the end. I don't see a compelling reason to make them separate topics in this case, but there may be another point of view worth considering. Why would you like to break them up?