Positron Intake Rotation

Positron Intake Rotation

Overview

This skill provides comprehensive guidance for handling issue intake rotation for the Positron IDE repository. Intake rotation is a weekly assignment (Monday-Friday) where team members review and respond to new issues, discussion posts, and support tickets to ensure timely responses and actionable issue tracking.

The goal is to respond to new items within approximately one business day and ensure all issues have the details required to be actionable.

🚨 CRITICAL: Manual Action Protocol

This skill assists with intake rotation but NEVER executes GitHub actions directly.

All GitHub interactions must be performed manually by the user:

• ✅ Draft responses for review before posting
• ✅ Suggest labels and categorization
• ✅ Prepare commands for user to execute
• ✅ Search and analyze issues/discussions
• ❌ NEVER post comments or responses directly
• ❌ NEVER edit issues, add labels, or change status
• ❌ NEVER close issues or create new ones
• ❌ NEVER execute gh commands that modify GitHub state

Workflow: Analyze → Recommend → Draft → User executes manually

When to Use This Skill

Use this skill when:

• Currently on intake rotation duty
• Helping another team member with intake tasks
• Learning the intake rotation process
• Reviewing backlog items without status
• Responding to GitHub discussions
• Handling customer support tickets
• Searching for duplicate or related issues

Quick Start

Essential Scripts

Four shell scripts are provided to streamline intake tasks:

1. `scripts/fetch_intake_issues.sh` - List open issues without status (the intake queue) 2. `scripts/fetch_discussions.sh` - List recent open discussions needing attention 3. `scripts/fetch_labels.sh` - Show all available repository labels for categorization 4. `scripts/search_related.sh <query>` - Search for related issues and discussions

All scripts support --json flag for programmatic use. Run scripts from the skill directory.

Essential References

Two comprehensive reference documents provide detailed workflows:

1. `references/intake_workflow.md` - Complete workflows for handling issues, discussions, and support tickets 2. `references/response_examples.md` - Response patterns and examples from experienced team members

Load these references when drafting responses or handling complex scenarios.

Core Workflow

Daily Intake Process

Follow this process each day during rotation:

1. Check for new items

• Run scripts/fetch_intake_issues.sh to see issues without status
• Run scripts/fetch_discussions.sh to see recent discussions
• Check Support Tickets in Jira

2. Review each item systematically

• Read the full description and context
• Assess completeness (are system details, reproduction steps, etc. provided?)
• Determine item type (bug, feature request, question, duplicate)

3. Search for related content

• Use scripts/search_related.sh "<keywords>" to find similar issues
• Check documentation at https://positron.posit.co/welcome.html
• Look for existing discussions on the topic

4. Recommend categorization and organization

• Run scripts/fetch_labels.sh to see available labels
• Suggest appropriate labels (area, type, priority) for user to apply
• Recommend setting status to "Triage" once organized
• Suggest adding to "Positron Backlog" project if applicable
• Prepare gh commands for user to execute manually

5. Draft response for user review

• Consult references/response_examples.md for patterns
• Draft welcoming message thanking the contributor
• Include clarifying questions if information is missing
• Suggest workarounds or links to related content when available
• Set realistic expectations about next steps
• Present draft to user for review before posting

6. Recommend follow-through actions

• Suggest tagging relevant team members if specialized knowledge is needed
• Draft duplicate closure message with reference to canonical issue
• Recommend converting discussions to issues when appropriate
• Advise continuing follow-up even after rotation ends, or explicit handoff

Using GitHub CLI

Prefer using GitHub CLI (gh) over other methods for consistency. All commands below are for the USER to execute manually.

Read-only commands (can be executed to gather information):

# View issue with all comments
gh issue view <number> --repo posit-dev/positron --comments

# Search issues
gh issue list --repo posit-dev/positron --search "<query>" --state all

# View discussion
gh api graphql -f query='...' # (see scripts for examples)

Modification commands (prepare for user, NEVER execute directly):

# Add labels - DRAFT THIS COMMAND for user to run
gh issue edit <number> --repo posit-dev/positron --add-label "area: console,Bug"

