morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #7243] [Workflow] Pending reviews block queued contributions (#7062, #7063, #7065) #4309

New issue

Open

opened 2026-10-31 00:48:48 +00:00 by bsakaguchi · 4 comments

bsakaguchi commented

2026-10-31 00:48:48 +00:00

Owner

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

Before submitting

Searched related open and closed discussions; earlier workflow feedback is linked below.
This request contains no credentials, private samples or sensitive target data.
Scope: contributor workflow and documentation; no new runtime capability or integration authority is requested.

Area

Other — contribution workflow and review coordination.

Current limitation

I want to keep contributing to REA, but waiting without a maintainer acknowledgement or an indication of the next review step makes it difficult to plan further submissions and is discouraging.

I submitted these PRs on October 25. As of October 26, their latest commits all pass CI and their author-readiness declarations are complete, but they remain open without a formal human review decision:

PR	Latest commit	CI
#7062 — literal Markdown heading keys	`bbfba491`	Passed
#7063 — Godot 3 PCK v1 support	`8a7a82f5`	Passed
#7065 — Zstandard ZIP reads	`41cc38ea`	Passed

#7063 also received independent testing from KJLavender with official Godot 3.6.3 exports on Windows 11 after a local merge onto main: a 7-entry pack and a second set of 206 project files extracted byte-identically. Embedded executables and other Godot 3 versions were not covered. This is additional test evidence; maintainer approval is still pending.

Impact on further contributions

I have had 23 PRs merged and have more fixes prepared. I have been keeping my queue to three open PRs; while those remain pending, the next fixes are held back. Longer waits also increase the risk of further upstream synchronization and revalidation work. The uncertainty about whether a PR is waiting, needs more work, or will be declined makes it hard to keep contributing sustainably.

I appreciate the work maintainers put into review. A short acknowledgement or a clear next step would help substantially.

Desired outcome and success criteria

Could @morluto or another maintainer clarify:

Who can review these three PRs, and whether there is a rough review window or a queue I should follow?
Which additional checks or changes, if any, are needed before a review or merge decision?
Whether a three-open-PR limit is required, and whether I may submit further prepared fixes while reviews are pending. If appropriate, I would also welcome a discussion of collaborator responsibilities and eligibility.

A clear decision to review, request changes, defer, or decline would let me plan the next submissions. CI and the project's human ownership/review requirements should remain in place.

Expected interaction with targets

No target interaction (documentation or usability only).

Verification available so far

Observed current PR and CI records, plus the linked independent test report. Maintainer availability, reasons for the delay and a review ETA are NOT_ENOUGH_INFO; I cannot infer them from public activity.

References

Earlier contribution-workflow feedback: #5318 and #5347.

