Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughFront-matter Changes
Sequence Diagram(s)mermaid Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
🚀 Docs preview deployed |
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
docs/020-governance-and-policies/program-lead-policy.md (1)
25-30: Add an explicit public decision step.This section says the process should be transparent, but the flow currently stops at the Governance Board decision. I'd add a final step requiring the outcome, rationale, and any recusals/conflicts to be posted in the public issue/discussion.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/020-governance-and-policies/program-lead-policy.md` around lines 25 - 30, Add a final public decision step to the selection process: after "Selecting the candidate through the Governance Board's decision" require that the Board posts the outcome, the decision rationale, and any recusals or conflicts of interest to the original public issue/discussion; update the numbered list in the selection process to include this explicit publication step so the full flow is transparent and documented.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/020-governance-and-policies/program-lead-policy.md`:
- Line 10: The bold markup on the sentence in program-lead-policy.md is opened
with ** but not closed; fix it by either removing the leading ** or by wrapping
the full sentence with ** at both start and end so the emphasis is balanced
(i.e., change "** Volunteer roles and maintainership are not governed by this
policy." to either "Volunteer roles and maintainership are not governed by this
policy." or "**Volunteer roles and maintainership are not governed by this
policy.**").
- Line 12: The markdown heading "## Appointment" contains two spaces after the
hashes which triggers MD019; update the heading to a single space ("##
Appointment") so the heading conforms to markdownlint rules, ensuring the change
targets the "## Appointment" line in program-lead-policy.md and preserves the
heading text.
- Line 99: There is a stray zero-width/invisible character on the empty line
within the Program Lead Policy markdown (a hidden character causing noisy
diffs); open the paragraph around that blank line in program-lead-policy.md,
delete and retype the empty line (or use your editor's "show invisibles"
feature) to remove the zero-width character so the file contains a true empty
line with no hidden characters.
---
Nitpick comments:
In `@docs/020-governance-and-policies/program-lead-policy.md`:
- Around line 25-30: Add a final public decision step to the selection process:
after "Selecting the candidate through the Governance Board's decision" require
that the Board posts the outcome, the decision rationale, and any recusals or
conflicts of interest to the original public issue/discussion; update the
numbered list in the selection process to include this explicit publication step
so the full flow is transparent and documented.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 501b6044-6186-4c6c-ada9-0c3802962781
📒 Files selected for processing (4)
docs/010-contribution-guidelines/AMBASSADOR_PROGRAM.mddocs/010-contribution-guidelines/BOUNTY_PROGRAM.mddocs/010-contribution-guidelines/recognizing-contributors-and-appointing-new-maintainers.mddocs/020-governance-and-policies/program-lead-policy.md
It is still not specified anywhere in AsyncAPI docs what 'one year' is. Is it a calendar year or a fiscal year? If it's a fiscal year, when does a fiscal year start and end in AsyncAPI? This definition of 'one year' is also tightly tied to the budgeting process, which is still not clearly defined in AsyncAPI either, leading to disruptions in programs' budgeting (the Bounty Program missed funding for January and February 2026 because of an ambiguous budgeting process). The rounds in the Bounty Program are not tied to either definition of 'one year' also. Instead, they are tied to the time of logical completion due to the complexity of software development in complex systems. As of March 11th, 2026, the round The absence of the possibility to prognose ~5% of the Bounty Program is exactly why the Bounty Program Coordinator's compensation is tied to results and not to any fixed calendar/fiscal period or given as a separate line in the AsyncAPI budget, and it would be best to leave it that way. The evaluation process proposed in the PR employs optimistic approach where the previous Program Lead is evaluated positively within several minutes during the Board meeting and simply continues to perform their duties; while the pessimistic scenario suggests having at least a bench of candidates ready to take over immediately in case of a negative evaluation of the previous Lead, to maintain the uninterrupted continuity of the process. In its current form, the proposed evaluation process factually mandates an immediate halt of all current and future activities on a program in case of a negative evaluation of the previous Program Lead, leading to the loss of at least two months until the election and training of a new Program Lead due to the inertia of moving mechanisms that cannot be stopped and started immediately. Areas that need to be addressed:
|
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (1)
docs/020-governance-and-policies/program-lead-policy.md (1)
81-81: Small wording cleanup: replace “prior to” with “before”.Line 81 reads cleaner with “before” and keeps the same meaning.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/020-governance-and-policies/program-lead-policy.md` at line 81, Replace the phrase "prior to" with "before" in the sentence "The Governance Board conducts regular and annual performance evaluations prior to any renewal decision." so it reads "The Governance Board conducts regular and annual performance evaluations before any renewal decision."
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/020-governance-and-policies/program-lead-policy.md`:
- Line 22: Replace the ambiguous phrase "Tenures are typically for **one year**"
with a precise definition: state whether "one year" means a calendar year (Jan
1–Dec 31) or a fiscal year (define fiscal start/end), and specify the
anchor/renewal boundary date (for example "tenure runs from July 1 to June 30"
or "tenure runs from the date of appointment to the same date next calendar
year"); update any related references in the same section heading or policy
notes so renewal and budget processes use this exact period definition.
- Around line 72-83: Add a provisional-evaluation mechanism to the "Annual
Report" and "Evaluation" sections: specify that if final annual data is not
available by the regular evaluation date, the Governance Board will perform a
provisional evaluation using available data and set a firm deadline (e.g., 60
days) for submission of final data; if final data is not provided by that
deadline, the provisional evaluation stands for the renewal decision or a
conditional renewal with defined remediation steps. Update the "Annual Report"
heading (Tenure/Annual Report) to require a submission deadline relative to the
evaluation date and amend the "Evaluation" section to describe the
provisional-evaluation process, the fixed deadline for final data, and the
fallback outcomes (provisional evaluation, conditional renewal, or deferral).
- Around line 91-98: Under the "## Renewal" section, when the Board decides to
"Conclude the engagement", add a required continuity clause that mandates a
documented transition plan (including timelines, interim responsibilities,
knowledge transfer steps, and a named point of contact) to be approved by the
Board before the conclusion date; update the bullet "Conclude the engagement" to
reference this requirement and require the decision and the transition plan to
be communicated to stakeholders.
- Around line 15-23: Update the "Each role must have" section to specify the
budget submission and approval timeline and where approvals are recorded:
require the proposed budget to be submitted at least X weeks prior to the annual
tenure review (or at role creation), require formal approval by the Finance
Director and Program Lead Council (or named governance body), and record
approvals in the Governance Approvals Log (or Program Budget Register) with date
and approver signature; reference the existing "Each role must have" list and
the sentence "Tenures are typically for one year" when adding the
timing/approval path language.
---
Nitpick comments:
In `@docs/020-governance-and-policies/program-lead-policy.md`:
- Line 81: Replace the phrase "prior to" with "before" in the sentence "The
Governance Board conducts regular and annual performance evaluations prior to
any renewal decision." so it reads "The Governance Board conducts regular and
annual performance evaluations before any renewal decision."
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 115654fe-2d56-45b5-b338-e5f809526140
📒 Files selected for processing (1)
docs/020-governance-and-policies/program-lead-policy.md
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (2)
docs/020-governance-and-policies/program-lead-policy.md (2)
16-22:⚠️ Potential issue | 🟠 MajorDefine the budget approval process and timing.
The "Approved budget" requirement lacks critical operational details that have already caused funding gaps (per PR comments, the Bounty Program missed funding for January–February 2026 due to ambiguous budgeting). The policy must specify:
- When the budget must be submitted (e.g., "at least 8 weeks before tenure start")
- Who approves it (e.g., "Governance Board")
- Where the approval is documented (e.g., "in the Governance Board decision record")
- What the budget must include (e.g., "funding period dates, amount, responsible budget owner")
Without these details, programs risk funding interruptions between the tenure decision and actual fund availability.
📋 Suggested addition to address budget process
Each role must have: - A clearly defined scope - Expected deliverables - Defined duration - Approved budget + +The budget proposal must be submitted to the Governance Board at least eight weeks before the tenure start date and must include: +- Funding period dates +- Total amount requested +- Breakdown by category (if applicable) +- Responsible budget owner + +Budget approval must be completed before the tenure begins and documented in the Governance Board decision record.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/020-governance-and-policies/program-lead-policy.md` around lines 16 - 22, Update the "Approved budget" bullet in program-lead-policy.md to specify the approval process: state when the budget must be submitted (e.g., "at least 8 weeks before tenure start"), who approves it (e.g., "Governance Board"), where approval is recorded (e.g., "Governance Board decision record"), and what the budget must include (e.g., "funding period dates, requested amount, line-item breakdown, and responsible budget owner"); reference the "Approved budget" line so editors can replace the vague bullet with these explicit fields and timeframes to prevent funding gaps.
97-107:⚠️ Potential issue | 🟠 MajorAdd transition and continuity requirements for engagement conclusions.
Line 104's "Conclude the engagement" option lacks transition planning, creating operational risk. Per PR comments, a negative evaluation without continuity planning would cause program activities to halt immediately, with an estimated 2+ month gap for selecting and onboarding a replacement.
The policy must require:
- Transition timeline (notice period for wind-down or handover)
- Interim ownership (who manages program activities during transition)
- Knowledge transfer (documentation, access, stakeholder handoff)
- Successor path (immediate re-opening of role, or program sunset plan)
Without these, the "Conclude" decision creates an unmanaged gap in program operations.
🔄 Suggested addition for transition planning
Following this, the Governance Board may decide to: - Renew the appointment for another term. - Renew with revised scope or expectations. - Conclude the engagement All decisions must be documented and communicated transparently. + +If the engagement is concluded, the Governance Board must approve and publish a transition plan that includes: +- Transition timeline and final work-completion date +- Interim program owner during the transition period +- Knowledge transfer requirements (documentation, access credentials, stakeholder contacts) +- Successor selection timeline or program closure plan + +The transition plan must be communicated to stakeholders at least 30 days before the engagement end date.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/020-governance-and-policies/program-lead-policy.md` around lines 97 - 107, Update the "Evaluation and Renewal" section to expand the "Conclude the engagement" outcome into a required transition plan: specify a transition timeline/notice period for wind-down or handover, designate interim ownership to manage program activities during the transition, mandate knowledge transfer activities (documentation, access handoffs, stakeholder briefings), and define a successor path (immediate role re-opening or a program sunset plan); add these as required sub-bullets under the "Conclude the engagement" option so reviewers can see "transition timeline", "interim ownership", "knowledge transfer", and "successor path" explicitly called out and enforced.
🧹 Nitpick comments (1)
docs/020-governance-and-policies/program-lead-policy.md (1)
87-87: Consider the interaction between regular reviews and renewal reviews.Line 87 establishes reviews every six months, and lines 98-99 add renewal reviews starting three months before tenure end, with final reviews one to two months before end.
For a typical twelve-month tenure, this creates:
- Month 6: Regular performance review
- Month 9: Renewal review begins
- Months 10-11: Final performance review
This might be intentionally dense to support renewal decisions, but it could also create review fatigue or confusion about which review serves which purpose. Consider clarifying the distinct objectives of regular vs. renewal reviews, or consolidating the month-6 regular review with the month-9 renewal kickoff for twelve-month tenures.
Also applies to: 98-99
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/020-governance-and-policies/program-lead-policy.md` at line 87, Clarify the interaction between regular six-month reviews and renewal reviews by explicitly stating their distinct objectives and/or consolidating timing to avoid overlap: update the sentence that schedules "every first week of each sixth month" and the renewal-review sentences that start "three months before tenure end" and "one to two months before end" so they either (a) define the regular review as a performance check (not renewal-related) and define renewal reviews as a separate, decision-focused process with specific triggers, or (b) merge or shift the regular six-month review timing for 12-month tenures so the midterm review also serves as the renewal kickoff; refer to the phrases "first week of each sixth month", "renewal reviews starting three months before tenure end", and "final reviews one to two months before end" when making the edits.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/020-governance-and-policies/program-lead-policy.md`:
- Around line 78-96: The policy lacks a provisional evaluation mechanism when
complete annual data isn't available at the scheduled review; add a paragraph
after the "Annual Report" section requiring the lead to submit all available
metrics and a written explanation of pending items and give the Governance Board
two options: (1) issue a provisional evaluation based on available evidence with
a required final data submission deadline no later than 60 days after tenure
end, or (2) defer the renewal decision until final data is available while
granting an interim extension not exceeding 90 days; reference the "Annual
Report" and "Review Process" headings so reviewers can locate and integrate this
new provisional-evaluation clause.
- Line 87: The phrase "every first week of each sixth month" is ambiguous;
replace it in program-lead-policy.md with a clear statement indicating the
intended cadence—either "semi-annually (every six months from the start of
tenure)" if reviews should occur every six months, or "in the first week of June
and the first week of December" if calendar months are intended—by updating the
sentence that currently contains "every first week of each sixth month" so it
reads the chosen clarified wording.
- Line 23: The phrase "Tenures are typically for **twelve calendar months**" is
ambiguous about alignment; update that sentence to explicitly state whether
tenures are calendar-year aligned (e.g., "Tenures run January 1 – December 31")
or rolling from appointment date (e.g., "Tenures run for twelve months from the
appointment date"); also add a one-sentence note about renewal timing and how
this affects budgeting/reporting (for example, when renewals are considered and
which fiscal/reporting cycle they fall into) so readers know start/end semantics
and the impact on budget cycles.
---
Duplicate comments:
In `@docs/020-governance-and-policies/program-lead-policy.md`:
- Around line 16-22: Update the "Approved budget" bullet in
program-lead-policy.md to specify the approval process: state when the budget
must be submitted (e.g., "at least 8 weeks before tenure start"), who approves
it (e.g., "Governance Board"), where approval is recorded (e.g., "Governance
Board decision record"), and what the budget must include (e.g., "funding period
dates, requested amount, line-item breakdown, and responsible budget owner");
reference the "Approved budget" line so editors can replace the vague bullet
with these explicit fields and timeframes to prevent funding gaps.
- Around line 97-107: Update the "Evaluation and Renewal" section to expand the
"Conclude the engagement" outcome into a required transition plan: specify a
transition timeline/notice period for wind-down or handover, designate interim
ownership to manage program activities during the transition, mandate knowledge
transfer activities (documentation, access handoffs, stakeholder briefings), and
define a successor path (immediate role re-opening or a program sunset plan);
add these as required sub-bullets under the "Conclude the engagement" option so
reviewers can see "transition timeline", "interim ownership", "knowledge
transfer", and "successor path" explicitly called out and enforced.
---
Nitpick comments:
In `@docs/020-governance-and-policies/program-lead-policy.md`:
- Line 87: Clarify the interaction between regular six-month reviews and renewal
reviews by explicitly stating their distinct objectives and/or consolidating
timing to avoid overlap: update the sentence that schedules "every first week of
each sixth month" and the renewal-review sentences that start "three months
before tenure end" and "one to two months before end" so they either (a) define
the regular review as a performance check (not renewal-related) and define
renewal reviews as a separate, decision-focused process with specific triggers,
or (b) merge or shift the regular six-month review timing for 12-month tenures
so the midterm review also serves as the renewal kickoff; refer to the phrases
"first week of each sixth month", "renewal reviews starting three months before
tenure end", and "final reviews one to two months before end" when making the
edits.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: ff11cd79-3a99-4e63-b8d6-e6fd026b07b8
📒 Files selected for processing (1)
docs/020-governance-and-policies/program-lead-policy.md
|
|
|
Hi Ash, thanks for the feedback. To clarify, this policy is mainly meant to establish a clear, consistent framework for governance and performance evaluation for Program Leads. Some elements, such as budget cycles, funding availability, and compensation structures, are closely linked to sponsorship and overall financial planning, so this will make more sense when a separate budget document is available/written. |
|
The evaluation process will surely need to be edited/amended once a clear budgetary process is adopted to ensure alignment. I consider the model with multiple reviews throughout the budgetary year - described in my comments at:
@fmvilas and @hguerrero agreed with multiple reviews throughout the budgetary year in:
Therefore, my sole stipulation is that the AsyncAPI Budget for the next year be TSC-approved before November fifteenth to avoid funding gaps for ongoing Programs (for example, the Bounty Program activities for the next year begin in the first half of December) and for result-based Program Leads (their expected results are known in advance, allowing compensation to be committed at the time of TSC budget approval). Additional reviews throughout the budgetary year will reduce funding-gap risks for time-based Program Leads down to zero. |



This PR outlines the process in which the GB takes when it comes to the work of paid program leasd, selections and evaluations.
Summary by CodeRabbit