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] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
