Back to Details

positron-intake-rotation

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Positron Intake Rotation

Positron 接收轮值

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.
本技能为Positron IDE代码仓库的issue接收轮值工作提供全面指导。接收轮值是按周分配的任务（周一至周五），团队成员需要审查并回应新issue、讨论帖和支持工单，确保及时回复和可落地的issue追踪。
我们的目标是在大约1个工作日内回应新提交的内容，并确保所有issue都包含可落地处理所需的完整信息。

🚨 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
本技能仅协助完成接收轮值工作，绝对不会直接执行GitHub操作。
所有GitHub交互必须由用户手动完成：
  • ✅ 发布前草拟回复供审核
  • ✅ 建议标签和分类方式
  • ✅ 准备好供用户执行的命令
  • ✅ 搜索和分析issue/讨论
  • ❌ 绝对不要直接发布评论或回复
  • ❌ 绝对不要编辑issue、添加标签或修改状态
  • ❌ 绝对不要关闭或创建新issue
  • ❌ 绝对不要执行会修改GitHub状态的
    gh
    命令
工作流： 分析 → 给出建议 → 草拟内容 → 用户手动执行

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
符合以下场景时可使用本技能：
  • 正处于接收轮值期间
  • 协助其他团队成员完成接收任务
  • 学习接收轮值流程
  • 审查无状态的待处理积压项
  • 回应GitHub讨论
  • 处理客户支持工单
  • 搜索重复或相关的issue

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.
我们提供4个shell脚本以简化接收任务：
  1. scripts/fetch_intake_issues.sh
     - 列出无状态的开放issue（接收队列）
  2. scripts/fetch_discussions.sh
     - 列出需要关注的近期开放讨论
  3. scripts/fetch_labels.sh
     - 展示仓库所有可用的分类标签
  4. scripts/search_related.sh <query>
     - 搜索相关的issue和讨论
所有脚本都支持
--json
参数供程序化调用，请在本技能的目录下执行脚本。

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.
两份全面的参考文档提供了详细的工作流说明：
  1. references/intake_workflow.md
     - 处理issue、讨论和支持工单的完整工作流
  2. references/response_examples.md
     - 资深团队成员使用的回复模板和示例
草拟回复或处理复杂场景时请参考这些文档。

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
  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
轮值期间请每日遵循以下流程：
  1. 检查新增内容
    • 执行
      scripts/fetch_intake_issues.sh
      查看无状态的issue
    • 执行
      scripts/fetch_discussions.sh
      查看近期讨论
    • 检查Jira中的支持工单
  2. 系统地审查每一项内容
    • 通读完整描述和上下文
    • 评估信息完整性（是否提供了系统信息、复现步骤等？）
    • 确定内容类型（bug、功能请求、问题、重复内容）
  3. 搜索相关内容
  4. 给出分类和整理建议
    • 执行
      scripts/fetch_labels.sh
      查看可用标签
    • 建议用户添加合适的标签（领域、类型、优先级）
    • 整理完成后建议将状态设置为「Triage」
    • 若适用，建议添加到「Positron Backlog」项目中
    • 准备好供用户手动执行的
      gh
      命令
  5. 草拟回复供用户审核
    • 参考
      references/response_examples.md
      中的回复模板
    • 草拟感谢贡献者的欢迎语
    • 若信息缺失，补充需要澄清的问题
    • 可行的话提供临时解决方案或相关内容的链接
    • 对后续步骤给出合理预期
    • 发布前将草稿提交给用户审核
  6. 给出后续行动建议
    • 若需要专业领域知识，建议@相关团队成员
    • 若为重复内容，草拟关联到标准issue的关闭说明
    • 合适的情况下建议将讨论转换为issue
    • 建议轮值结束后继续跟进，或明确交接给下一位轮值人员

Using GitHub CLI

使用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):
bash
undefined
为保证一致性，优先使用GitHub CLI（
gh
）完成操作。以下所有命令都需要用户手动执行。
只读命令（可执行以获取信息）：
bash
undefined

View issue with all comments

查看issue及所有评论

gh issue view <number> --repo posit-dev/positron --comments
gh issue view <number> --repo posit-dev/positron --comments

Search issues

搜索issue

gh issue list --repo posit-dev/positron --search "<query>" --state all
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):
```bash
gh api graphql -f query='...' # 示例见脚本内容

**修改类命令**（为用户准备好，绝对不要直接执行）：
```bash

Add labels - DRAFT THIS COMMAND for user to run

添加标签 - 草拟该命令供用户执行

gh issue edit <number> --repo posit-dev/positron --add-label "area: console,Bug"
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.
gh issue close <number> --repo posit-dev/positron --comment "Closing as duplicate of #<canonical-number>"

