[doc] Update release/contribution/quickstart docs (#242)

* Add release process

* Update the contributions docs

* Update the architecture part

* Address review feedback

docs/source/community/community.rst

@@ -4,4 +4,14 @@
 Community
 =========
 
-TODO
+AIBrix Slack Channels
+---------------------
+
+We use the `AIBrix Slack <https://join.slack.com/t/aibrix/shared_invite/zt-2r893y8c7-wdwPxeJLqNWf2SdLlRDYCg>`_ for informal discussions among users and contributors.
+Join the channels to start conversations and get support from the community.
+
+
+AiBrix Mailing List
+-------------------
+
+The official AIBrix mailing list is hosted on Google Groups at `[email protected] <[email protected]>`_.

docs/source/community/contribution.rst

@@ -0,0 +1,89 @@
+.. _contribution:
+
+============
+Contribution
+============
+
+This document serves as the definitive guide for contributing to the codebase. We welcome your patches and contributions to the project and appreciate your support.
+
+To ensure a smooth process, please follow a few simple guidelines.
+
+
+Getting Started
+---------------
+
+Please make sure to read and observe our `Code of Conduct <https://github.com/aibrix/aibrix/blob/main/CODE_OF_CONDUCT.md>`_.
+
+
+Make your first contribution
+----------------------------
+
+Find something to start with
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Help is always welcome! For example, documentation can always use improvement.
+There’s always code that can be clarified and variables or functions that can be renamed or commented.
+There’s always a need for more test coverage. You get the idea - if you ever see something you think should be fixed, you should own it.
+Here is how you get started.
+
+Good Start issues
+^^^^^^^^^^^^^^^^^
+
+To find AIBrix issues that make good entry points:
+
+- Start with issues labeled `good first issue <https://github.com/aibrix/aibrix/labels/good%20first%20issue>`_.
+- For issues that require deeper knowledge of one or more technical aspects, look at issues labeled `help wanted <https://github.com/aibrix/aibrix/labels/help%20wanted>`_.
+
+Joining the community
+---------------------
+
+Follow these instructions if you want to:
+
+Become an official member of the AIBrix GitHub Org
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Before requesting to join the AIBrix GitHub Org, we kindly ask that you make a few initial contributions to demonstrate your intent to continue contributing to AIBrix.
+
+There are a number of ways to contribute to AIBrix:
+
+- Submit PRs (codes or docs)
+- File issues reporting bugs or providing feedback
+- Answer questions on Slack or GitHub issues
+
+When you are ready to join, please send an issue asking adding yourself as a member in the issue.
+
+
+PR process
+----------
+
+Enrich your PR information
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+1. **Provide Clear Descriptions**: Ensure your PR includes a concise yet informative description. Summarize the problem being solved, the approach taken, and any notable changes or additions to the codebase. This helps reviewers quickly understand the purpose of the PR.
+
+2. **Reference Related Issues**: Link to any related issues, discussion threads, or feature requests in the description. Use keywords like Fixes #IssueNumber to automatically close an issue when the PR is merged.
+
+3. **Include Context for Major Changes**: If the PR involves significant changes or refactors, include a brief rationale for why these changes are necessary and how they improve the project.
+
+4. **Document New Features**: If the PR introduces a new feature, ensure that documentation (e.g., README updates, code comments) is included or planned as part of the PR.
+
+5. **Provide Test Coverage**: If applicable, describe the tests you've added to cover the changes in the PR. This helps reviewers assess if the code is robust and if potential edge cases are handled.
+
+6. **Use Clear Commit Messages**: Each commit message should be clear and focused on one change or improvement. Commit titles should describe the change in 50 characters or less, and more details can be added in the commit body.
+
+
+Code Review
+^^^^^^^^^^^
+
+1. **Be Open to Feedback**: Reviewers may suggest improvements, point out bugs, or ask for clarifications. Be open to suggestions, even if you don’t agree initially. Use this as an opportunity to strengthen your code.
+
+2. **Respond Promptly**: Acknowledge feedback with comments explaining how you’ll address the concerns or why a change may not be necessary. Keeping communication clear and respectful helps maintain a productive review process.
+
+3. **Update Your PR Gradually**: Apply changes based on reviewer feedback as soon as possible. Avoid force-pushing updates unless necessary, as this can disrupt the review flow and history tracking.
+
+4. **Clarify Unclear Feedback**: If you’re unsure about a comment, don’t hesitate to ask for clarification before making changes. Miscommunication can lead to unnecessary rework.
+
+5. **Use Suggestions Appropriately**: If the reviewer uses GitHub’s suggestion feature, accept or modify the suggestions as needed, while ensuring the PR remains aligned with the original goal.
+
+6. **Summarize Major Revisions**: If the PR undergoes significant revisions after the initial review, summarize the new changes to give reviewers a clearer understanding of what’s been updated.
+

docs/source/designs/architecture.rst

@@ -1,7 +1,20 @@
 .. _architecture:
 
-====================
-Overall Architecture
-====================
+============
+Architecture
+============
+
+An overview of AIBrix’s architecture
+
+This guide introduces the AIBrix ecosystem and explains how its components integrate into the LLM inference lifecycle.
+
+AIBrix Ecosystem
+----------------
+
+The following diagram gives an overview of the AIBrix Ecosystem and how it relates to the wider Kubernetes and LLM landscapes.
+
+.. figure:: ../assets/images/aibrix-architecture-v1.png
+  :alt: aibrix-architecture-v1
+  :width: 70%
+  :align: center
 
-TODO

docs/source/development/development.rst

@@ -0,0 +1,5 @@
+.. _development:
+
+===========
+Development
+===========

docs/source/development/release.rst

@@ -0,0 +1,113 @@
+.. _release:
+
+=======
+Release
+=======
+
+.. note::
+    This document is for release team only. Feel free to skip it.
+
+This process outlines the steps required to create and publish a release for AIBrix Github project.
+Follow these steps to ensure a smooth and consistent release cycle.
+
+1. Prepare the code
+-----------------------------
+
+Option 1.1: minor version release without prior release candidates
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+For new minor version release like ``v0.1.0``, please checkout a new branch named ``release-0.1``.
+
+.. code-block:: bash
+
+    git checkout -b release-v0.1
+    git fetch origin main
+    git rebase origin/main
+    git push origin release-v0.1
+
+.. note::
+    If origin doesn't points to upstream, let's say you fork the remote, ``upstream`` or other remotes should be right remote to push to.
+
+Option 1.2: minor version release with prior release candidates
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. code-block:: bash
+
+    git checkout release-v0.1
+    git fetch origin main
+    git rebase origin/main
+    git push origin release-v0.1
+
+.. note::
+    If origin doesn't points to upstream, let's say you fork the remote, ``upstream`` or other remotes should be right remote to push to.
+
+Option 2: patch version release
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+For patch version like ``v0.1.1``, please reuse the release branch ``release-0.1``, it should be created earlier from the minor version release.
+for patch release, we do not rebase ``main`` because it will introduce new features. All fixes have to be cherry-picked or cut PR against ``release-0.1`` directly.
+
+.. code-block:: bash
+
+    git checkout release-0.1
+    # not need to push, it should be update to date.
+
+
+Cut a PR
+--------
+
+Make sure the manifest images tags and updated and python version is updated. A sample PR is `Cut v0.1.0-rc.2 release <https://github.com/aibrix/aibrix/pull/226>`_.
+Merge the PR.
+
+.. note::
+    container image actually is not built yet, we preserve the tag name and it would be built later once the tag is created.
+
+
+Create the tag and push to remote
+---------------------------------
+
+.. code-block:: bash
+
+    # make sure you fetch the earlier PR locally
+    git fetch origin release-0.1
+    git rebase origin/release-0.1
+
+    # create the tag
+    git tag v0.1.0
+
+    # push the tag
+    git push origin v0.1.0
+
+Monitor the release pipeline
+----------------------------
+
+After pushing the tag, the release pipeline (e.g., CI/CD workflows) should automatically begin. This may include:
+- Running tests and validations
+- Building manifest artifacts
+- Building container image and push to the registry
+- Building python library and upload to PyPI
+
+Monitor the pipeline's progress to ensure it completes successfully
+
+.. figure:: ../assets/images/release-pipeline-manifests.png
+  :alt: draft-release
+  :width: 70%
+  :align: center
+
+.. figure:: ../assets/images/release-pipeline-python-package.png
+  :alt: draft-release
+  :width: 70%
+  :align: center
+
+Publish the release on Github
+-----------------------------
+
+Release pipeline will cut a draft pre-release in `Github Releases <https://github.com/aibrix/aibrix/releases>`_.
+Go to the "Releases" section in the repository, select the draft release corresponding to the tag you created.
+Include release notes summarizing the changes (new features, bug fixes, breaking changes, etc.).
+Optionally attach binaries, documentation, or other assets. In the end, let's publish the release.
+
+.. figure:: ../assets/images/draft-release.png
+  :alt: draft-release
+  :width: 70%
+  :align: center

docs/source/getting_started/installation.rst

@@ -4,4 +4,50 @@
 Installation
 ============
 
-This section contains how to install the packages.
+This guide describes how to install AIBrix manifests in different platforms.
+
+Currently, AIBrix installation does rely on other cloud specific features. It's fully compatible with vanilla Kubernetes.
+
+
+Install AIBrix on Cloud Kubernetes Clusters
+-------------------------------------------
+
+.. attention::
+    AIBrix will install `Envoy Gateway <https://gateway.envoyproxy.io/>`_ and `KubeRay <https://github.com/ray-project/kuberay>`_ in your environment.
+    If you already have these components installed, you can use corresponding manifest to skip them.
+
+
+Stable Version
+^^^^^^^^^^^^^^
+
+.. code:: bash
+
+    kubectl apply -f https://github.com/aibrix/aibrix/releases/download/v0.1.0-rc.2/aibrix-dependency-v0.1.0-rc.2.yaml
+    kubectl apply -f https://github.com/aibrix/aibrix/releases/download/v0.1.0-rc.2/aibrix-core-v0.1.0-rc.2.yaml
+
+
+Nightly Version
+^^^^^^^^^^^^^^^
+
+.. code:: bash
+
+    # clone the latest repo
+    git clone https://github.com/aibrix/aibrix.git
+    cd aibrix
+
+    # Install component dependencies
+    kubectl create -k config/dependency
+
+    # Install aibrix components
+    kubectl apply -k config/default
+
+
+Install AIBrix on Kind Cluster
+------------------------------
+
+.. attention::
+    Kind itself doesn't support GPU yet. In order to use the kind version with GPU support, feel free to checkout `nvkind <https://github.com/klueska/nvkind>`_.
+
+We use `Lambda Labs <https://lambdalabs.com/>`_ platform to install and test kind based deployment.
+
+TODO