You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@texera.apache.org by Ian Maxon <im...@apache.org> on 2025/08/01 16:33:24 UTC

Re: [DISCUSS] Code Contribution Process

This seems like a great idea to me. +1. These are practices I wish we
had adopted earlier in AsterixDB.
My only small suggestion would be that there is an ASF Slack. It might
be a good idea to migrate to that one.

On Thu, Jul 31, 2025 at 3:50 PM Xinyuan Lin <li...@gmail.com> wrote:
>
> *Proposed Code Contribution Process*
>
> Based on our discussion, we propose the following process for contributing
> to the codebase:
>
>    1.
>
>    *Create an Issue for Any Proposed Change*
>    To track any proposed changes to the codebase, developers should first
>    create a corresponding issue. While we often have offline discussions, any
>    such conversation that involves proposed code changes should be summarized
>    and added to the relevant issue. Developers are free to use their preferred
>    tools to create diagrams or documents, but the final outputs should be
>    attached to the issue.
>    2.
>
>    *Include Final Design in the Pull Request (PR) Description*
>    If a design document exists for a particular feature or change, it
>    should be included or summarized in the PR description. This ensures the
>    context and rationale for changes are clearly visible during the review
>    process.
>    3.
>
>    *Store User-Facing Documentation in the docs Folder*
>    Any documentation intended to help users understand or use the system
>    should be added to the docs folder in the main repository.
>    4.
>
>    *Review Process and Merging Guidelines*
>    Reviewers are responsible for ensuring that each PR aligns with the
>    design discussed in the associated issue. Any contributor can serve as a
>    reviewer. However, only a committer can merge a PR. While a committer
>    doesn’t have to review every PR personally, they must verify that the PR
>    adheres to the Code Contribution Process before merging.
>    5.
>
>    *Sync Discussions Across Channels*
>    All development-related discussions from the Texera Slack #dev channel
>    and Texera GitHub repo should be synced to this dev mailing list to ensure
>    transparency and continuity.
>
> --
>
> Sincerely,
>
> Xinyuan Lin

Re: [DISCUSS] Code Contribution Process

Posted by Chen Li <ch...@gmail.com>.
I also support these practices.   We will start following them.

We will also look into the ASF Slack.

Chen

On Fri, Aug 1, 2025 at 9:33 AM Ian Maxon <im...@apache.org> wrote:

> This seems like a great idea to me. +1. These are practices I wish we
> had adopted earlier in AsterixDB.
> My only small suggestion would be that there is an ASF Slack. It might
> be a good idea to migrate to that one.
>
> On Thu, Jul 31, 2025 at 3:50 PM Xinyuan Lin <li...@gmail.com> wrote:
> >
> > *Proposed Code Contribution Process*
> >
> > Based on our discussion, we propose the following process for
> contributing
> > to the codebase:
> >
> >    1.
> >
> >    *Create an Issue for Any Proposed Change*
> >    To track any proposed changes to the codebase, developers should first
> >    create a corresponding issue. While we often have offline
> discussions, any
> >    such conversation that involves proposed code changes should be
> summarized
> >    and added to the relevant issue. Developers are free to use their
> preferred
> >    tools to create diagrams or documents, but the final outputs should be
> >    attached to the issue.
> >    2.
> >
> >    *Include Final Design in the Pull Request (PR) Description*
> >    If a design document exists for a particular feature or change, it
> >    should be included or summarized in the PR description. This ensures
> the
> >    context and rationale for changes are clearly visible during the
> review
> >    process.
> >    3.
> >
> >    *Store User-Facing Documentation in the docs Folder*
> >    Any documentation intended to help users understand or use the system
> >    should be added to the docs folder in the main repository.
> >    4.
> >
> >    *Review Process and Merging Guidelines*
> >    Reviewers are responsible for ensuring that each PR aligns with the
> >    design discussed in the associated issue. Any contributor can serve
> as a
> >    reviewer. However, only a committer can merge a PR. While a committer
> >    doesn’t have to review every PR personally, they must verify that the
> PR
> >    adheres to the Code Contribution Process before merging.
> >    5.
> >
> >    *Sync Discussions Across Channels*
> >    All development-related discussions from the Texera Slack #dev channel
> >    and Texera GitHub repo should be synced to this dev mailing list to
> ensure
> >    transparency and continuity.
> >
> > --
> >
> > Sincerely,
> >
> > Xinyuan Lin
>