fix: labels for experiments

.github/workflows/issue-experiment.yml

@@ -6,7 +6,7 @@ on:
 
 jobs:
   issue-experiment-proposed:
-    if: github.event.label.name == format('experiment{0} proposed', ':')
+    if: github.event.label.name == format('status{0} proposed', ':')
     runs-on: ubuntu-latest
     steps:
       - uses: actions/github-script@v7
@@ -20,7 +20,7 @@ jobs:
               body: 'This issue has been marked as an experiment proposal! :test_tube: It will now enter a period of consultation during which we encourage the community to provide feedback on the proposed design. Please see the [experiment workflow documentation](https://taskfile.dev/experiments#workflow) for more information on how we release experiments.'
             })
   issue-experiment-draft:
-    if: github.event.label.name == format('experiment{0} draft', ':')
+    if: github.event.label.name == format('status{0} draft', ':')
     runs-on: ubuntu-latest
     steps:
       - uses: actions/github-script@v7
@@ -34,7 +34,7 @@ jobs:
               body: 'This experiment has been marked as a draft! :sparkles: This means that an initial implementation has been added to the latest release of Task! You can find information about this experiment and how to enable it in our [experiments documentation](https://taskfile.dev/experiments). Please see the [experiment workflow documentation](https://taskfile.dev/experiments#workflow) for more information on how we release experiments.'
             })
   issue-experiment-candidate:
-    if: github.event.label.name == format('experiment{0} candidate', ':')
+    if: github.event.label.name == format('status{0} candidate', ':')
     runs-on: ubuntu-latest
     steps:
       - uses: actions/github-script@v7
@@ -48,7 +48,7 @@ jobs:
               body: 'This experiment has been marked as a candidate! :fire: This means that the  implementation is nearing completion and we are entering a period for final comments and feedback! You can find information about this experiment and how to enable it in our [experiments documentation](https://taskfile.dev/experiments). Please see the [experiment workflow documentation](https://taskfile.dev/experiments#workflow) for more information on how we release experiments.'
             })
   issue-experiment-stable:
-    if: github.event.label.name == format('experiment{0} stable', ':')
+    if: github.event.label.name == format('status{0} stable', ':')
     runs-on: ubuntu-latest
     steps:
       - uses: actions/github-script@v7
@@ -62,7 +62,7 @@ jobs:
               body: 'This experiment has been marked as stable! :metal: This means that the  implementation is now final and ready to be released. No more changes will be made and the experiment is safe to use in production! You can find information about this experiment and how to enable it in our [experiments documentation](https://taskfile.dev/experiments). Please see the [experiment workflow documentation](https://taskfile.dev/experiments#workflow) for more information on how we release experiments.'
             })
   issue-experiment-released:
-    if: github.event.label.name == format('experiment{0} released', ':')
+    if: github.event.label.name == format('status{0} released', ':')
     runs-on: ubuntu-latest
     steps:
       - uses: actions/github-script@v7
@@ -82,7 +82,7 @@ jobs:
               state: 'closed'
             })
   issue-experiment-abandoned:
-    if: github.event.label.name == format('experiment{0} abandoned', ':')
+    if: github.event.label.name == format('status{0} abandoned', ':')
     runs-on: ubuntu-latest
     steps:
       - uses: actions/github-script@v7
@@ -102,7 +102,7 @@ jobs:
               state: 'closed'
             })
   issue-experiment-superseded:
-    if: github.event.label.name == format('experiment{0} superseded', ':')
+    if: github.event.label.name == format('status{0} superseded', ':')
     runs-on: ubuntu-latest
     steps:
       - uses: actions/github-script@v7

website/docs/experiments/experiments.mdx

@@ -96,11 +96,11 @@ Task.
 All experimental features start with a proposal in the form of a GitHub issue.
 If the maintainers decide that an issue has enough support and is a breaking
 change or is complex/controversial enough to require user feedback, then the
-issue will be marked with the `experiment: proposal` label. At this point, the
+issue will be marked with the `status: proposal` label. At this point, the issue
-issue becomes a proposal and a period of consultation begins. During this
+becomes a proposal and a period of consultation begins. During this period, we
-period, we request that users provide feedback on the proposal and how it might
+request that users provide feedback on the proposal and how it might effect
-effect their use of Task. It is up to the discretion of the maintainers to
+their use of Task. It is up to the discretion of the maintainers to decide how
-decide how long this period lasts.
+long this period lasts.
 
 ### 2. Draft
 
@@ -108,9 +108,9 @@ Once a proposal's consultation ends, a contributor may pick up the work and
 begin the initial implementation. Once a PR is opened, the maintainers will
 ensure that it meets the requirements for an experimental feature (i.e. flags
 are in the right format etc) and merge the feature. Once this code is released,
-the status will be updated via the `experiment: draft` label. This indicates
+the status will be updated via the `status: draft` label. This indicates that an
-that an implementation is now available for use in a release and the experiment
+implementation is now available for use in a release and the experiment is open
-is open for feedback.
+for feedback.
 
 :::note
 
