Skip to content

ci: add issue welcome issue - #4127

Open
Phoenix500526 wants to merge 1 commit into
apache:mainfrom
Phoenix500526:action/issue-welcome
Open

ci: add issue welcome issue#4127
Phoenix500526 wants to merge 1 commit into
apache:mainfrom
Phoenix500526:action/issue-welcome

Conversation

@Phoenix500526

Copy link
Copy Markdown
Contributor

Summary

So many people don't know that they can reply a "take" or "untake" comment to self-assign or self-unassign an issue. This action is designed to leave a comment on an issue to let them know.

Refs #N

Verification

AI use

Select exactly one:

  • No generative tool made a substantive contribution
  • Generative tooling made a substantive contribution

Tool(s) and scope:

Checklist

  • Tests cover the change and fail without it
  • Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

  • Yes — described under Summary above
  • No

@github-actions github-actions Bot added the effort/S Under 100 readable lines label Aug 29, 2026
@Phoenix500526
Phoenix500526 force-pushed the action/issue-welcome branch 2 times, most recently from c458d05 to 4ee87bd Compare August 29, 2026 03:49

@Astro-Han Astro-Han left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for thinking about how we can make take / untake easier for contributors to discover.

Since this would add an automated comment to every newly opened issue, I think the behavior itself would be better discussed with the community before we decide on the implementation. The commands are already documented in the contributing guides, so it would also be useful to establish whether there is still a discoverability gap and whether an automatic comment is the preferred way to address it.

Would you mind opening a Discussion for this proposal and linking it here? That would give contributors and maintainers a place to weigh the onboarding benefit against the additional notification and issue noise. This is a suggestion about where to make the product/community decision, rather than an objection to your implementation.

Reviewed with Codex; I verified the existing assignment workflow and contributor documentation.

中文对照

谢谢你考虑如何让贡献者更容易发现 take / untake

由于这个改动会在每个新建 issue 下自动添加一条评论,我觉得在决定具体实现之前,最好先和社区讨论这个行为本身。目前贡献指南里已经记录了这些命令,因此也值得先确认现在是否仍然存在可发现性问题,以及自动评论是不是大家更希望采用的解决方式。

可以请你先为这个提议创建一个 Discussion,并在这里关联一下吗?这样贡献者和维护者可以一起权衡它对新贡献者的帮助,以及额外通知和 issue 噪声带来的影响。这只是建议把产品和社区层面的决定放到更合适的地方讨论,并不是对你当前实现的否定。

本次审查使用了 Codex;我核对了现有的 issue 认领 workflow 和贡献指南。

Signed-off-by: Jiawei Zhao <Phoenix500526@163.com>
@Phoenix500526

Copy link
Copy Markdown
Contributor Author

@Astro-Han Thanks for the suggestion. I opened #4160 so the community can discuss the discoverability benefit and notification cost before we move forward with this behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

effort/S Under 100 readable lines

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants