[docs] Update governance process links (#32995)

Signed-off-by: esmeetu <jasonailu87@gmail.com>
Signed-off-by: Roger Wang <hey@rogerw.io>
Co-authored-by: Roger Wang <hey@rogerw.io>

docs/governance/process.md

@@ -25,34 +25,55 @@ Maintainers form a hierarchy based on sustained, high-quality contributions and
 
 ### Core Maintainers
 
-Core Maintainers function like a project planning and decision making committee. In other convention, they might be called a Technical Steering Committee (TSC). In vLLM vocabulary, they are often known as "Project Leads". They meet weekly to coordinate roadmap priorities and allocate engineering resources. Current active leads: @WoosukKwon, @zhuohan123, @simon-mo, @youkaichao, @robertgshaw2-redhat, @tlrmchlsmth, @mgoin, @njhill, @ywang96, @houseroad, @yeqcharlotte, @ApostaC
-
-The responsibilities of the core maintainers are:
-
-* Author quarterly roadmap and responsible for each development effort.
-* Making major changes to the technical direction or scope of vLLM and vLLM projects.
-* Defining the project's release strategy.
-* Work with model providers, hardware vendors, and key users of vLLM to ensure the project is on the right track.
+Core Maintainers function like a project planning and decision making committee. In other convention, they might be called a Technical Steering Committee (TSC). In vLLM vocabulary, they are often known as "Project Leads". They meet weekly to coordinate roadmap priorities and allocate engineering resources.
+
+**Project Leads:**
+
+- Woosuk Kwon ([@WoosukKwon](https://github.com/WoosukKwon))
+- Zhuohan Li ([@zhuohan123](https://github.com/zhuohan123))
+- Simon Mo ([@simon-mo](https://github.com/simon-mo))
+- Kaichao You ([@youkaichao](https://github.com/youkaichao))
+- Robert Shaw ([@robertgshaw2-redhat](https://github.com/robertgshaw2-redhat))
+- Tyler Michael Smith ([@tlrmchlsmth](https://github.com/tlrmchlsmth))
+- Michael Goin ([@mgoin](https://github.com/mgoin))
+- Nick Hill ([@njhill](https://github.com/njhill))
+- Roger Wang ([@ywang96](https://github.com/ywang96))
+- Lu Fang ([@houseroad](https://github.com/houseroad))
+- Ye (Charlotte) Qi ([@yeqcharlotte](https://github.com/yeqcharlotte))
+- Yihua Cheng ([@ApostaC](https://github.com/ApostaC))
+
+**Responsibilities:**
+
+- Author quarterly roadmap and responsible for each development effort.
+- Making major changes to the technical direction or scope of vLLM and vLLM projects.
+- Defining the project's release strategy.
+- Work with model providers, hardware vendors, and key users of vLLM to ensure the project is on the right track.
 
 ### Lead Maintainers
 
-While Core maintainers assume the day-to-day responsibilities of the project, Lead maintainers are responsible for the overall direction and strategy of the project. A committee of @WoosukKwon, @zhuohan123, @simon-mo, @youkaichao, and @robertgshaw2-redhat currently shares this role with divided responsibilities.
+While Core maintainers assume the day-to-day responsibilities of the project, Lead maintainers are responsible for the overall direction and strategy of the project. The following committee currently shares this role with divided responsibilities:
+
+- Woosuk Kwon ([@WoosukKwon](https://github.com/WoosukKwon))
+- Zhuohan Li ([@zhuohan123](https://github.com/zhuohan123))
+- Simon Mo ([@simon-mo](https://github.com/simon-mo))
+- Kaichao You ([@youkaichao](https://github.com/youkaichao))
+- Robert Shaw ([@robertgshaw2-redhat](https://github.com/robertgshaw2-redhat))
 
-The responsibilities of the lead maintainers are:
+**Responsibilities:**
 
-* Making decisions where consensus among core maintainers cannot be reached.
-* Adopting changes to the project's technical governance.
-* Organizing the voting process for new committers.
+- Making decisions where consensus among core maintainers cannot be reached.
+- Adopting changes to the project's technical governance.
+- Organizing the voting process for new committers.
 
 ### Committers and Area Owners
 
 Committers have write access and merge rights. They typically have deep expertise in specific areas and help the community.
 
-The responsibilities of the committers are:
+**Responsibilities:**
 
-* Reviewing PRs and providing feedback.
-* Addressing issues and questions from the community.
-* Own specific areas of the codebase and development efforts: reviewing PRs, addressing issues, answering questions, improving documentation.
+- Reviewing PRs and providing feedback.
+- Addressing issues and questions from the community.
+- Own specific areas of the codebase and development efforts: reviewing PRs, addressing issues, answering questions, improving documentation.
 
 Specially, committers are almost all area owners. They author subsystems, review PRs, refactor code, monitor tests, and ensure compatibility with other areas. All area owners are committers with deep expertise in that area, but not all committers own areas.
 
@@ -68,23 +89,23 @@ Any committer can nominate candidates via our private mailing list:
 
 Committership is highly selective and merit based. The selection criteria requires:
 
-* **Area expertise**: leading design/implementation of core subsystems, material performance or reliability improvements adopted project‑wide, or accepted RFCs that shape technical direction.
-* **Sustained contributions**: high‑quality merged contributions and reviews across releases, responsiveness to feedback, and stewardship of code health.
-* **Community leadership**: mentoring contributors, triaging issues, improving docs, and elevating project standards.
+- **Area expertise**: leading design/implementation of core subsystems, material performance or reliability improvements adopted project‑wide, or accepted RFCs that shape technical direction.
+- **Sustained contributions**: high‑quality merged contributions and reviews across releases, responsiveness to feedback, and stewardship of code health.
+- **Community leadership**: mentoring contributors, triaging issues, improving docs, and elevating project standards.
 
 To further illustrate, a committer typically satisfies at least two of the following accomplishment patterns:
 
-* Author of an accepted RFC or design that materially shaped project direction
-* Measurable, widely adopted performance or reliability improvement in core paths
-* Long‑term ownership of a subsystem with demonstrable quality and stability gains
-* Significant cross‑project compatibility or ecosystem enablement work (models, hardware, tooling)
+- Author of an accepted RFC or design that materially shaped project direction
+- Measurable, widely adopted performance or reliability improvement in core paths
+- Long‑term ownership of a subsystem with demonstrable quality and stability gains
+- Significant cross‑project compatibility or ecosystem enablement work (models, hardware, tooling)
 
 While there isn't a quantitative bar, past committers have:
 
-* Submitted approximately 30+ PRs of substantial quality and scope
-* Provided high-quality reviews of approximately 10+ substantial external contributor PRs
-* Addressed multiple issues and questions from the community in issues/forums/Slack
-* Led concentrated efforts on RFCs and their implementation, or significant performance or reliability improvements adopted project‑wide
+- Submitted approximately 30+ PRs of substantial quality and scope
+- Provided high-quality reviews of approximately 10+ substantial external contributor PRs
+- Addressed multiple issues and questions from the community in issues/forums/Slack
+- Led concentrated efforts on RFCs and their implementation, or significant performance or reliability improvements adopted project‑wide
 
 ### Working Groups