Servicing docs improvements (dotnet#85729)

Adding more details to our servicing documentation, particularly around the check-servicing-labels CI leg.

Co-authored-by: Juan Hoyos <19413848+hoyosjs@users.noreply.github.com>

Author: carlossanlop

.github/PULL_REQUEST_TEMPLATE/servicing_pull_request_template.md

@@ -21,3 +21,7 @@ main PR <!-- Link to PR if any that fixed this in the main branch. -->
 # Risk
 
 <!-- Please assess the risk of taking this fix. Provide details backing up your assessment. -->
+
+# Package authoring signed off?
+
+IMPORTANT: If this change touches code that ships in a NuGet package, please make certain that you have added any necessary [package authoring](../../docs/project/library-servicing.md) and gotten it explicitly reviewed.

.github/workflows/check-service-labels.yml

@@ -13,10 +13,12 @@ jobs:
   check-labels:
     runs-on: ubuntu-latest
     steps:
-    - name: Check servicing labels
+    - name: Check 'Servicing-approved' label
       run: |
+        echo "Merging permission is enabled for servicing PRs when the `Servicing-approved` label is applied."
         if [ "${{ contains(github.event.pull_request.labels.*.name, 'Servicing-approved') }}" = "true" ]; then
           exit 0
         else
+          echo "::error:: 'Servicing-approved' label not applied to the PR yet. More information: https://github.com/dotnet/runtime/blob/main/docs/project/library-servicing.md#approval-process"
           exit 1
         fi

docs/project/library-servicing.md

@@ -1,6 +1,6 @@
 # How to service a library
 
-This document provides the steps necessary after modifying a library in a servicing branch.
+This document provides the steps that need to be followed after modifying a library in a servicing branch.
 
 Servicing branches represent shipped versions of .NET, and their name is in the format `release/X.0-staging`. Examples:
 
@@ -41,5 +41,15 @@ All the servicing change must go through an approval process. You have two ways
 For both cases, you must:
 
 - Fill out the template of the PR description.
-- Add the `servicing-consider` label.
-- Bring it to the attention of the engineering lead responsible for the area, so they consider the fix for servicing.
+- Bring it to the attention of the [engineering lead responsible for the area](~/docs/area-owners.md).
+- If the fix is a product change, the area owner will:
+  - Add the `Servicing-consider` label.
+  - Ask the area owner to champion your PR in the .NET Tactics meeting to request merge approval.
+  - If the change is approved, they will replace the `Servicing-consider` label by `Servicing-approved` and sign-off the PR.
+- If the fix is a test-only or infra-only change, the area owner will:
+  - Review the PR and sign-off if they approve it.
+  - Add the `Servicing-approved` label.
+
+The area owner can then merge the PR once the CI looks good (it's either green or the failures are investigated and determined to be unrelated to the PR).
+
+**Note**: Applying the `Servicing-approved` label ensures the `check-service-labels` CI job passes, which is a mandatory requirement for merging a PR in a servicing branch.