Create annual-activities.md

Author: divya-mohan0209

sig-docs/annual-activities.md

@@ -0,0 +1,84 @@
+# List of annual activities to be performed by SIG Docs leadership
+
+This document lists and details the activities to be performed annually by [SIG Docs leadership](./sig-docs/README.md#leadership)
+
+The recommended timeline for these activities is usually November - January due to lower levels of activity.
+
+## Prune OWNERS_ALIASES under k/website
+
+At the end of each year, leadership needs to ensure that folks listed in the [OWNERS_ALIASES file](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES) 
+are willing to continue contributing.
+
+This can be done by using the [maintainers tool](https://github.com/kubernetes-sigs/maintainers) which helps parse the file for 
+activity levels of those listed from GitHub and [devstats](https://k8s.devstats.cncf.io).
+
+### Steps
+
+- Set up the [maintainers tool](https://github.com/kubernetes-sigs/maintainers) along with its prerequisites locally by following the instructions.
+- Clone the [k/website](https://github.com/kubernetes/website) repository on your machine.
+- Create a new branch locally. This is required since there are nested OWNERS_ALIASES files within the repository.
+- Switch to the newly created branch and delete all nested OWNERS_ALIASES files. Retain the OWNERS_ALIASES file at the top of the repository root only.
+Without this, the maintainers tool will not produce the required output.
+- Run the maintainers tool against this new copy of the website repo locally.
+  - Tip: While executing the command, ensure you exclude the following folks by using the `--exclude` flag:
+      - Security Response Committee members,
+      - Release engineering approvers and reviewers,
+      - Co-chairs and tech leads of SIG Docs, SIG Release, and SIG Security
+- You'll get a list of SIG Docs approvers/reviewers with no contributions and with low reviews/approvals.
+- Submit a separate PR each for the list with no contributions and with low reviews/approvals and seek feedback. The timeframe for this activity should be ~2 weeks per PR.
+  - Tip: The lists will likely be long. It'd be easier if you raise the second one after the first PR is merged.
+  - Example PRs:
+    - https://github.com/kubernetes/website/pull/38719
+    - https://github.com/kubernetes/website/pull/38853
+- Socialize the activity within the [SIG Docs google group](https://groups.google.com/u/1/g/kubernetes-sig-docs) and the [#sig-docs slack channel](https://kubernetes.slack.com/messages/sig-docs). Add it as an item to the upcoming meeting agenda.
+- Work with all stakeholders to get the PRs merged, ideally before the end of the year.
+- In case of issues with merging due to conflicts with localization initiatives, such as lack of minimum number of approvers/reviewers,
+seek consensus with the localization subproject and wider SIG Docs community in the next year.
+  
+## Create new PR Wrangler schedule
+
+Preferably, before the second week of December, [the PR Wrangler schedule](https://github.com/kubernetes/website/wiki/PR-Wranglers) for the upcoming year needs to be released. 
+
+This needs to be done along with or after the pruning of the OWNERS_ALIASES file detailed above.
+
+SIG co-chairs, tech leads, and localization subproject leads have access to edit the [k/website wiki](https://github.com/kubernetes/website/wiki/).
+
+### Steps:
+
+- Create a new page under [PR Wranglers](https://github.com/kubernetes/website/wiki/PR-Wranglers) for the upcoming year.
+- Copy the table from previous year's page and amend the dates for the upcoming year.
+- Ensure approvers/reviewers pruned per the cleanup detailed above aren't reflecting in the list.
+- Socialize the new list on the [#sig-docs slack channel](https://kubernetes.slack.com/messages/sig-docs).
+
+## Create new Issue Wrangler schedule
+
+Preferably, before the second week of December, [the Issue Wrangler schedule](https://github.com/kubernetes/website/wiki/Issue-Wranglers) for the upcoming year needs to be released. 
+
+This needs to be done along with or after the pruning of the OWNERS_ALIASES file detailed above.
+
+SIG co-chairs, tech leads, and localization subproject leads have access to edit the [k/website wiki](https://github.com/kubernetes/website/wiki/).
+
+### Steps:
+
+- Send out a call for nominations for the Issue Wrangler role during the last quarter of the year on the the [SIG Docs google group](https://groups.google.com/u/1/g/kubernetes-sig-docs). 
+- Create a new page under [Issue Wranglers](https://github.com/kubernetes/website/wiki/Issue-Wranglers) for the upcoming year.
+- Copy the table from previous year's page and amend the dates for the upcoming year.
+- Add nominations received to the table.
+  - Tip: Aim at populating data for Q1 of the upcoming year by December.
+- Socialize the new list on the [#sig-docs slack channel](https://kubernetes.slack.com/messages/sig-docs).
+
+## Prepare annual report
+
+SIG Docs co-chairs and tech leads are responsible for submission of annual report projecting SIG health during the first quarter of every year. 
+
+The annual reports for previous years can be viewed [here](https://github.com/kubernetes/community/tree/master/sig-docs).
+
+General steps and timelines are outlined in [this document](https://github.com/kubernetes/community/blob/master/committee-steering/governance/annual-reports.md).
+
+Specific steps related to SIG Docs are outlined below.
+
+### Steps:
+
+- The [site analytics dashboard](https://datastudio.google.com/u/0/reporting/fede2672-b2fd-402a-91d2-7473bdb10f04/page/567IC) is featured as part of metrics we care about.
+  - Specifically, we highlight number of page views and top pages for the year.
+- Normally, we do not have KEPs as part of release cycles. Any work on an ongoing KEP or a subproject formalization needs to be highlighted explicitly.