chore: add toggleable retroactive grant notice to issue templates#669
Merged
rickstaa merged 1 commit intoMay 20, 2026
Merged
Conversation
Embeds a commented retroactive-grant notice in the Additional context field of both bug and feature templates. Hidden by default; team members remove the comment markers and fill in the compensation cap when an issue is retroactively compensated. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
|
@mehrdadmms is attempting to deploy a commit to the Livepeer Foundation Team on Vercel. A member of the Team first needs to authorize it. |
📝 WalkthroughWalkthroughBoth GitHub issue templates (bug report and feature request) are updated in parallel to include a prefilled retroactive grant notice. The notice is initially hidden in HTML comments, with updated descriptions guiding users to remove the markers to display it in published issues. ChangesRetroactive Grant Notice in Issue Templates
Estimated Code Review Effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (4)
.github/ISSUE_TEMPLATE/bug-report.yml (2)
119-125: ⚡ Quick winRemove duplicate link reference.
The Retroactive Grants post link appears twice: once in the introductory sentence (line 119) and again as step 1 (line 125). This redundancy could be streamlined by removing the introductory reference and keeping only the enumerated step.
♻️ Suggested simplification
- Before picking this up, read the [Retroactive Grants post](https://forum.livepeer.org/t/about-the-retroactive-grant-applications-category/3250/2?u=mehrdad) in full. Key points: + Key points:🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/ISSUE_TEMPLATE/bug-report.yml around lines 119 - 125, The duplicate Retroactive Grants link appears in the introductory sentence ("read the [Retroactive Grants post]...") and again as enumerated step 1; remove the introductory link so the single canonical reference remains as the numbered step. Edit the paragraph that begins "Before picking this up, read the [Retroactive Grants post]..." to delete the bracketed link and surrounding parenthetical URL, leaving the rest of the guidance intact, and ensure step 1 still contains the full link text "[original Retroactive Grants post]" unchanged.
111-111: ⚡ Quick winClarify that team members (not issue reporters) should remove the HTML comment markers.
The current wording "If this issue is retroactively compensated" could be interpreted as past tense or unclear about who performs the action. Consider rewording to make it explicit that team members will uncomment the notice when marking an issue as eligible for retroactive grants.
📝 Suggested rewording for clarity
- description: Add any other context about the problem here. If this issue is retroactively compensated, remove the `<!--` and `-->` markers from the block below so the notice appears in the published issue. + description: Add any other context about the problem here. (Team members: To mark this issue as eligible for retroactive compensation, edit the issue to remove the `<!--` and `-->` markers from the block below, fill in the compensation cap, and save.)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/ISSUE_TEMPLATE/bug-report.yml at line 111, Update the description string that reads "Add any other context about the problem here. If this issue is retroactively compensated, remove the `<!--` and `-->` markers from the block below so the notice appears in the published issue." to explicitly state that team members (not the issue reporter) should remove the HTML comment markers when marking an issue as eligible for retroactive grants; locate and edit the same description line (the `description:` value in the bug-report template) to a clearer phrasing such as "Add any other context about the problem here. If this issue is later marked eligible for retroactive compensation, a project team member should remove the `<!--` and `-->` markers below so the notice appears in the published issue." and save the updated template..github/ISSUE_TEMPLATE/feature-request.yml (2)
42-42: ⚡ Quick winClarify that team members (not issue reporters) should remove the HTML comment markers.
The current wording "If this issue is retroactively compensated" could be interpreted as past tense or unclear about who performs the action. Consider rewording to make it explicit that team members will uncomment the notice when marking an issue as eligible for retroactive grants.
📝 Suggested rewording for clarity
- description: Add any other context or screenshots about the feature request here. If this issue is retroactively compensated, remove the `<!--` and `-->` markers from the block below so the notice appears in the published issue. + description: Add any other context or screenshots about the feature request here. (Team members: To mark this issue as eligible for retroactive compensation, edit the issue to remove the `<!--` and `-->` markers from the block below, fill in the compensation cap, and save.)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/ISSUE_TEMPLATE/feature-request.yml at line 42, Update the description line that currently reads "If this issue is retroactively compensated, remove the `<!--` and `-->` markers..." to explicitly instruct team members/maintainers to remove the HTML comment markers when marking an issue as eligible for retroactive compensation; locate the YAML key "description" containing that sentence and replace it with a clearer phrase such as "If maintainers determine this issue is eligible for retroactive compensation, a team member should remove the `<!--` and `-->` markers from the block below so the notice appears in the published issue."
50-56: ⚡ Quick winRemove duplicate link reference.
The Retroactive Grants post link appears twice: once in the introductory sentence (line 50) and again as step 1 (line 56). This redundancy could be streamlined by removing the introductory reference and keeping only the enumerated step.
♻️ Suggested simplification
- Before picking this up, read the [Retroactive Grants post](https://forum.livepeer.org/t/about-the-retroactive-grant-applications-category/3250/2?u=mehrdad) in full. Key points: + Key points:🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/ISSUE_TEMPLATE/feature-request.yml around lines 50 - 56, Remove the duplicate Retroactive Grants link in the introductory sentence and keep only the enumerated reference under the "Required steps before investing more time:" section (specifically the "1. Read the [original Retroactive Grants post]" step); edit the introductory paragraph to remove the parenthetical link and slightly reword if needed to preserve context without repeating the same URL.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In @.github/ISSUE_TEMPLATE/bug-report.yml:
- Around line 119-125: The duplicate Retroactive Grants link appears in the
introductory sentence ("read the [Retroactive Grants post]...") and again as
enumerated step 1; remove the introductory link so the single canonical
reference remains as the numbered step. Edit the paragraph that begins "Before
picking this up, read the [Retroactive Grants post]..." to delete the bracketed
link and surrounding parenthetical URL, leaving the rest of the guidance intact,
and ensure step 1 still contains the full link text "[original Retroactive
Grants post]" unchanged.
- Line 111: Update the description string that reads "Add any other context
about the problem here. If this issue is retroactively compensated, remove the
`<!--` and `-->` markers from the block below so the notice appears in the
published issue." to explicitly state that team members (not the issue reporter)
should remove the HTML comment markers when marking an issue as eligible for
retroactive grants; locate and edit the same description line (the
`description:` value in the bug-report template) to a clearer phrasing such as
"Add any other context about the problem here. If this issue is later marked
eligible for retroactive compensation, a project team member should remove the
`<!--` and `-->` markers below so the notice appears in the published issue."
and save the updated template.
In @.github/ISSUE_TEMPLATE/feature-request.yml:
- Line 42: Update the description line that currently reads "If this issue is
retroactively compensated, remove the `<!--` and `-->` markers..." to explicitly
instruct team members/maintainers to remove the HTML comment markers when
marking an issue as eligible for retroactive compensation; locate the YAML key
"description" containing that sentence and replace it with a clearer phrase such
as "If maintainers determine this issue is eligible for retroactive
compensation, a team member should remove the `<!--` and `-->` markers from the
block below so the notice appears in the published issue."
- Around line 50-56: Remove the duplicate Retroactive Grants link in the
introductory sentence and keep only the enumerated reference under the "Required
steps before investing more time:" section (specifically the "1. Read the
[original Retroactive Grants post]" step); edit the introductory paragraph to
remove the parenthetical link and slightly reword if needed to preserve context
without repeating the same URL.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: ee05b728-82c5-4b19-a3f1-59a5ab076e47
📒 Files selected for processing (2)
.github/ISSUE_TEMPLATE/bug-report.yml.github/ISSUE_TEMPLATE/feature-request.yml
github-project-automation
Bot
moved this from Triage
to Ready to Merge
in Engineering Roadmap
github-project-automation
Bot
moved this from Ready to Merge
to Done
in Engineering Roadmap
1 task
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds a hidden-by-default retroactive grant notice to both the Bug Report and Feature Request issue templates. The notice is embedded in the existing Additional context field as an HTML-commented block, so:
Additional contextheading is the normal expected one).<!--and-->markers and fills in the compensation cap before submitting. The full notice then renders for anyone picking up the work.Why
Some issues we open are eligible for retroactive compensation. Contributors who pick those up need to understand up front that this isn't pay-for-delivery: payment depends on demonstrated community adoption and proof points, with specific required steps (public discussion, named beneficiaries, attestation) that must be completed before applying. Linking to the Retroactive Grants forum post and surfacing the cap in the issue itself avoids surprises later.
How it works
value:of theAdditional contexttextarea on both templates, wrapped in<!-- ... -->.> [!IMPORTANT]callout at the top of the notice holds the compensation cap with a**[FILL IN AMOUNT]**placeholder — clearly visible so it can't be forgotten when activating the notice.description:of the field explains the uncomment-to-activate flow to whoever is filling out the form.Test plan
🤖 Generated with Claude Code
Summary by CodeRabbit