# Close as duplicate - DRAFT THIS COMMAND for user to run
gh issue close <number> --repo posit-dev/positron --comment "Closing as duplicate of #<canonical-number>"

Important: Present modification commands to the user in a code block with clear instructions to review and execute manually.

Handling Different Scenarios

Bug Reports

For bug reports, assess completeness:

Complete bug report:

• System details (Positron version, OS, commit hash)
• Clear reproduction steps
• Expected vs. actual behavior
• Error messages or screenshots

If complete: 1. Search for duplicates using scripts/search_related.sh 2. Suggest labels (area, "Bug" type) for user to apply 3. Recommend setting status to "Triage" 4. Draft response thanking reporter and acknowledging the issue

If incomplete: 1. Draft message thanking the reporter 2. Include specific questions about missing information 3. Suggest referencing the bug report template if helpful 4. Advise keeping issue open until information is provided

Refer to `references/intake_workflow.md` for detailed bug handling workflows.

Feature Requests

For feature requests: 1. Draft message thanking the user for the suggestion 2. Search for existing related feature requests 3. If duplicate, draft message linking to existing issue (user closes manually) 4. If new, suggest labels and recommend adding to backlog 5. Draft message setting realistic expectations about prioritization

Discussions

For discussions: 1. Determine discussion type (question, idea, bug report, announcement) 2. Draft appropriate response:

• Questions: Provide answer or link to docs
• Ideas: Acknowledge and link to related issues
• Bug reports: Ask user to create formal issue
• Off-topic: Politely redirect

Recommend converting discussions to issues when they contain clear, actionable bug reports or feature requests (user performs conversion manually).

Support Tickets

Support tickets require special handling:

⚠️ CRITICAL: Never mention customer names in public issues or discussions

1. Review ticket context in Jira 2. Search for related public issues 3. Draft response in Jira (not publicly) for user to post 4. Recommend creating sanitized public issue if needed 5. Suggest linking between ticket and issue

Security Issues

If an issue describes a security vulnerability: 1. Do NOT discuss details publicly 2. Draft message asking reporter to email security@posit.co 3. Recommend closing public issue with note about private reporting (user closes manually) 4. Advise alerting team privately

Response Guidelines

Tone and Style

Be welcoming: Thank contributors for their time and effort

Be clear: Use simple language, explain technical terms, provide examples

Be helpful: Offer workarounds, link to resources, provide next steps

Be realistic: Don't overpromise timelines or solutions

Be professional: Remain calm and constructive, even with frustrated reporters

Learning from Examples

To see examples from experienced team members:

# Find issues commented on by key team members
gh search issues --repo posit-dev/positron --commenter juliasilge --limit 20
gh search issues --repo posit-dev/positron --commenter jmcphers --limit 20

# View specific issue with comments
gh issue view <number> --repo posit-dev/positron --comments

Pay special attention to responses by juliasilge and jmcphers for tone and approach guidance.

Load `references/response_examples.md` for detailed response patterns and anti-patterns.

Important Reminders

Team Collaboration

Don't try to solve everything alone. Reach out to team members when:

• The issue requires specialized domain knowledge
• You're unsure how to categorize or prioritize
• The issue describes complex technical problems
• You need help understanding the user's concern

Handoff Protocol

If handling an item extends beyond your rotation week:

• Typically: Continue following up yourself to get to triage
• If not possible: Explicitly communicate handoff to next person on rotation
• Don't drop items without clear handoff

Documentation

If recurring issues or common questions emerge:

• Consider creating FAQ entries
• Suggest documentation improvements
• Note patterns for team discussion

Quick Reference Links

• Issue Intake Board - Issues without status
• Discussions - Community discussions
• Support Tickets - Customer support (Jira)
• Rotation Schedule - Google Sheet
• Documentation - Official Positron docs
• Positron Assistant - GitHub issue assistant

Workflow Summary

