Skip to content

docs: redefine and clarify feature stages #18416

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

EdwardAngert
Copy link
Contributor

@EdwardAngert EdwardAngert commented Jun 17, 2025

Summary

Edit the feature stages doc to define and clarify each stage both for Coder users and internally.

Specifically:

  • product: deciding what a feature is and when it feature graduates or is removed
  • engineering: tagging and communicating risk (for any stage - esp. since this now introduces the idea of deprecation)
  • support: customer expectations and SLAs
  • docs: everywhere

in pr/in progress

  • added "experiment (hidden)" and "legacy (deprecated)" rows
  • draft deprecation policy modeled after GitLab/GitHub

todo

  • define graduation criteria?
  • add an “Enabled by default?” column or list item for each

help wanted

  • check wording. this effectively states policy
  • ☝️ ensure scopes of support align with intention and SLA
  • Legacy/deprecation language and intent

@EdwardAngert EdwardAngert requested a review from bpmct June 17, 2025 20:17
@EdwardAngert EdwardAngert self-assigned this Jun 17, 2025
@EdwardAngert EdwardAngert added the docs Area: coder.com/docs label Jun 17, 2025
@EdwardAngert EdwardAngert requested review from matifali, Kira-Pilot, bpmct and stirby and removed request for bpmct June 17, 2025 20:26
Copy link
Member

@matifali matifali left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a few comments and queries.

Comment on lines +17 to +18
| [Beta](#beta) | No | Not fully | Documentation</br>Discord</br>GitHub | Publicly available on an opt-in basis. In active development with minor bugs. Suitable for staging; optional for production. Not covered by SLA. |
| [GA](#general-availability-ga) | Yes | Yes | License-based / SLA | Stable and tested. Enabled by default. Fully documented. Support based on license. |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do not need to repeat support in the Description column, since we already have a separate Support column.

Comment on lines +16 to +18
| [Early Access](#early-access-features) | No | No | Limited documentation</br>GitHub issues | For staging only. Functional, but not feature-complete or stable.</br>Disabled by default. |
| [Beta](#beta) | No | Not fully | Documentation</br>Discord</br>GitHub | Publicly available on an opt-in basis. In active development with minor bugs. Suitable for staging; optional for production. Not covered by SLA. |
| [GA](#general-availability-ga) | Yes | Yes | License-based / SLA | Stable and tested. Enabled by default. Fully documented. Support based on license. |
Copy link
Member

@matifali matifali Jun 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should mention Discord, GitHub, and Documentation as support channels for GA features, at least for the OSS community.

because they might cause performance or stability issues. Early access features
can be mostly feature-complete, but require further internal testing and remain
in the early access stage for at least one month.
Coder sometimes releases early access features that are available for use, but are disabled by default.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Coder sometimes releases early access features that are available for use, but are disabled by default.
Coder sometimes releases early access features that are available for use, but are opt-in by default.

Some features are not disabled by default but require opt-in, such as Presets and the upcoming Secrets. We will likely not hide them behind a flag and provide an early access status within the product and documentation through labels.


<details><summary>To enable early access features:</summary>

Use the [Coder CLI](../../install/cli.md) `--experiments` flag to enable early
access features:
Use the [Coder CLI](../../install/cli.md) `--experiments` flag to enable early access features:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not a hard requirement to gate all early access features behind feature flags.

I see that we are adding a new category for experimental features that could also qualify as EA.

some features may be incomplete.
Beta features are often ready for general availability within two-three releases.
You should test beta features in staging environments.
You can use beta features in production, but should set expectations and inform users that some features may be incomplete.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We now try to complete features in Beta and only do polishing and bug fixes in the GA phase. So saying that they may be comparable feature-wise would be incorrect.

already. Customers with a valid Coder license, can submit a support request or
contact your [account team](https://coder.com/contact).
For support, consult our knowledgeable and growing community on [Discord](https://discord.gg/coder), or create a
[GitHub issue](https://github.com/coder/coder/issues) if one doesn't exist already.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
[GitHub issue](https://github.com/coder/coder/issues) if one doesn't exist already.
[GitHub issue](https://github.com/coder/coder/issues/new/choose) if one doesn't exist already.

suggestion that could improve the documentation, please
We intend [Coder documentation](../../README.md) to be the [single source of truth](https://en.wikipedia.org/wiki/Single_source_of_truth)
and all features should have some form of complete documentation that outlines how to use or implement a feature.
If you discover an error or if you have a suggestion that could improve the documentation, please
[submit a GitHub issue](https://github.com/coder/internal/issues/new?title=request%28docs%29%3A+request+title+here&labels=["customer-feedback","docs"]&body=please+enter+your+request+here).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we asking for feedback on the internal repo? We should use the coder/coder repo issues or GitHub Discussions.

Comment on lines +141 to +142
## Legacy (Deprecated)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should add Product labels and docs labels to all deprecated features.
There are a few deprecated API endpoints listed in the API docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Area: coder.com/docs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants