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
>