[METADATA UPDATE][Merge by 2024-02-07] Retiring the ms.prod and ms.technology metadata attributes from the Learn platform (values moving to ms.service)

[learn-build-service-prod]

A Pull Request has been made from the Learn Platform's Metadata Management System. Please review and merge this Pull Request within 5 days. If you have any questions or concerns about the purpose of these metadata updates, please contact docs-allowlist-mgmt@microsoft.com. If you are not the correct contact for this content and repository, please notify Metadata-Management@microsoft.com.

If this Pull Request is not merged within 14 days, it will be automatically merged by our system to ensure the timeliness of the metadata update. This includes bypassing the Repository's Branch Policy, including if Review Required is enabled. Please notify Metadata-Management@microsoft.com if you have questions or concerns or would like Pull Requests for metadata updates to merge automatically in future.

Fixing#930798 Remove ms.prod = powershell. Replaced by ms.service = powershell

Summary
In Germanium, the ms.prod and ms.technology metadata attributes will be retired from the Learn platform and values will be consolidated into ms.service and ms.subservice for reporting on content by product.

• C+E Skilling Content Architecture manages internal, business-facing taxonomies that enable reporting on key metrics for content published on Microsoft Learn. Authors manually apply values from these taxonomies to populate metadata attributes.
• Two of these taxonomies are ms.prod/ms.technology and ms.service/ms.subservice. "ms.prod" and "ms.service" were distinctions carried over from legacy systems that predated the Learn platform, intended to differentiate on-prem products from cloud services.
• We plan to rename the attributes from ms.service and ms.subservice in a future semester.

Why are we making this change?

• For the business: Accuracy of reporting metadata directly impacts the accuracy of content analytics, so it's important that related taxonomies reflect the current state of the business. Most product taxonomies within Microsoft no longer distinguish between "on-prem" and "cloud service."
• For content authors: We eliminate the need to choose between two similar attributes when applying reporting metadata to content or filtering reports.
• For engineers, data scientists, and taxonomists: Simplifying and reducing underlying metadata attributes reduces the cost and complexity required to extend metadata capabilities on the platform.

How does this affect me?

• Once changes to reporting metadata are merged, dashboards and reports maintained by Skilling Insights & Intelligence will reflect new values. If you've been using ms.prod/ms.technology filters, you'll switch to ms.service/ms.subservice filters in those dashboards and reports.
• If you have custom dashboards or Kusto queries, you might need to update those as well.

Frequently Asked Questions
Why does this Pull Request appear to be made by the Repository Owner? We open Pull Requests two different ways.

• For Git Repos with a permissioned Service Account, we open the PR from our Document Build Service Account.
• For Git Repos that we either do not have Service Account permission for or the repo is in Azure Repos (ADO) we open the Pull Requests in an automated way with the PR creator as the Repo owner.

How can I revert a Pull Request that has been merged and created an unexpected issue? Whether a PR has been merged manually or automatically, you can revert it if an issue arises. See Reverting a pull request - GitHub Docs.

[learn-build-service-prod]

Learn Build status updates of commit ba4d3a6:

✅ Validation status: passed

File	Status	Preview URL	Details
dsc/includes/dsc-resources.md	✅Succeeded	View (dsc-1.1)

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

[github-actions]

Expectations

Thanks for your submission! Here's a quick note to provide you with some context for what to expect from the docs team and the process now that you've submitted a PR. Even if you've contributed to this repo before, we strongly suggest reading this information; it might have changed since you last read it.

To see our process for reviewing PRs, please read our editor's checklist and process for managing pull requests in particular. Below is a brief, high-level summary of what to expect, but our contributor guide has expanded details.

The docs team begins to review your PR if you request them to or if your PR meets these conditions:

• It is not a draft PR.
• It does not have a WIP prefix in the title.
• It passes validation and build steps.
• It does not have any merge conflicts.
• You have checked every box in the PR Checklist, indicating you have completed all required steps and marked your PR as Ready to Merge.

You can always request a review at any stage in your authoring process, the docs team is here to help! You do not need to submit a fully polished and finished draft; the docs team can help you get content ready for merge.

While reviewing your PR, the docs team may make suggestions, write comments, and ask questions. When all requirements are satisfied, the docs team marks your PR as Approved and merges it. Once your PR is merged, it is included the next time the documentation is published. For this project, the documentation is published daily at 3 p.m. Pacific Standard Time (PST).