Daily Intake (Assistant Mode - Draft & Recommend):
1. Fetch new items (scripts/fetch_intake_issues.sh, scripts/fetch_discussions.sh)
2. Review and assess each item
3. Search for related content (scripts/search_related.sh)
4. SUGGEST labels and categorization (scripts/fetch_labels.sh)
5. DRAFT response (references/response_examples.md) for user review
6. PREPARE gh commands for user to execute
7. RECOMMEND setting status to "Triage" (user executes)
8. ADVISE on follow-through or handoff

Remember: The goal is to ASSIST the user with timely response and actionable
organization. NEVER execute GitHub modification commands directly - always
present drafts and recommendations for the user to review and execute manually.

Issue Intake Workflow

This document provides detailed workflows for handling issues, discussions, and support tickets during intake rotation.

Core Responsibilities

The person on intake rotation ensures that issues, discussions, and support tickets are not dropped or ignored. The goal is to respond within about a business day. Key responsibilities:

1. Review and organize open issues without a status - Check the Issue Intake Board 2. Respond to open discussions - Check Positron Discussions 3. Handle support tickets - Check Jira Support Board

Important: Reach out to other team members for input if it's not clear how to handle an issue.

Handoff: If handling an item bleeds into the next week, typically continue following up yourself. If that's not possible, explicitly communicate with the next person on rotation to hand it off.

Issue Handling Workflow

Step 1: Identify New Issues

Use the fetch_intake_issues.sh script or check the Issue Intake Board for open issues without a status.

Step 2: Review Issue Details

For each new issue, review:

• Title and description - Is the issue clear and actionable?
• System details - Are system details provided (Positron version, OS, etc.)?
• Reproduction steps - Can the issue be reproduced?
• Related content - Are there duplicate or related issues?

Step 3: Search for Related Content

Before responding, search for:

• Existing issues - Use search_related.sh or gh issue list --search
• Discussions - Check if similar topics have been discussed
• Documentation - Check https://positron.posit.co/welcome.html for relevant docs

Step 4: Categorize and Label

Based on the issue content: 1. Fetch available labels - Run fetch_labels.sh to see current labels 2. Apply appropriate labels:

• Area labels (e.g., area: assistant, area: console, area: data-explorer)
• Type labels (e.g., Bug, Feature, Documentation)
• Priority labels if applicable

3. Assign to project - Add to "Positron Backlog" project if applicable

Step 5: Set Status

Issues typically start with status "Triage" once they've been reviewed and organized. Other statuses may be available in the project board.

Step 6: Draft Response

When drafting responses:

• Be welcoming and professional - Thank users for reporting issues
• Ask clarifying questions if details are missing
• Provide workarounds if available
• Link to related issues or docs when relevant
• Set expectations about timeline or next steps if known

Look at past responses by key team members (especially juliasilge and jmcphers) for tone and style guidance.

Common response patterns:

• For bugs: "Thank you for reporting this. Can you provide [specific details]? In the meantime, you might try [workaround]."
• For features: "Thanks for the suggestion! This is similar to #[related-issue]. We'll consider this during planning."
• For duplicates: "Thanks for reporting! This looks like a duplicate of #[issue-number]. I'll close this in favor of that one, but feel free to add any additional context there."
• For unclear issues: "Thanks for reaching out. To help us understand this better, could you provide [specific information]?"

Step 7: Follow Through

• Tag relevant team members if their expertise is needed
• Close duplicates and reference the canonical issue
• Move to triage once the issue is organized and ready for team review

Discussion Handling Workflow

Step 1: Review New Discussions

Use fetch_discussions.sh or check Discussions for recent activity.

Step 2: Determine Discussion Type

Discussions typically fall into:

• Questions - Users seeking help or clarification
• Ideas/Feature Requests - Suggestions for new functionality
• Bug Reports - Issues that should be converted to formal issues
• Announcements/Updates - Team communications

Step 3: Respond or Redirect

• For questions: Answer directly or link to docs/related discussions
• For feature ideas: Acknowledge and indicate if similar issues exist
• For bugs: Ask the user to create a formal issue with the bug template
• For off-topic: Politely redirect to appropriate channels

Step 4: Convert to Issues When Appropriate

