Officially we need the vote to be open for 72 hours. Thanks, Yicong Huang [email protected] On Mar 12, 2026 at 10:37 PM -0700, Chen Li <[email protected]>, wrote:
> Thanks to all for the good discussion. Can we wrap it up and make a > decision? > > Chen > > 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] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
