-1
Treating Issue or Discussion as documentation of a PR is not the purpose of
them.
In my point of view, Issues are the problems users encounter and open one
to explain what was the error (issue) and how to replicate it.
Discussion is a place for brainstorming and exchanging ideas.
Each PR has a dedicated PR description to include all the information and
documentation and I prefer to have everything in one place.
It is just a personal opinion.

Best regards,
Ali

On Tue, Mar 10, 2026 at 2:43 PM Yicong Huang <[email protected]>
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]
>
>

Reply via email to