If a discussion describes a clear bug or feature request: 1. Ask the user to create a formal issue (preferred) 2. Or create an issue yourself and link to the discussion 3. Summarize key points in the issue description

Support Ticket Workflow

Support tickets from customers require special handling:

1. Never mention customer names in public issues or discussions 2. Review the ticket in Jira for context 3. Search for related issues that might already address the problem 4. Create a new issue if needed - Sanitize any customer-specific information 5. Update the support ticket with links to relevant issues or workarounds 6. Coordinate with support team if specialized knowledge is needed

Other Scenarios

Incomplete Bug Reports

If a bug report lacks critical information:

• Ask for specific details: system info, reproduction steps, error messages
• Use the bug report template as a guide for what's needed
• Be patient and helpful - not everyone knows what information is useful

Feature Requests

• Thank the user for the suggestion
• Search for existing feature requests
• If duplicate, link to the existing issue
• If new, apply appropriate labels and add to backlog for triage

Security Issues

If an issue describes a security vulnerability:

• Do not discuss details publicly
• Ask the reporter to email security@posit.co
• Close the public issue with a note about the private reporting process
• Alert the team privately

Spam or Abusive Content

• Report to GitHub if needed
• Lock and hide conversations if appropriate
• Escalate to team leads if necessary

Tips for Effective Intake

1. Don't try to solve everything - Your job is to organize and respond, not to fix every bug 2. It's okay to say "I don't know" - Tag subject matter experts when needed 3. Be kind and welcoming - Many reporters are new to open source 4. Use templates - Look at past responses for common patterns 5. Keep it simple - Clear, concise responses are better than long explanations 6. Document patterns - If you notice recurring issues, consider creating docs or FAQ entries

Quick Reference Links

• Issue Intake Board
• Discussions
• Support Tickets (Jira)
• Rotation Schedule (Google Sheet)
• Documentation
• Positron Assistant for GitHub

Response Examples

This document contains examples of effective responses to issues and discussions. Look for patterns in tone, structure, and helpful elements.

How to Use This Reference

When drafting responses: 1. Review examples similar to your situation 2. Note the welcoming tone and professional language 3. Observe how questions are asked clearly 4. See how workarounds and next steps are communicated 5. Adapt the patterns to your specific case

Finding More Examples

To find real examples from key team members:

# Search for issues/PRs commented on by juliasilge
gh search issues --repo posit-dev/positron --commenter juliasilge --limit 20

# Search for issues/PRs commented on by jmcphers
gh search issues --repo posit-dev/positron --commenter jmcphers --limit 20

# View a specific issue with comments
gh issue view <number> --repo posit-dev/positron --comments

Common Response Patterns

Pattern: Bug Report - Initial Response

Situation: User reports a bug with good details

Response Structure: 1. Thank them for reporting 2. Confirm you understand the issue 3. Ask any clarifying questions 4. Provide workaround if available 5. Set expectations

Example:

Thank you for reporting this! I can reproduce the issue with Copilot models not having access to certain tools like getProjectTree and executeCode.

A few questions to help us debug:
- Does this happen with all Copilot models or specific ones?
- Do you see any errors in the Developer Tools console (Help > Toggle Developer Tools)?

In the meantime, you might try using Claude Sonnet models directly, which should have full tool access.

I'll add this to our backlog for investigation.

Pattern: Bug Report - Missing Information

Situation: User reports a bug but lacks critical details

Response Structure: 1. Thank them for reporting 2. Explain what information is needed and why 3. Provide easy ways to get that information 4. Remain helpful and encouraging

Example:

Thanks for reporting this issue! To help us investigate, could you provide:

1. Your Positron version (Help > About)
2. Your operating system and version
3. Steps to reproduce the issue
4. Any error messages you see

You can get much of this info automatically by running "Help > Report Issue" in Positron.

Looking forward to getting this resolved!

Pattern: Feature Request

Situation: User suggests a new feature

Response Structure: 1. Thank them for the suggestion 2. Acknowledge the use case 3. Link to related issues if they exist 4. Set expectations about prioritization 5. Invite further discussion

