[GH-ISSUE #5318] [Workflow] PR review ownership, repeated upstream syncs, and contributor motivation #3235

New issue

Closed

opened 2026-10-31 00:38:10 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-31 00:38:10 +00:00

Owner

Originally created by @ShuaixinHuang on GitHub (Oct 20, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5318

Superseded by #5347. Please continue the review-coordination discussion in the replacement issue, which summarizes the current CI-passing state. This issue is closed because it was replaced; the original discussion and evidence remain available below.

Decision needed

Could maintainers assign a reviewer and give a rough review window for #4941, #4946 and #4947, and clarify when contributors should refresh an unmerged branch against moving upstream?

Context and evidence

These PRs were opened on October 18 and are still open on October 20, entering their third calendar day. I have repeatedly fixed reported problems and rerun validation while upstream has continued changing. Repeated synchronization and new conflicts make the same unmerged contributions require ongoing work.

I have not received a reply or review submission from the maintainers contacted in the October 19 review request. CassieFox23 has provided a useful independent retest of #4941, which I appreciate; my concern is the absence of a clear maintainer review owner or schedule.

Latest update — October 20, 09:37 Beijing time (01:37 UTC)

All three current PR heads have now been rechecked: CI required and author readiness pass, and GitHub reports no merge conflicts.

One final combined review-request email was sent to morluto, N0zoM1z0 and Kaoru0822 using their verified public contact addresses. It explains the repeated synchronization work, open-PR limit and queued contributions, and asks for a reviewer or a rough review window. I explicitly stated that this is my final unsolicited review reminder for these PRs: I will send no further review emails or @ reminders, and will wait for the normal review process while responding to any requested technical details. Sending is confirmed; delivery, reading and a maintainer response are not confirmed.

Current status, so the request is concrete:

#4947: current-head required CI passes and GitHub reports no merge conflict. Could this small, test-only correction be reviewed first?
#4946 (updated October 20, 01:35 UTC): upstream conflict resolved and pushed as b4483ce8. Current-head CI, including CI required, passes: 38 successful jobs; five portable test shards with 9,636 tests passed and zero failures. GitHub reports no merge conflict. The PR body retains the known independent local Windows fixture limitation tracked by #4947.
#4941 (updated October 20, 01:09 UTC): current-head CI at 35e2cad5 and CI required now pass. All five portable test shards passed (10,251 tests, zero failures), including all 16 Java cancellation/cleanup controls and 27 filename/URL controls on Linux. Readiness passes and GitHub reports no merge conflict. This PR is now awaiting maintainer review.

I remain responsible for technical correctness and responding to review feedback. This request concerns review coordination and feedback, with the normal checks and review requirements preserved.

Contributor impact

I have additional contributions waiting locally, and the open-PR limit makes this review queue affect further work. Spending repeated cycles reconciling the same unmerged changes, without an acknowledgement or a rough review window, is discouraging and is reducing my motivation to keep volunteering maintenance work.

Requested next steps

Identify who can review these PRs, starting with the small CI-passing #4947.
Give a rough review window, or say explicitly if the work should be paused or declined.
Clarify whether branches should be continuously synchronized while waiting, or refreshed when a reviewer is ready.
Consider how the open-PR limit and review queue can support contributors with further fixes waiting.

Related workflow proposals: #3445 (review routing/CODEOWNERS) and #3588 (triage and repository workflow). This issue supplies a concrete current contributor experience and asks for a review plan.

No target interaction; this is contribution-workflow feedback. The evidence above is the linked PR/check/comment record; maintainer availability and notification read status are unknown.

Originally created by @ShuaixinHuang on GitHub (Oct 20, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5318 > **Superseded by #5347.** Please continue the review-coordination discussion in the replacement issue, which summarizes the current CI-passing state. This issue is closed because it was replaced; the original discussion and evidence remain available below. ### Decision needed Could maintainers assign a reviewer and give a rough review window for #4941, #4946 and #4947, and clarify when contributors should refresh an unmerged branch against moving upstream? ### Context and evidence These PRs were opened on October 18 and are still open on October 20, entering their third calendar day. I have repeatedly fixed reported problems and rerun validation while upstream has continued changing. Repeated synchronization and new conflicts make the same unmerged contributions require ongoing work. I have not received a reply or review submission from the maintainers contacted in [the October 19 review request](https://github.com/morluto/rea/pull/4941#issuecomment-6268340992). CassieFox23 has provided a useful [independent retest of #4941](https://github.com/morluto/rea/pull/4941#pullrequestreview-5573391687), which I appreciate; my concern is the absence of a clear maintainer review owner or schedule. ### Latest update — October 20, 09:37 Beijing time (01:37 UTC) All three current PR heads have now been rechecked: **CI required and author readiness pass, and GitHub reports no merge conflicts**. One final combined review-request email was sent to morluto, N0zoM1z0 and Kaoru0822 using their verified public contact addresses. It explains the repeated synchronization work, open-PR limit and queued contributions, and asks for a reviewer or a rough review window. I explicitly stated that this is my final unsolicited review reminder for these PRs: I will send no further review emails or @ reminders, and will wait for the normal review process while responding to any requested technical details. Sending is confirmed; delivery, reading and a maintainer response are not confirmed. Current status, so the request is concrete: - **#4947:** current-head required CI passes and GitHub reports no merge conflict. Could this small, test-only correction be reviewed first? - **#4946 (updated October 20, 01:35 UTC):** upstream conflict resolved and pushed as `b4483ce8`. [Current-head CI](https://github.com/morluto/rea/actions/runs/39352850029), including `CI required`, passes: 38 successful jobs; five portable test shards with 9,636 tests passed and zero failures. GitHub reports no merge conflict. The PR body retains the known independent local Windows fixture limitation tracked by #4947. - **#4941 (updated October 20, 01:09 UTC):** [current-head CI](https://github.com/morluto/rea/actions/runs/39350036839) at `35e2cad5` and `CI required` now pass. All five portable test shards passed (10,251 tests, zero failures), including all 16 Java cancellation/cleanup controls and 27 filename/URL controls on Linux. Readiness passes and GitHub reports no merge conflict. This PR is now awaiting maintainer review. I remain responsible for technical correctness and responding to review feedback. This request concerns review coordination and feedback, with the normal checks and review requirements preserved. ### Contributor impact I have additional contributions waiting locally, and the open-PR limit makes this review queue affect further work. Spending repeated cycles reconciling the same unmerged changes, without an acknowledgement or a rough review window, is discouraging and is reducing my motivation to keep volunteering maintenance work. ### Requested next steps 1. Identify who can review these PRs, starting with the small CI-passing #4947. 2. Give a rough review window, or say explicitly if the work should be paused or declined. 3. Clarify whether branches should be continuously synchronized while waiting, or refreshed when a reviewer is ready. 4. Consider how the open-PR limit and review queue can support contributors with further fixes waiting. Related workflow proposals: #3445 (review routing/CODEOWNERS) and #3588 (triage and repository workflow). This issue supplies a concrete current contributor experience and asks for a review plan. No target interaction; this is contribution-workflow feedback. The evidence above is the linked PR/check/comment record; maintainer availability and notification read status are unknown.

bsakaguchi closed this issue

2026-10-31 00:38:10 +00:00

bsakaguchi commented

2026-10-31 00:38:11 +00:00

Author

Owner

@XinwangTao commented on GitHub (Oct 20, 2026):

This is a useful data point for the workflow discussion. The most actionable ask here is probably the synchronization policy: asking contributors to keep an unmerged branch continuously synced with moving upstream turns review latency into unbounded contributor work, which is exactly what wears out volunteers. A reviewer-ready-then-sync convention (refresh only once a reviewer is assigned/ready) would cap that cost, and the current-head CI status the author already maintains makes that safe. Reviewing the small test-only #4947 first also seems like a low-cost way to unblock the queue.

@XinwangTao commented on GitHub (Oct 20, 2026): This is a useful data point for the workflow discussion. The most actionable ask here is probably the synchronization policy: asking contributors to keep an unmerged branch continuously synced with moving upstream turns review latency into unbounded contributor work, which is exactly what wears out volunteers. A reviewer-ready-then-sync convention (refresh only once a reviewer is assigned/ready) would cap that cost, and the current-head CI status the author already maintains makes that safe. Reviewing the small test-only #4947 first also seems like a low-cost way to unblock the queue.

bsakaguchi commented

2026-10-31 00:38:11 +00:00

Author

Owner

@ShuaixinHuang commented on GitHub (Oct 20, 2026):

@gensokyo-dev, could you please review #4941, #4946 and #4947, or help assign a maintainer reviewer?

#4947 is the small test-only fixture correction, so reviewing it first would help unblock the contribution queue. The PR descriptions contain the CI results and validation limits, and #4946's upstream conflict has been resolved. A rough review window, and guidance on when to resynchronize while waiting, would help avoid repeated rework.

Thank you for your time and help.

@ShuaixinHuang commented on GitHub (Oct 20, 2026): @gensokyo-dev, could you please review #4941, #4946 and #4947, or help assign a maintainer reviewer? #4947 is the small test-only fixture correction, so reviewing it first would help unblock the contribution queue. The PR descriptions contain the CI results and validation limits, and #4946's upstream conflict has been resolved. A rough review window, and guidance on when to resynchronize while waiting, would help avoid repeated rework. Thank you for your time and help.

bsakaguchi referenced this issue

2026-10-31 00:40:57 +00:00

[GH-ISSUE #5733] [Docs] inspect_analysis_view parent lists omit supported pcap capture Evidence #3480

bsakaguchi referenced this issue

2026-10-31 01:08:24 +00:00

[PR #3235] [CLOSED] fix(cli): list retained analysis-view parents the service projects #5664