[docs] Add "Contribute Code" community documentation (#572)

Author: caozhen1937

website/community/how-to-contribute/contribute-code.md

@@ -21,7 +21,62 @@ sidebar_position: 1
 
 # Contribute Code
 
-TODO
+Fluss is maintained, improved, and extended by code contributions of volunteers. We welcome contributions to Fluss, but due to preserve the high quality of the code base, we follow a contribution process that is explained in this document.
+
+:::warning
+Please read this document carefully before starting to work on a code contribution. Follow the process and guidelines explained below. Contributing to Fluss does not start with opening a pull request. We expect contributors to reach out to us first to discuss the overall approach together. Without consensus with the Fluss committers, contributions might require substantial rework or will not be reviewed.
+:::
+
+## Looking for what to contribute
+
+- If you have a good idea for the contribution, you can proceed to [the code contribution process](#code-contribution-process).
+- If you are looking for what you could contribute, you can browse [open issues](https://github.com/alibaba/fluss/issues), which are not assigned, and then follow [the code contribution process](#code-contribution-process).
+- If you are very new to the Fluss project and ready to tackle some open issues, we've collected some [good first issues](https://github.com/alibaba/fluss/contribute) for you.
+
+
+## Code Contribution Process
+
+### Discuss
+
+Create an issue and reach consensus.
+
+**To request an issue, please note that it is not just a "please assign it to me", you need to explain your understanding of the issue, and your design, and if possible, you need to provide your POC code.**
+
+### Implement
+
+Implement the change according to the Code Style and Quality(refer to the [Flink doc](https://flink.apache.org/how-to-contribute/code-style-and-quality-preamble/) Guide and the approach agreed upon in the issue.
+
+1. Only start working on the implementation if there is consensus on the approach (e.g. you are assigned to the ticket)
+2. If you are newer, can refer to [ide setup](/community/dev/ide-setup) to setup a Fluss dev environment.
+
+### Review
+Create the pull request and work with the reviewer. 
+
+1. Make sure no unrelated or unnecessary reformatting changes are included.
+2. Please ensure that the test passing.
+3. Please don't resolve conversation.
+
+### Merge
+A committer of Fluss checks if the contribution fulfills the requirements and merges the code to the codebase.
+
+## Pull Request Guide
+
+Considerations before opening a pull request:
+
+- Make sure that the pull request corresponds to a [GitHub issue](https://github.com/alibaba/fluss/issues). Exceptions are made for typos in JavaDoc or documentation files, which need no issue.
+
+- Name the pull request in the format "[component] Title of the pull request", where *[component]* should be replaced by the name of the component being changed. Typically, this corresponds to the component label assigned to the issue (e.g., [kv], [log], [client], [flink]). Skip *[component]* if you are unsure about which is the best component. **Hotfixes** should be named for example `[hotfix][docs] Expand JavaDoc for PuncuatedWatermarkGenerator`.
+
+- Fill out the pull request template to describe the changes contributed by the pull request. Please describe it such that the reviewer understands the problem and solution from the description, not only from the code. That will give reviewers the context they need to do the review.
+
+- Make sure that the change passes the automated tests, i.e., `mvn clean verify` passes.
+
+- Each pull request should address only one issue, not mix up code from multiple issues.
+
+
+There is a separate guide on [how to review a pull request](how-to-contribute/review-pull-requests.md), including our pull request review process. As a code author, you should prepare your pull request to meet all requirements.
+
+You need to make sure that all GitHub Actions CI checks must pass for a pull request. If there are any failures, it is essential to investigate the exception stack by in the CI logs. Additionally, GitHub Actions automatically collects and uploads Maven logs (logs printed by log4j in the code) to GitHub Artifacts (see the "Artifacts" section in this [build](https://github.com/alibaba/fluss/actions/runs/13761957739)). These logs are particularly valuable for debugging issues that are difficult to reproduce in a local environment.
 
 
 

website/community/how-to-contribute/review-pull-requests.md

@@ -0,0 +1,63 @@
+---
+sidebar_label: Review Pull Requests
+sidebar_position: 1
+---
+
+<!--
+ Copyright (c) 2025 Alibaba Group Holding Ltd.
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+      http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+# How to Review a Pull Request
+
+This guide is for all committers and contributors that want to help with reviewing code contributions. Thank you for your effort - good reviews are one of the most important and crucial parts of an open source project. This guide should help the community to make reviews such that:
+
+* Contributors have a good contribution experience.
+* Our reviews are structured and check all important aspects of a contribution.
+* We make sure to keep a high code quality in Fluss.
+* We avoid situations where contributors and reviewers spend a lot of time refining a contribution that gets rejected later.
+
+## Review Checklist
+
+Every review needs to check the following six aspects. **We encourage to check these aspects in order, to avoid
+spending time on detailed code quality reviews when formal requirements are not met or there is no consensus in
+the community to accept the change.**
+
+### 1. Is the Contribution Well-Described?
+
+Check whether the contribution is sufficiently well-described to support a good review. Trivial changes and fixes
+do not need a long description. If the implementation is exactly according to a prior discussion on issue or the
+development mailing list, only a short reference to that discussion is needed.
+
+If the implementation is different from the agreed approach in the consensus discussion, a detailed description of
+the implementation is required for any further review of the contribution.
+
+### 2. Does the Contribution Need Attention from some Specific Committers?
+
+Some changes require attention and approval from specific committers.
+
+If the pull request needs specific attention, one of the tagged committers/contributors should give the final approval.
+
+### 3. Is the Overall Code Quality Good, Meeting Standard we Want to Maintain in Fluss?
+
+- Does the code follow the right software engineering practices? Is the code correct, robust, maintainable, testable?
+- Are the changes performance aware, when changing a performance sensitive part?
+- Are the changes sufficiently covered by tests? Are the tests executing fast?
+- If dependencies have been changed, were the NOTICE files updated?
+
+Code guidelines can be found in the [Flink Java Code Style and Quality Guide](https://flink.apache.org/how-to-contribute/code-style-and-quality-java/).
+
+### 4. Are the documentation updated?
+
+If the pull request introduces a new feature, the feature should be documented.