Add community section

docs/.vitepress/config.mts

@@ -31,13 +31,14 @@ export default withMermaid({
     // https://vitepress.dev/reference/default-theme-config
     nav: [
       {text: 'Home', link: '/'},
-      {text: 'Overview', link: '/overview'},
+      {text: 'Overview', link: '/overview/'},
       {text: 'Documentation',
       items: [
         {text: 'Infrastructure as a Service', link: '/iaas/getting-started'},
         {text: 'Bare Metal Management', link: '/baremetal/'},
         {text: 'Network Automation', link: '/network-automation/'},
       ]},
+      {text: 'Community', link: '/community/'},
     ],
 
     editLink: {
@@ -169,6 +170,23 @@ export default withMermaid({
         text: 'Overview', link: '/network-automation/',
       },
     ],
+    '/community/': [
+      {
+        text: 'Community',
+        items: [
+          { text: 'Welcome', link: '/community/' },
+          { text: 'Contributing Guide', link: '/community/contributing' },
+        ],
+      },
+      {
+        text: 'Style Guide',
+        collapsed: false,
+        items: [
+          { text: 'Coding', link: '/community/style-guide/coding' },
+          { text: 'Documentation', link: '/community/style-guide/documentation' },
+        ],
+      },
+    ],
     },
     socialLinks: [
       {

docs/community/contributing.md

@@ -0,0 +1,127 @@
+# Contributing to IronCore
+
+Welcome to the IronCore contributor guide! Whether you're fixing a typo, reporting a bug, or building a new feature,
+your contributions are welcome at any time. This guide applies to all repositories under the
+[ironcore-dev](https://github.com/ironcore-dev) GitHub organization.
+
+## Prerequisites
+
+Before your first contribution, please complete the following:
+
+1. **Create a [GitHub account](https://github.com/signup)** if you don't already have one.
+2. **Sign the [Developer Certificate of Origin (DCO)](https://developercertificate.org/)** — all commits must be
+   signed off (`git commit -s`) to certify that you wrote the code or have the right to submit it. This is checked
+   automatically on every pull request.
+3. **Read our [Code of Conduct](https://events.linuxfoundation.org/about/code-of-conduct/)** — we follow the
+   Linux Foundation Code of Conduct and are committed to providing a welcoming and respectful community for everyone.
+
+## Find Something to Work On
+
+Not sure where to start? Here are a few ways to find your first contribution:
+
+- **Browse [`good first issue`](https://github.com/search?q=org%3Aironcore-dev+label%3A%22good+first+issue%22+state%3Aopen&type=issues)
+  labels** — these are issues where maintainers have committed to providing extra guidance.
+- **Look for [`help wanted`](https://github.com/search?q=org%3Aironcore-dev+label%3A%22help+wanted%22+state%3Aopen&type=issues)
+  labels** — these are issues open for community contribution.
+- **Improve documentation** — clarify existing docs, fix typos, or add missing content. See the
+  [documentation conventions](/community/style-guide/documentation) in the style guide.
+- **Report a bug** — if you've found an issue, open a GitHub issue with steps to reproduce it.
+- **Propose a feature** — open an issue to discuss your idea before starting implementation.
+
+**Tip:** Before working on a larger change, open an issue first to discuss your approach with the maintainers. This
+avoids unnecessary work and helps align your contribution with the project's direction.
+
+## Making a Contribution
+
+### 1. Fork and Clone
+
+Fork the repository you want to contribute to and clone it locally:
+
+```shell
+git clone git@github.com:<your-username>/<repository>.git
+cd <repository>
+```
+
+### 2. Create a Branch
+
+Create a feature branch from `main`:
+
+```shell
+git checkout -b my-feature
+```
+
+If needed, rebase to the current `main` before submitting your pull request:
+
+```shell
+git fetch upstream main
+git rebase upstream/main
+```
+
+### 3. Make Your Changes
+
+- Follow the [coding](/community/style-guide/coding) and [documentation](/community/style-guide/documentation) style guides for code, testing, and documentation standards.
+- Keep commits small and focused — each commit should be correct independently.
+- Write clear [commit messages](/community/style-guide/coding#commit-messages) that explain *why*, not just *what*.
+- Include tests for any new functionality or bug fix.
+- Sign off every commit for DCO compliance:
+
+```shell
+git commit -s -m "Add support for feature X"
+```
+
+### 4. Submit a Pull Request
+
+Push your branch and open a pull request against `main`:
+
+```shell
+git push origin my-feature
+```
+
+In your pull request description:
+- Explain what the change does and why it's needed.
+- Reference any related issues (e.g., `Fixes #123`).
+- Tag a relevant maintainer if you need a specific reviewer — check the `CODEOWNERS` file in the repository.
+
+### 5. Run Checks
+
+Before submitting, run the project's checks locally to catch issues early. See
+[Running tests](/community/style-guide/coding#running-tests) in the coding style guide for details:
+
+```shell
+make test          # Unit and integration tests
+make lint          # Linter checks
+make verify        # Code generation and manifests are up to date
+```
+
+## Code Review
+
+All contributions go through code review before merging. Here's what to expect:
+
+- **A maintainer will review your PR** and may request changes. This is normal — reviews improve code quality for
+  everyone.
+- **Address feedback** by pushing additional commits or amending existing ones.
+- **Mark resolved comments** as resolved in GitHub and leave a comment when your changes are ready for another look.
+
+Reviews are a collaborative process. Don't hesitate to ask questions or push back if you disagree with feedback —
+respectful discussion leads to better outcomes.
+
+## Reporting Issues
+
+We use GitHub issues to track bugs and feature requests. When opening an issue:
+
+- Check if a similar issue already exists.
+- Provide enough context to understand and reproduce the problem.
+- Use the issue templates provided in each repository when available.
+
+## Licensing
+
+All contributions to IronCore projects are licensed under the
+[Apache 2.0 License](http://www.apache.org/licenses/LICENSE-2.0).
+
+## Need Help?
+
+- Ask questions on any issue or pull request — maintainers are happy to help.
+- Join our [Slack workspace](https://join.slack.com/t/ironcore-dev/shared_invite/zt-3o0qo3j90-pbqV0io1B~Z~LqeAp4n2Vg)
+  to chat with the community.
+
+Thank you for contributing to IronCore!

docs/community/index.md

@@ -0,0 +1,30 @@
+# Welcome to the IronCore Community!
+
+IronCore is an open-source project built by and for the community. Whether you're a developer, system administrator,
+or infrastructure enthusiast, there are many ways to get involved, ask questions, and contribute to the project.
+
+## Get Connected
+
+### Slack
+
+Join our [Slack workspace](https://join.slack.com/t/ironcore-dev/shared_invite/zt-3o0qo3j90-pbqV0io1B~Z~LqeAp4n2Vg) to chat
+with maintainers and other community members. It's the best place to ask questions, share ideas, and get help with IronCore.
+
+### GitHub
+
+All IronCore development happens in the open on [GitHub](https://github.com/ironcore-dev). You can:
+
+- Browse the source code and documentation
+- Report bugs or request features by opening an [issue](https://github.com/ironcore-dev/ironcore/issues)
+- Follow the project's development and roadmap
+
+## Contribute
+
+We welcome contributions of all kinds — from code and documentation to bug reports and feature ideas. If you'd like to
+get started, check out our [Contributing Guide](/community/contributing), [Coding Style Guide](/community/style-guide/coding),
+and [Documentation Style Guide](/community/style-guide/documentation).
+
+## Code of Conduct
+
+The IronCore community is committed to providing a welcoming and inclusive environment for everyone. We expect all
+participants to treat each other with respect and professionalism.

docs/community/style-guide/coding.md

@@ -0,0 +1,171 @@
+# Coding Style Guide
+
+This style guide defines the conventions for contributing code and tests across all IronCore projects.
+Following these standards ensures consistency and helps maintainers review contributions efficiently.
+
+## Code Style
+
+### Go Conventions
+
+All IronCore projects are written in Go. We follow the standard Go style guides as our baseline:
+
+- [Effective Go](https://go.dev/doc/effective_go) — the foundational language guide.
+- [Go Code Review Comments](https://go.dev/wiki/CodeReviewComments) — the de facto standard for code reviews.
+
+The rules below supplement these upstream guides with IronCore-specific conventions. Do not duplicate what is already
+covered upstream — read those guides first.
+
+### Formatting
+
+- Run `gofmt` (or `goimports`) on all code before committing. This is non-negotiable.
+- Use your editor or a pre-commit hook to automate formatting.
+
+### Naming
+
+- Follow Go naming conventions: `MixedCaps` for exported identifiers, `mixedCaps` for unexported ones. Never use
+  underscores in Go names.
+- Keep initialisms consistent: `URL` not `Url`, `ID` not `Id`, `HTTP` not `Http`.
+- Use descriptive package names. Avoid generic names like `util`, `common`, `helpers`, or `misc`.
+- Controller and reconciler types should clearly indicate the resource they manage
+  (e.g., `MachineReconciler`, `VolumeController`).
+
+### Imports
+
+Organize imports into three groups separated by blank lines:
+
+```go
+import (
+    // Standard library
+    "context"
+    "fmt"
+
+    // Third-party packages
+    "sigs.k8s.io/controller-runtime/pkg/client"
+
+    // IronCore packages
+    "github.com/ironcore-dev/ironcore/api/compute/v1alpha1"
+)
+```
+
+Avoid renaming imports unless there is a name collision.
+
+### Error Handling
+
+- Never discard errors with `_`. Handle every error or explicitly document why it is safe to ignore.
+- Return errors as the last return value. Handle errors early and return — keep the happy path at minimal indentation.
+- Use lowercase error strings without trailing punctuation: `fmt.Errorf("failed to create machine")`.
+- Wrap errors with context: `fmt.Errorf("reconciling machine %s: %w", name, err)`.
+
+### Comments
+
+- Write comments that explain *why*, not *what*. The code itself shows what it does.
+- Comments on exported identifiers become godoc — start with the identifier name and write complete sentences.
+- If reviewers ask questions about why code is written a certain way, that is a sign that a comment would help.
+
+### Logging
+
+- Use structured logging consistently. Prefer key-value pairs over formatted strings.
+- Use appropriate log levels:
+    - **Error** — the reconciler cannot proceed; requires attention.
+    - **Info** — significant events (resource created, deleted, reconciled).
+    - **Debug/V(1)** — detailed information useful for troubleshooting.
+
+### Linting
+
+All projects should use [golangci-lint](https://golangci-lint.run/) with the project's `.golangci.yml` configuration.
+Run linters locally before pushing:
+
+```shell
+make lint
+```
+
+## Testing
+
+Good tests are as important as good code. Tests protect against regressions, document expected behavior, and give
+reviewers confidence that changes work correctly.
+
+### Testing Pyramid
+
+IronCore projects use three levels of testing:
+
+| Level | Purpose | Tools |
+| --- | --- | --- |
+| **Unit tests** | Test individual functions and methods in isolation. | Go standard `testing` package |
+| **Integration tests** | Test controllers against a real API server using envtest. | [controller-runtime envtest](https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/envtest) |
+| **End-to-end tests** | Test the full system with real components deployed. | [Ginkgo](https://onsi.github.io/ginkgo/) + [Gomega](https://onsi.github.io/gomega/) |
+
+### Writing Tests
+
+- **Table-driven tests** are the preferred pattern for unit tests with multiple input/output cases:
+
+```go
+func TestValidateMachineName(t *testing.T) {
+    tests := []struct {
+        name    string
+        input   string
+        wantErr bool
+    }{
+        {name: "valid name", input: "my-machine", wantErr: false},
+        {name: "empty name", input: "", wantErr: true},
+        {name: "name with spaces", input: "my machine", wantErr: true},
+    }
+    for _, tt := range tests {
+        t.Run(tt.name, func(t *testing.T) {
+            err := ValidateMachineName(tt.input)
+            if (err != nil) != tt.wantErr {
+                t.Errorf("ValidateMachineName(%q) error = %v, wantErr %v", tt.input, err, tt.wantErr)
+            }
+        })
+    }
+}
+```
+
+- **Test names** should be descriptive and specific. Use the pattern `Test<Function>_<scenario>` for unit tests.
+- **Assertions** in Ginkgo/Gomega tests should use matchers, not boolean checks:
+
+| Do | Don't |
+| --- | --- |
+| `Expect(pod.Status.Phase).To(Equal(corev1.PodRunning))` | `Expect(pod.Status.Phase == corev1.PodRunning).To(BeTrue())` |
+
+- **Failure messages** must be actionable. Include what was expected, what was received, and enough context to debug
+  without re-running:
+
+| Do | Don't |
+| --- | --- |
+| `"expected Machine %s to be in Running phase, got %s"` | `"wrong phase"` |
+
+### Test Reliability
+
+- Tests must be deterministic. A test that passes 99% of the time is unreliable in CI.
+- Use `gomega.Eventually` for polling conditions instead of `time.Sleep`.
+- Clean up resources after tests. Use `DeferCleanup` in Ginkgo or `t.Cleanup` in standard tests.
+- Keep tests fast. Unit tests should complete in seconds; integration tests in under two minutes.
+
+### Running Tests
+
+Before submitting a pull request, run the full test suite locally:
+
+```shell
+make test          # Unit and integration tests
+make lint          # Linter checks
+make verify        # Code generation and manifests are up to date
+```
+
+## Commit Messages
+
+- **Subject line**: imperative mood, max 72 characters, capitalize the first word, no trailing period.
+- **Body**: wrap at 72 characters, explain *what* and *why*, separate from the subject with a blank line.
+- Reference related issues: `Fixes #123` or `Relates to #456`.
+
+| Do | Don't |
+| --- | --- |
+| `Add volume snapshot support` | `Added volume snapshot support` |
+| `Fix nil pointer in machine reconciler` | `fixed stuff` |
+
+## Pull Requests
+
+- Keep pull requests small and focused — one logical change per PR.
+- Separate bug fixes from refactoring from new features.
+- Include tests for any new functionality or bug fix.
+- Ensure all CI checks pass before requesting review.
+- Write a clear PR description explaining what changed and why.