@@ -124,13 +124,13 @@ experimental features may be abandoned _at any time_.
 
 Once an acceptable level of consensus has been reached by the community and
 feedback/changes are less frequent/significant, the status may be updated via
-the `experiment: candidate` label. This indicates that a proposal is _likely_ to
+the `status: candidate` label. This indicates that a proposal is _likely_ to
 accepted and will enter a period for final comments and minor changes.
 
 ### 4. Stable
 
 Once a suitable amount of time has passed with no changes or feedback, an
-experiment will be given the `experiment: stable` label. At this point, the
+experiment will be given the `status: stable` label. At this point, the
 functionality will be treated like any other feature in Task and any changes
 _must_ be backward compatible. This allows users to migrate to the new
 functionality without having to worry about anything breaking in future
@@ -139,14 +139,13 @@ version.
 
 ### 5. Released
 
-When making a new major release of Task, all experiments marked as
+When making a new major release of Task, all experiments marked as `status:
-`experiment: stable` will move to `experiment: released` and their behaviors
+stable` will move to `status: released` and their behaviors will become the new
-will become the new default in Task. Experiments in an earlier stage (i.e. not
+default in Task. Experiments in an earlier stage (i.e. not stable) cannot be
-stable) cannot be released and so will continue to be experiments in the new
+released and so will continue to be experiments in the new version.
-version.
 
 ### Abandoned / Superseded
 
-If an experiment is unsuccessful at any point then it will be given the
+If an experiment is unsuccessful at any point then it will be given the `status:
-`experiment: abandoned` or `experiment: superseded` labels depending on which is
+abandoned` or `status: superseded` labels depending on which is more suitable.
-more suitable. These experiments will be removed from Task.
+These experiments will be removed from Task.

website/versioned_docs/version-latest/experiments/experiments.mdx

@@ -96,11 +96,11 @@ Task.
 All experimental features start with a proposal in the form of a GitHub issue.
 If the maintainers decide that an issue has enough support and is a breaking
 change or is complex/controversial enough to require user feedback, then the
-issue will be marked with the `experiment: proposal` label. At this point, the
+issue will be marked with the `status: proposal` label. At this point, the issue
-issue becomes a proposal and a period of consultation begins. During this
+becomes a proposal and a period of consultation begins. During this period, we
-period, we request that users provide feedback on the proposal and how it might
+request that users provide feedback on the proposal and how it might effect
-effect their use of Task. It is up to the discretion of the maintainers to
+their use of Task. It is up to the discretion of the maintainers to decide how
-decide how long this period lasts.
+long this period lasts.
 
 ### 2. Draft
 
@@ -108,9 +108,9 @@ Once a proposal's consultation ends, a contributor may pick up the work and
 begin the initial implementation. Once a PR is opened, the maintainers will
 ensure that it meets the requirements for an experimental feature (i.e. flags
 are in the right format etc) and merge the feature. Once this code is released,
-the status will be updated via the `experiment: draft` label. This indicates
+the status will be updated via the `status: draft` label. This indicates that an
-that an implementation is now available for use in a release and the experiment
+implementation is now available for use in a release and the experiment is open
-is open for feedback.
+for feedback.
 
 :::note
 
@@ -124,13 +124,13 @@ experimental features may be abandoned _at any time_.
 
 Once an acceptable level of consensus has been reached by the community and
 feedback/changes are less frequent/significant, the status may be updated via
-the `experiment: candidate` label. This indicates that a proposal is _likely_ to
+the `status: candidate` label. This indicates that a proposal is _likely_ to
 accepted and will enter a period for final comments and minor changes.
 
 ### 4. Stable
 
 Once a suitable amount of time has passed with no changes or feedback, an
-experiment will be given the `experiment: stable` label. At this point, the
+experiment will be given the `status: stable` label. At this point, the
 functionality will be treated like any other feature in Task and any changes
 _must_ be backward compatible. This allows users to migrate to the new
 functionality without having to worry about anything breaking in future
@@ -139,14 +139,13 @@ version.
 
 ### 5. Released
 
-When making a new major release of Task, all experiments marked as
+When making a new major release of Task, all experiments marked as `status:
-`experiment: stable` will move to `experiment: released` and their behaviors
+stable` will move to `status: released` and their behaviors will become the new
-will become the new default in Task. Experiments in an earlier stage (i.e. not
+default in Task. Experiments in an earlier stage (i.e. not stable) cannot be
-stable) cannot be released and so will continue to be experiments in the new
+released and so will continue to be experiments in the new version.
-version.
 
 ### Abandoned / Superseded
 
-If an experiment is unsuccessful at any point then it will be given the
+If an experiment is unsuccessful at any point then it will be given the `status:
-`experiment: abandoned` or `experiment: superseded` labels depending on which is
+abandoned` or `status: superseded` labels depending on which is more suitable.
-more suitable. These experiments will be removed from Task.
+These experiments will be removed from Task.