**重要提示：** 将修改类命令放在代码块中提供给用户，并明确提示用户审核后手动执行。

Handling Different Scenarios

不同场景的处理方式

Bug Reports

Bug报告

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.
处理Bug报告时，请评估信息完整性：
完整的Bug报告包含：
  • 系统信息（Positron版本、操作系统、commit哈希值）
  • 清晰的复现步骤
  • 预期行为和实际行为的对比
  • 错误信息或截图
若信息完整：
  1. 使用
    scripts/search_related.sh
    搜索重复内容
  2. 建议用户添加对应标签（领域、「Bug」类型）
  3. 建议将状态设置为「Triage」
  4. 草拟感谢报告者、确认收到issue的回复
若信息不完整：
  1. 草拟感谢报告者的消息
  2. 列出针对缺失信息的具体问题
  3. 若有帮助，建议参考Bug报告模板
  4. 建议在信息补充完成前保持issue开放
详细的Bug处理工作流请参考
references/intake_workflow.md
。

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
处理功能请求时：
  1. 草拟感谢用户提出建议的消息
  2. 搜索现有的相关功能请求
  3. 若为重复内容，草拟关联到现有issue的消息（用户手动关闭）
  4. 若为新请求，建议添加对应标签并推荐加入积压队列
  5. 草拟对优先级预期的说明消息

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).
处理讨论时：
  1. 确定讨论类型（问题、想法、Bug报告、公告）
  2. 草拟对应的回复：
    • 问题： 提供答案或文档链接
    • 想法： 确认收到并关联相关issue
    • Bug报告： 请用户创建正式的issue
    • 无关内容： 礼貌地引导到合适的渠道
当讨论包含清晰可落地的Bug报告或功能请求时，建议将讨论转换为issue（用户手动执行转换）。

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
支持工单需要特殊处理：
⚠️ 重要提示： 绝对不要在公开issue或讨论中提及客户姓名
  1. 在Jira中查看工单上下文
  2. 搜索相关的公开issue
  3. 草拟Jira内部回复（不要公开发布）供用户提交
  4. 若需要，建议创建脱敏后的公开issue
  5. 建议在工单和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
如果issue描述了安全漏洞：
  1. 绝对不要公开讨论细节
  2. 草拟请报告者发送邮件到security@posit.co的消息
  3. 建议关闭公开issue并备注请走私有上报渠道（用户手动关闭）
  4. 建议私下通知团队相关情况

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:
bash
undefined
可以参考资深团队成员的回复示例：
bash
undefined

Find issues commented on by key team members

查找核心团队成员评论过的issue

gh search issues --repo posit-dev/positron --commenter juliasilge --limit 20 gh search issues --repo posit-dev/positron --commenter jmcphers --limit 20
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

查看指定issue及评论

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.**
gh issue view <number> --repo posit-dev/positron --comments

可重点参考`juliasilge`和`jmcphers`的回复，学习语气和处理方式。

**详细的回复模板和反面示例请查看`references/response_examples.md`。**

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
不要试图独自解决所有问题。 遇到以下情况请联系团队成员：
  • issue需要特定领域的专业知识
  • 你不确定如何分类或设置优先级
  • issue描述了复杂的技术问题
  • 你需要帮助理解用户的需求

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
如果处理的内容超出了你的轮值周期：
  • 通常情况： 你可以继续跟进直到进入Triage状态
  • 若无法跟进： 明确告知下一位轮值人员完成交接
  • 不要在没有明确交接的情况下搁置任务

Documentation

文档优化

If recurring issues or common questions emerge:
  • Consider creating FAQ entries
  • Suggest documentation improvements
  • Note patterns for team discussion
如果出现重复的issue或常见问题：
  • 考虑新增FAQ条目
  • 建议优化相关文档
  • 记录共性模式供团队讨论

Quick Reference Links

快速参考链接

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.
每日接收流程（助手模式 - 草拟与建议）：
1. 获取新增内容（scripts/fetch_intake_issues.sh, scripts/fetch_discussions.sh）
2. 审查并评估每一项内容
3. 搜索相关内容（scripts/search_related.sh）
4. 建议标签和分类（scripts/fetch_labels.sh）
5. 草拟回复（参考references/response_examples.md）供用户审核
6. 准备好供用户执行的gh命令
7. 建议将状态设置为「Triage」（用户手动执行）
8. 给出后续跟进或交接的建议

注意：我们的目标是协助用户及时回复、整理可落地的内容。绝对不要直接执行GitHub修改类命令 - 始终先提供草稿和建议，供用户审核后手动执行。