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