Example:

Thanks for this suggestion! Better terminal integration with R workflows would definitely
be valuable.

This relates to some of our ongoing work in #<related-issue>. We're considering several
approaches for improving the terminal experience.

I've added this to our backlog for consideration. Feel free to add any additional context
about your specific use case - that helps us prioritize.

Pattern: Duplicate Issue

Situation: Issue is a duplicate of an existing one

Response Structure: 1. Thank them for reporting 2. Link to the canonical issue 3. Explain why you're closing as duplicate 4. Invite them to continue discussion on the canonical issue

Example:

Thank you for reporting this! This appears to be a duplicate of #<issue-number>, where
we're tracking the same behavior.

I'm going to close this issue in favor of that one to keep the discussion in one place.
Please feel free to add any additional details or context to #<issue-number> - every
data point helps!

Pattern: Unclear Issue

Situation: Issue is vague or unclear

Response Structure: 1. Thank them for reaching out 2. Acknowledge what you understand 3. Ask specific questions to clarify 4. Provide examples of what would be helpful

Example:

Thanks for reaching out! I want to make sure I understand the issue correctly.

When you say "the console isn't working", do you mean:
- The console doesn't start at all?
- Commands don't execute?
- Output isn't displayed?
- Something else?

Also helpful would be:
- Your Positron version (Help > About)
- Which language you're using (Python/R)
- Any error messages you see

A screenshot or screen recording would be really helpful too!

Pattern: Converting Discussion to Issue

Situation: Discussion contains a clear bug or feature request

Response Structure: 1. Acknowledge the discussion 2. Explain why it should be an issue 3. Ask them to create an issue or offer to create one 4. Summarize what should be included

Example:

This is a great discussion! It sounds like you've identified a specific bug with data frame rendering in the Variables pane.

Would you mind creating a formal issue for this? That helps us track and prioritize the fix.
Please include:
- Your system details (Positron version, OS)
- Steps to reproduce
- Expected vs actual behavior

I'll link back to this discussion from the issue so we don't lose this context.

Pattern: Support Ticket Response

Situation: Internal support ticket needs response

Response Structure: 1. Review ticket context privately 2. Search for related public issues 3. Respond in support system (not public) 4. Create sanitized public issue if needed

Internal Response:

I found a related issue at posit-dev/positron#<number> that describes the same Python
extension loading behavior.

The workaround is to disable and re-enable the Python extension after startup. We're
working on a permanent fix tracked in that issue.

I've added a note to the public issue mentioning this affects some enterprise configurations.

Anti-Patterns to Avoid

Don't: Be Dismissive

❌ "This is already documented. Please read the docs."

✅ "Thanks for asking! This is documented at [link]. Specifically, the section on [topic] should help. Let me know if you have questions after reading that!"

Don't: Promise Timelines

❌ "We'll fix this in the next release."

✅ "We've added this to our backlog. I can't promise a specific timeline, but we'll prioritize based on impact and complexity."

Don't: Blame the User

❌ "You're doing it wrong. You should..."

✅ "I see what's happening. Here's how to [correct approach]. Does that work for you?"

Don't: Leave Them Hanging

❌ [No response or closing without explanation]

✅ "I'm going to close this issue as [reason]. If you have additional concerns, please feel free to reopen or comment. Thanks!"

Response Tone Guidelines

Be welcoming: Remember that reporting issues takes time and effort. Thank contributors.

Be clear: Use simple language. Avoid jargon when possible. Explain technical terms.

Be helpful: Provide workarounds, links, and next steps. Don't just acknowledge problems.

Be realistic: Don't overpromise. It's okay to say you don't know or need to check with the team.

Be professional: Even if the reporter is frustrated, remain calm and constructive.

Using This Guide

1. Before responding: Read through relevant patterns 2. Draft your response: Adapt patterns to your specific situation 3. Review: Check tone, clarity, completeness 4. Send: Post your response 5. Follow up: Continue the conversation as needed

Remember: The goal is to make contributors feel heard and helped, while gathering the information needed to address their concerns.