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