+1 I think it is a norm for OSS contributors to raise a new issue or find an existing issue first, then raise a PR that links to that issue. Adding a hard check can remind reviewers to check the motivation and the scope of the changes.
Best, Jiadong Bai On Thu, Mar 12, 2026 at 11:22 PM Yicong Huang <[email protected]> wrote: > I agree that these are two separate questions, and that the specific > enforcement mechanism was not part of this vote. > > If this vote passes and we agree that the requirement should be enforced, > we will then need to decide how to apply that enforcement in practice, we > can discuss this kind of implementation details on PRs following up. I > mentioned CI only as one possible way enforcement could be handled in > practice later on. My point was not to include that as part of this vote, > but simply to note that, if linking an issue becomes a formal requirement, > some practical enforcement approach may eventually be needed. Relying only > on reviewers to check this manually would add review burden, make > enforcement less consistent, and make expectations harder to communicate to > new reviewers. That said, I am open to other enforcement approaches as > well. Feel free to propose one! > > Best, > Yicong Huang > [email protected] > > On Mar 12, 2026 at 11:09 PM -0700, Xinyuan Lin <[email protected]>, > wrote: > > I did read and follow that part of the vote proposal, and I'm not opposed > > to the vote itself. My concern is specifically about using CI to enforce > > the requirement. The proposal mentioned that enforcement *could* be > > implemented through CI, but that wasn’t actually part of what we are > voting > > on, and I strongly disagree with taking that approach. > > > > I just want to emphasize that even if this vote passes, it does not mean > we > > have automatically agreed to enforce it through CI. That should remain a > > separate discussion about implementation details. > > > > On Thu, Mar 12, 2026 at 11:00 PM Yicong Huang <[email protected]> > > wrote: > > > > > The enforcement is already part of the vote. Quoting from the initial > vote > > > proposal: > > > > > > > > If this vote passes, we will treat issue/discussion linkage as the > > > expected policy for non-minor PRs, and we can follow up with practical > > > enforcement details in the PR template and/or CI checks. If the vote > does > > > not pass, we will continue to treat those information as optional > fields. > > > > > > The entire vote is about whether we want to enforce this requirement or > > > not. Whether we want reviewers to manually enforce it or rely on CI, > it's > > > implementation details. > > > > > > Best, > > > Yicong Huang > > > [email protected] > > > > > > On Mar 12, 2026 at 10:54 PM -0700, Xinyuan Lin <[email protected] > >, > > > wrote: > > > > > As I mentioned earlier, I’m fine with requiring PRs to link to an > issue > > > > > (i.e., I would vote 0 on that point). However, I think the > question of > > > > > whether CI should be used to enforce this requirement should be > handled > > > as > > > > > a separate vote. We shouldn’t combine multiple topics or > implementation > > > > > steps into a single vote. > > > > > > > > > > Regarding the idea of a “soft check,” it’s true that many existing > PRs do > > > > > not have linked issues. However, this is mainly because linking > issues > > > has > > > > > not been an official requirement in the past. The PR and issue > templates > > > > > have only served as guidance for developers, and they were never > formally > > > > > discussed or approved through a vote. As a result, reviewers have > not > > > had a > > > > > clear mandate to enforce them. > > > > > > > > > > If this vote passes and linking an issue becomes a formal > requirement for > > > > > PRs, then reviewers should check for it and enforce it during the > review > > > > > process. > > > > > > > > > > On Thu, Mar 12, 2026 at 10:27 PM Yicong Huang < > [email protected]> > > > > > wrote: > > > > > > > > > > > > Thanks, Zuozhi and Shengquan, for recognizing the importance > of using > > > > > > > issues and linking related information. > > > > > > > > > > > > > > Regarding the idea of a “soft CI check,” we have already tried > > > something > > > > > > > similar by making the PR template include an optional field > for related > > > > > > > issues or discussions. In practice, this has functioned like a > soft > > > > > > > requirement/guidance, but unfortunately most PRs tend not to > follow > > > it. In > > > > > > > an earlier count, 15 of the last 25 merged PRs had no linked > issue. 18 > > > of > > > > > > > the 25 open PRs have no linked issue. Based on this > statistics, I feel > > > the > > > > > > > urgency to open this vote and I do not think adding only a > soft check > > > would > > > > > > > be very effective to change the situation. > > > > > > > > > > > > > > As for exceptions, I agree that this is open for discussion, > and I > > > think > > > > > > > we should welcome more proposals. That said, we need to be > clear about > > > what > > > > > > > counts as a MINOR change. Otherwise, MINOR could easily become > a > > > catch-all > > > > > > > category that covers almost everything. In the initial > proposal, I > > > > > > > intentionally kept MINOR to a very small subset of changes. The > > > principle > > > > > > > is that some changes may not need prior discussion because > they are > > > > > > > straightforward and unlikely to be controversial, such as > documentation > > > > > > > updates or typo fixes. I would also be open to extending this > category > > > to > > > > > > > formatting-only changes and dead code removal. However, for > bug fixes, > > > I > > > > > > > would still suggest keeping a record through an issue, since > the issue > > > > > > > captures the bug itself and the context behind the fix, not > just the > > > code > > > > > > > change. > > > > > > > > > > > > > > Anyway, I appreciate all the feedback and votes so far. It is > healthy > > > to > > > > > > > have different voices from the community. I would again > encourage more > > > > > > > people on the dev mailing list to speak up and share their > views as > > > well! > > > > > > > > > > > > > > Best, > > > > > > > Yicong Huang > > > > > > > [email protected] > > > > > > > > > > > > > > On Mar 12, 2026 at 11:28 AM -0700, Shengquan Ni < > [email protected]>, > > > wrote: > > > > > > > > > > > > > > > > > > 0 > > > > > > > > > > > > > > > > > > > > > > I think linking related information is helpful for PRs > that went > > > through > > > > > > > > > > > multiple discussion iterations, especially for new > contributors to > > > > > > > > > > > understand the reasoning behind certain decisions. But > I also > > > agree with > > > > > > > > > > > Zuozhi that “minor fixes” should likely be a bit > broader than > > > what’s > > > > > > > > > > > described here. > > > > > > > > > > > Overall, I don't have a strong opinion on this. > > > > > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > > > Shengquan Ni > > > > > > > > > > > > > > > > > > > > > > On Wed, Mar 11, 2026 at 11:37 PM Zuozhi Wang < > [email protected]> > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > +1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Re: Ali, I believe in many open source > projects, issues are > > > both for > > > > > > > users > > > > > > > > > > > > > > > reporting problems/bugs, and propose > enhancements. Discussion > > > is a new > > > > > > > > > > > > > > > thing to me and I'm not very familiar with how > people are > > > adopting it, > > > > > > > > > > > > > > > before discussions exist, I think people also > use issues for > > > discussion > > > > > > > > > > > > > > > purposes. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regarding this proposal, PR describes a > specific change, > > > > > > > > > > > > > > > issues/discussions describes the original bug > or enhancement > > > proposals. > > > > > > > > > > > > > > > Also it's quite common to have a single issue > linking with > > > multiple > > > > > > > PRs if > > > > > > > > > > > > > > > a work is complex and needs to be broken down > into smaller PRs. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm fine with soft CI checks, hard CI checks > is a bit too much > > > to me > > > > > > > right > > > > > > > > > > > > > > > now. > > > > > > > > > > > > > > > Also I'm fine with "minor fixes" to be a bit > larger than what's > > > > > > > described > > > > > > > > > > > > > > > right in the proposal, I would add things like > minor bug fixes > > > or minor > > > > > > > > > > > > > > > code cleanups as well. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2026/03/10 21:42:26 Yicong Huang wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi everyone, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would like to start a vote > on adopting the following > > > contribution > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > policy for Apache Texera: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Proposal > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > For pull requests that are not > minor, contributors > > > should include > > > > > > > at > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > least one related GitHub Issue or GitHub > Discussion reference > > > in the PR > > > > > > > > > > > > > > > description. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Examples of acceptable > references include: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > • Closes/Fixes/Resolves #1234 > > > > > > > > > > > > > > > > > > > > > > > • Related to #1234 > > > > > > > > > > > > > > > > > > > > > > > • Discussion #1234 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The goal is to make sure each > non-minor code change is > > > connected > > > > > > > to its > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > original problem statement, motivation, or > prior discussion > > > context. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Rationale > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Today, many PRs do not > properly fill in the “Any > > > related issues, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > documentation, discussions?” section in the PR > template, and > > > some PRs > > > > > > > do > > > > > > > > > > > > > > > not link any issue or discussion at all. This > makes review and > > > > > > > long-term > > > > > > > > > > > > > > > maintenance harder. As discussed in #4246, > issue/discussion > > > linkage > > > > > > > > > > > > > > > improves traceability, preserves decision > context, and helps > > > > > > > contributors > > > > > > > > > > > > > > > and reviewers understand why a change exists. > It also makes it > > > easier > > > > > > > to > > > > > > > > > > > > > > > track follow-up work, revisions, and related > PRs over time. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Scope / exception > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Minor PRs can be exempt, such > as: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > • typo fixes > > > > > > > > > > > > > > > > > > > > > > > • comment-only changes > > > > > > > > > > > > > > > > > > > > > > > • very small non-functional > cleanup > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > One way to handle this is to > explicitly mark such PRs > > > as minor. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What this vote is about > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If this vote passes, we will > treat issue/discussion > > > linkage as the > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > expected policy for non-minor PRs, and we can > follow up with > > > practical > > > > > > > > > > > > > > > enforcement details in the PR template and/or > CI checks. If > > > the vote > > > > > > > does > > > > > > > > > > > > > > > not pass, we will continue to treat those > information as > > > optional > > > > > > > fields. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please vote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > • +1: support adopting this > policy > > > > > > > > > > > > > > > > > > > > > > > • 0: no strong opinion > > > > > > > > > > > > > > > > > > > > > > > • -1: do not support adopting > this policy, preferably > > > with > > > > > > > explanation > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This vote will remain open for > at least 72 hours. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > Yicong Huang > > > > > > > > > > > > > > > > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
