Mike's comments

Signed-off-by: Diego-Castan <diego.castan@ibm.com>

Author: diegocastanibm

CONTRIBUTING.md

@@ -1,8 +1,6 @@
 ## Contributing Guidelines
 
-Thank you for your interest in contributing to llm-d Fast Model Actuation (FMA). Community involvement is highly valued and crucial for the project's growth and success. The FMA project accepts contributions via GitHub pull requests. This outlines the process to help get your contribution accepted.
-
-To ensure a clear direction and cohesive vision for the project, the project leads have the final decision on all contributions. However, these guidelines outline how you can contribute effectively to FMA.
+FMA is currently developed by a small team in a focused development spike. We welcome contributions that align with the project's goals. The FMA project accepts contributions via GitHub pull requests.
 
 ## How You Can Contribute
 
@@ -32,7 +30,7 @@ This project adheres to the llm-d [Code of Conduct and Covenant](CODE_OF_CONDUCT
 
 ## Contributing Process
 
-We follow a **lazy consensus** approach: changes proposed by people with responsibility for a problem, without disagreement from others, within a bounded time window of review by their peers, should be accepted.
+We are a small team with defined responsibilities. All proposals must be reviewed by at least one relevant human reviewer, with broader review expected for changes with particularly wide impact.
 
 ### Types of Contributions
 
@@ -70,13 +68,11 @@ The current testing documentation can be found within the respective components
 * **All code changes** must be submitted as pull requests (no direct pushes)
 * **All changes** must be reviewed and approved by a maintainer other than the author
 * **All repositories** must gate merges on compilation and passing tests
-* **All experimental features** must be off by default and require explicit opt-in
 
 ## Commit and Pull Request Style
 
 * **Pull requests** should describe the problem succinctly
-* **Rebase and squash** before merging
-* **Use minimal commits** and break large changes into distinct commits
+* **Prefer smaller PRs** over larger ones; when a PR adds multiple commits, prefer smaller commits
 * **Commit messages** should have:
   * Short, descriptive titles
   * Description of why the change was needed
@@ -88,43 +84,42 @@ The current testing documentation can be found within the respective components
 
 ## API Changes and Deprecation
 
-* **No breaking changes**: The no-breaking-changes policy will apply once we reach GA
-* **Includes**: All protocols, API endpoints, internal APIs, command line flags/arguments
-* **Exception**: Bug fixes that don't impact significant number of consumers (As the project matures, we will be stricter about such changes - Hyrum's Law is real)
-* **Versioning**: All protocols and APIs should be versionable with clear forward and backward compatibility requirements. A new version may change behavior and fields. For Go modules and Python packages use semver v0.x.x.  For Kubernetes API object types we use the Kubernetes versioning structure and evolution rules
+* **Includes**: All protocols, API endpoints, internal APIs, command line flags/arguments, and Kubernetes API object type (resource) definitions
+* **Versioning**: We use [Semantic Versioning](https://semver.org) at major version 0 for Go modules and Python packages, which grants freedom to make breaking changes. For Kubernetes API object types we use the Kubernetes versioning structure and evolution rules (currently at `v1alpha1`). Since the project has no installed base, we currently make changes without regard to backward compatibility.
 * **Documentation**: All APIs must have documented specs describing expected behavior
 
 ## Testing Requirements
 
 We use two tiers of testing:
 
-1. **Behavioral tests**: Fast verification of code parts, testing different arguments
+1. **Behavioral unit tests**: Fast verification of individual units of code, testing different arguments
    * Best for fast verification of parts of code, testing different arguments
-   * Doesn't cover interactions between code
+   * Does not cover interaction between units of code
 2. **End-to-end (e2e) tests**: Whole system testing including benchmarking
-   * Best for preventing end to end regression and verifying overall correctness
+   * Best for preventing end-to-end regression and verifying overall correctness
    * Execution can be slow
 
-Strong e2e coverage is required for deployed systems to prevent functional regression. Appropriate test coverage is an important part of code review.
+Appropriate test coverage is an important part of code review.
 
 ## Security
 
 Maintain appropriate security mindset for production serving. The project will establish a project email address for responsible disclosure of security issues that will be reviewed by the project maintainers. Prior to the first GA release we will formalize a security component and process. More details on security can be found in the [SECURITY.md](./SECURITY.md) file.
 
 ## Project Structure and Ownership
 
-  The repository contains the following deployable components:
+The repository contains the following deployable components.
 
   | Component | Language | Source | Description |
   |---|---|---|---|
-  | **Dual-Pods Controller** | Go | `cmd/dual-pods-controller/`, `pkg/controller/dual-pods/` | Manages server-providing Pods in reaction to server-requesting Pods. Handles binding, sleep/wake, and readiness relay. |
+  | **Dual-Pods Controller** | Go | `cmd/dual-pods-controller/`, `pkg/controller/dual-pods/` | Manages server-providing Pods (milestone 2) and launched vLLM instances (milestone 3) in reaction to server-requesting Pods. Handles binding, sleep/wake, and readiness relay. |
   | **Launcher-Populator Controller** | Go | `cmd/launcher-populator/`, `pkg/controller/launcher-populator/` | Proactively creates launcher pods on nodes based on `LauncherPopulationPolicy` CRDs. |
   | **Requester** | Go | `cmd/requester/`, `pkg/server/requester/` | Lightweight binary running in server-requesting Pods. Exposes SPI endpoints for GPU info and readiness relay. |
   | **Launcher** | Python | `inference_server/launcher/` | FastAPI service managing multiple vLLM subprocess instances via REST API. |
-  | **Test Requester** | Go | `cmd/test-requester/` | Test binary simulating a requester with GPU allocation. |
+  | **Test Requester** | Go | `cmd/test-requester/` | Test binary simulating a requester (does not use real GPUs). |
   | **Test Server** | Go | `cmd/test-server/` | Test binary simulating a vLLM-like inference server. |
+  | **Test Launcher** | Python | `dockerfiles/Dockerfile.launcher.cpu` | CPU-based launcher image for testing without GPUs. |
 
-  The two controllers are deployed via Helm charts in `charts/`.
+  The two controllers are deployed via a single Helm chart in `charts/fma-controllers/`.
 
 ### Core Organization (`llm-d-incubation/llm-d-fast-model-actuation`)
 
@@ -140,59 +135,44 @@ This is an **incubating component** in the llm-d ecosystem, focused on fast mode
 * **`cmd/`**: Main applications
   * `dual-pods-controller/`: Controller managing server-providing Pods
   * `launcher-populator/`: Controller managing launcher pod population
-  * `requester/`: Example requester application
-  * `test-requester/`: Test requester with GPU allocation
-  * `test-server/`: Test server application
+  * `requester/`: Requester binary for server-requesting Pods
+  * `test-requester/`: Test requester (does not use real GPUs)
+  * `test-server/`: Test binary simulating a vLLM-like inference server
 
 * **`charts/`**: Helm charts for deployment
-  * `dual-pods-controller/`: Helm chart for dual-pods controller
-  * `launcher-populator/`: Helm chart for launcher-populator controller
+  * `fma-controllers/`: Unified Helm chart for both controllers
 
-* **`config/`**: Kubernetes configurations
-  * `crd/`: CRD YAML definitions
-  * `examples/`: Example configurations and deployments
+* **`config/`**: Kubernetes configurations (CRDs, examples, and more — see [cluster-sharing docs](docs/cluster-sharing.md) for recent extensions)
 
 * **`inference_server/`**: Python-based inference server components
   * `launcher/`: vLLM instance launcher (persistent management process)
   * `benchmark/`: Benchmarking tools and scenarios
 
-* **`docs/`**: Documentation
-  * `dual-pods.md`: Dual-pods architecture documentation
-  * `launcher.md`: Launcher component documentation
-  * `e2e-recipe.md`: End-to-end testing guide
-  * `local-test.md`: Local testing instructions
+* **`docs/`**: Documentation (see [`docs/README.md`](docs/README.md) for full index)
 
 * **`test/e2e/`**: End-to-end test scripts
   * `run.sh`: Standard dual-pods E2E test
   * `run-launcher-based.sh`: Launcher-based E2E test
 
 * **`dockerfiles/`**: Container image definitions
-  * `Dockerfile.launcher.cpu`: CPU-based launcher image
-  * `Dockerfile.launcher.benchmark`: Benchmark launcher image
+  * `Dockerfile.launcher.cpu`: CPU-based launcher image for testing without GPUs
+  * `Dockerfile.launcher.benchmark`: GPU-based launcher image (the real deal)
   * `Dockerfile.requester`: Requester application image
 
 ### Component Ownership
 
-* **Maintainers** are listed in the [OWNERS](OWNERS) file. The file follows Kubernetes conventions for future Prow compatibility but is not currently consumed by automation. Additional OWNERS files can be added per-directory as the project grows.
+* **Maintainers** are listed in the [OWNERS](OWNERS) file. The file follows [Kubernetes OWNERS conventions](https://www.kubernetes.dev/docs/guide/owners/) for future Prow compatibility but is not currently consumed by automation. Additional OWNERS files can be added per-directory as the project grows.
 * **Contributors** can become maintainers through consistent, quality contributions
-* Code ownership follows Kubernetes project conventions with OWNERS files
 
 ### Incubation Status
 
 FMA is currently in the **llm-d-incubation** organization, which means:
 
 * **Rapid iteration**: Greater freedom for testing new ideas and approaches
-* **Experimental features**: Components may change significantly as we learn
+* **Components may change significantly** as we learn
 * **Best effort support**: Not yet ready for production use
 * **Graduation path**: Working toward integration with core llm-d components
 
-### Graduation Criteria
-
-To graduate to the core `llm-d` organization, FMA must demonstrate:
+### Graduation
 
-1. **Stability**: Proven reliability in test environments
-2. **Performance**: Measurable improvements in model actuation speed
-3. **Documentation**: Complete user and developer documentation
-4. **Testing**: Comprehensive unit, integration, and E2E test coverage
-5. **Community adoption**: Active use and feedback from early adopters
-6. **API maturity**: Stable APIs ready for production use
+Graduation criteria are defined by the llm-d organization (not this repo). This repo tracks its progress toward meeting those criteria. See the llm-d organization documentation for details.

PR_SIGNOFF.md

@@ -1,14 +1,6 @@
 # Git Commit Signoff and Signing
 
-**NOTE**: "sign-off" is different from "signing" a commit.  The former
-indicates your assent to the repository's terms for contributors, the
-latter adds a cryptographic signature that is rarely displayed.  See
-[the git
-book](https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work)
-about signing. For commit signoff, do a web search on `git
-signoff`. GitHub has a concept of [a commit being
-"verified"](https://docs.github.com/en/authentication/managing-commit-signature-verification)
-that extends the Git concept of signing.
+**NOTE:** "DCO sign-off" is different from commit "signing". The former affirms your compliance with the DCO, while the latter adds a cryptographic signature that is rarely displayed. See [the git book](https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work) about signing. For commit signoff, do a web search on `git signoff`. GitHub has a concept of [a commit being "verified"](https://docs.github.com/en/authentication/managing-commit-signature-verification) that extends the Git concept of signing.
 
 In order to get a pull request approved, you must first complete a DCO
 sign-off for each commit that the request is asking to add to the
@@ -20,8 +12,7 @@ repository](https://github.com/llm-d/llm-d/blob/main/DCO). In
 the case of an individual, DCO sign-off is accomplished by doing a Git
 "sign-off" on the commit.
 
-We prefer that commits contributed to this repository be signed and
-GitHub verified, but this is not strictly necessary or enforced.
+Commits contributed to this repository must be signed and GitHub verified, as enforced by the [signed commits CI check](.github/workflows/ci-signed-commits.yaml).
 
 ## Commit Sign-off