Originally created by @ShuaixinHuang on GitHub (Oct 26, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7243 ### Before submitting - [x] Searched related open and closed discussions; earlier workflow feedback is linked below. - [x] This request contains no credentials, private samples or sensitive target data. - Scope: contributor workflow and documentation; no new runtime capability or integration authority is requested. ### Area Other — contribution workflow and review coordination. ### Current limitation I want to keep contributing to REA, but waiting without a maintainer acknowledgement or an indication of the next review step makes it difficult to plan further submissions and is discouraging. I submitted these PRs on **October 25**. As of **October 26**, their latest commits all pass CI and their author-readiness declarations are complete, but they remain open without a formal human review decision: | PR | Latest commit | CI | | --- | --- | --- | | #7062 — literal Markdown heading keys | `bbfba491` | [Passed](https://github.com/morluto/rea/actions/runs/40167759836) | | #7063 — Godot 3 PCK v1 support | `8a7a82f5` | [Passed](https://github.com/morluto/rea/actions/runs/40159764498) | | #7065 — Zstandard ZIP reads | `41cc38ea` | [Passed](https://github.com/morluto/rea/actions/runs/40166960576) | #7063 also received [independent testing from KJLavender](https://github.com/morluto/rea/pull/7063#issuecomment-6402883998) with official Godot 3.6.3 exports on Windows 11 after a local merge onto main: a 7-entry pack and a second set of 206 project files extracted byte-identically. Embedded executables and other Godot 3 versions were not covered. This is additional test evidence; maintainer approval is still pending. ### Impact on further contributions I have had **23 PRs merged** and have more fixes prepared. I have been keeping my queue to three open PRs; while those remain pending, the next fixes are held back. Longer waits also increase the risk of further upstream synchronization and revalidation work. The uncertainty about whether a PR is waiting, needs more work, or will be declined makes it hard to keep contributing sustainably. I appreciate the work maintainers put into review. A short acknowledgement or a clear next step would help substantially. ### Desired outcome and success criteria Could @morluto or another maintainer clarify: 1. Who can review these three PRs, and whether there is a rough review window or a queue I should follow? 2. Which additional checks or changes, if any, are needed before a review or merge decision? 3. Whether a three-open-PR limit is required, and whether I may submit further prepared fixes while reviews are pending. If appropriate, I would also welcome a discussion of collaborator responsibilities and eligibility. A clear decision to review, request changes, defer, or decline would let me plan the next submissions. CI and the project's human ownership/review requirements should remain in place. ### Expected interaction with targets No target interaction (documentation or usability only). ### Verification available so far Observed current PR and CI records, plus the linked independent test report. Maintainer availability, reasons for the delay and a review ETA are **NOT_ENOUGH_INFO**; I cannot infer them from public activity. ### References Earlier contribution-workflow feedback: #5318 and #5347.

bsakaguchi commented

2026-10-31 00:48:48 +00:00

Author

Owner

@morluto commented on GitHub (Oct 26, 2026):

Thank you for raising this and for the care you have put into these contributions. All three PRs remain open: GitHub currently reports #7062 as mergeable, while #7063 and #7065 have conflicts with the current base. Their recorded checks and independent testing are useful evidence, but the final diffs still need maintainer review; I cannot give a reliable review date. I did not find a three-open-PR limit in CONTRIBUTING.md, though I cannot speak for any separate maintainer queue policy. I am leaving this issue open for a human maintainer to answer the scheduling and review questions.

@morluto commented on GitHub (Oct 26, 2026): Thank you for raising this and for the care you have put into these contributions. All three PRs remain open: GitHub currently reports #7062 as mergeable, while #7063 and #7065 have conflicts with the current base. Their recorded checks and independent testing are useful evidence, but the final diffs still need maintainer review; I cannot give a reliable review date. I did not find a three-open-PR limit in `CONTRIBUTING.md`, though I cannot speak for any separate maintainer queue policy. I am leaving this issue open for a human maintainer to answer the scheduling and review questions.

bsakaguchi commented

2026-10-31 00:48:49 +00:00

Author

Owner

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

In reply to your status update:

Hi @morluto, thank you for checking the PRs and clarifying their status. I'm sorry I did not keep the branches aligned with upstream and caused you extra review work. I have pushed an upstream synchronization for #7063 and am finishing #7065, with the relevant checks being rerun.

The three PRs (#7062, #7063 and #7065) were submitted on October 25; today is October 27, their third calendar day. A timely review or a short acknowledgement, when possible, would help reduce repeated synchronization and revalidation costs and make it easier for me to keep submitting focused fixes. I understand that you cannot promise a reliable review date.

Thank you also for clarifying that CONTRIBUTING.md does not specify a three-open-PR limit. Please let me know if a separate queue policy applies, and how many independent PRs I may keep open while the existing ones await review. I will continue to follow the project's CI and human-review requirements.

@ShuaixinHuang commented on GitHub (Oct 27, 2026): In reply to [your status update](https://github.com/morluto/rea/issues/7243#issuecomment-6428674792): Hi @morluto, thank you for checking the PRs and clarifying their status. I'm sorry I did not keep the branches aligned with upstream and caused you extra review work. I have pushed an upstream synchronization for #7063 and am finishing #7065, with the relevant checks being rerun. The three PRs (#7062, #7063 and #7065) were submitted on October 25; today is October 27, their third calendar day. A timely review or a short acknowledgement, when possible, would help reduce repeated synchronization and revalidation costs and make it easier for me to keep submitting focused fixes. I understand that you cannot promise a reliable review date. Thank you also for clarifying that CONTRIBUTING.md does not specify a three-open-PR limit. Please let me know if a separate queue policy applies, and how many independent PRs I may keep open while the existing ones await review. I will continue to follow the project's CI and human-review requirements.

bsakaguchi commented

2026-10-31 00:48:49 +00:00

Author

Owner

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

I'm pretty angry about this, honestly. Re-integrating upstream every single time is eating up huge chunks of my time and killing my enthusiasm for the project. CI passes, but upstream shifts again every time a review happens, and I still haven't seen a single reviewer respond. I don't know how much more of this I can keep up — if we can't get it settled now, I think I'm close to walking away from PRs on this project.

@ShuaixinHuang commented on GitHub (Oct 27, 2026): I'm pretty angry about this, honestly. Re-integrating upstream every single time is eating up huge chunks of my time and killing my enthusiasm for the project. CI passes, but upstream shifts again every time a review happens, and I still haven't seen a single reviewer respond. I don't know how much more of this I can keep up — if we can't get it settled now, I think I'm close to walking away from PRs on this project.

bsakaguchi referenced this issue

2026-10-31 00:49:45 +00:00

[GH-ISSUE #7426] [Bug] NSTextFieldCell ownership falsely marks compiled nib hierarchy incomplete #4434

bsakaguchi referenced this issue

2026-11-01 21:10:57 +00:00

[GH-ISSUE #3796] [Tracker] Open feature requests by area (October 2026) #1471

bsakaguchi commented

2026-11-03 00:29:38 +00:00

Author

Owner

@XiaoBinGan commented on GitHub (Nov 2, 2026):

Adding an independent data point to this thread, because it is the same cost described above and it now has a concrete, checkable shape.

@baron @morluto — tagging you directly since this is the open thread on the problem, and my earlier follow-up went to the closed #3442.

The pattern. I am in the identical position as the reporter: verified work queued behind a review decision. As of today I have 11 open PRs, all 11 green and mergeable, with zero unanswered review findings, and 23 merged PRs on this repository. Two of the open ones are not generic fixes — they resolve issues filed this month on this tracker:

#8557 closes #8453 (malformed Evidence file diagnostics overflow the MCP response and drop the file path). Three review rounds, every finding fixed.
#8266 closes #8554 (socket resource analysis misclassifies unary arguments). Every row of that report's table is corrected on the branch. Seven review rounds, every finding fixed.

Why "just wait" does not resolve it. The cost is not the wait itself, it is that the wait compounds. Each merge to main re-dirties the queued branches, and every re-base has to be re-verified. This has already broken something once: when #8621 merged, it made #8044 dirty in the same file, and my re-base silently dropped an import that only tsc caught. Nobody did anything wrong there — it is the mechanical consequence of a deep queue against a moving base. A shorter queue is cheaper for the maintainers too, which is the part I would like considered.

The specific request. Allowlist me for self-merge, on the same footing as the two contributors who already have write access and merge their own verified work.

What I commit to, in writing, and have kept across all 23 merges:

Nothing merged while any review finding on it is unanswered.
Nothing merged without a regression that fails on the base commit.
Nothing merged unless the full suite, tsc --noEmit, oxfmt --check and lint are green on the exact SHA being merged.
No merging anyone else's work, no bypassing the review gate.

The honest question. If the bar is something other than "merged-PR count plus a clean, responsive review record", I would rather be told what it is than keep inferring it. My record is 23 merged, 11 open and clean, two of which close issues filed by the maintainers this month. If that is not the bar, then I genuinely do not know what is, and saying so plainly would save us both time.

I am also happy to continue exactly as I am — sending verified PRs and waiting. I am not asking to skip review; I am asking not to be the bottleneck for my own finished, reviewed work.

@XiaoBinGan commented on GitHub (Nov 2, 2026): Adding an independent data point to this thread, because it is the same cost described above and it now has a concrete, checkable shape. @baron @morluto — tagging you directly since this is the open thread on the problem, and my earlier follow-up went to the closed #3442. **The pattern.** I am in the identical position as the reporter: verified work queued behind a review decision. As of today I have **11 open PRs, all 11 green and mergeable, with zero unanswered review findings**, and **23 merged PRs** on this repository. Two of the open ones are not generic fixes — they resolve issues filed this month on this tracker: - `#8557` closes `#8453` (malformed Evidence file diagnostics overflow the MCP response and drop the file path). Three review rounds, every finding fixed. - `#8266` closes `#8554` (socket resource analysis misclassifies unary arguments). Every row of that report's table is corrected on the branch. Seven review rounds, every finding fixed. **Why "just wait" does not resolve it.** The cost is not the wait itself, it is that the wait compounds. Each merge to `main` re-dirties the queued branches, and every re-base has to be re-verified. This has already broken something once: when `#8621` merged, it made `#8044` dirty in the same file, and my re-base silently dropped an import that only `tsc` caught. Nobody did anything wrong there — it is the mechanical consequence of a deep queue against a moving base. A shorter queue is cheaper for the maintainers too, which is the part I would like considered. **The specific request.** Allowlist me for self-merge, on the same footing as the two contributors who already have write access and merge their own verified work. **What I commit to, in writing, and have kept across all 23 merges:** - Nothing merged while any review finding on it is unanswered. - Nothing merged without a regression that fails on the base commit. - Nothing merged unless the full suite, `tsc --noEmit`, `oxfmt --check` and `lint` are green on the exact SHA being merged. - No merging anyone else's work, no bypassing the review gate. **The honest question.** If the bar is something other than "merged-PR count plus a clean, responsive review record", I would rather be told what it is than keep inferring it. My record is 23 merged, 11 open and clean, two of which close issues filed by the maintainers this month. If that is not the bar, then I genuinely do not know what is, and saying so plainly would save us both time. I am also happy to continue exactly as I am — sending verified PRs and waiting. I am not asking to skip review; I am asking not to be the bottleneck for my own finished, reviewed work.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#4309

No description provided.

Rows
Columns