github-starred/conventionalcommits.org
2
0
Fork 0
mirror of https://github.com/conventional-commits/conventionalcommits.org.git synced 2026-03-22 12:44:37 -05:00
Code Issues 153 Packages Projects Releases Wiki Activity

[PR #677] feat: add experiment type #653

New Issue
Open
opened 2026-02-17 12:11:06 -06:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-02-17 12:11:06 -06:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/conventional-commits/conventionalcommits.org/pull/677
Author: @shiraz
Created: 12/18/2025
Status: 🔄 Open

Base: master ← Head: master

📝 Commits (1)

  • 5087b49 feat: add experiment type

📊 Changes

2 files changed (+12 additions, -2 deletions)

View changed files

📝 content/next/index.md (+6 -1)
📝 content/v1.0.0/index.md (+6 -1)

📄 Description

Add experiment Commit Type

Problem

Developers frequently create POCs and experimental features deployed to preview environments (Vercel Preview, Netlify Deploy Previews, etc.) for stakeholder testing. These commits may never be merged to master or released to production, but are currently labeled with feat: or chore:, which can be misleading.

Solution

Add experiment: as a recommended commit type to clearly distinguish experimental work, POCs, and testing implementations from production-ready features.

Use Cases

  • POCs: Experimental features deployed to preview environments for stakeholder evaluation
  • Testing & Analysis: Commits for testing purposes, performance analysis, or A/B testing
  • Stakeholder Review: Features deployed to preview environments where stakeholders can test before production decisions

Benefits

  • Clear intent: immediately identifies experimental vs production-ready work
  • Better tooling: enables automated tools to filter/handle experimental commits differently
  • Improved workflow: helps teams distinguish experimental work in commit history
  • Semantic clarity: "experiment" clearly stands out from other types

Example

experiment: try new caching strategy for API responses

experiment(ui): test new dashboard layout for stakeholder review

Notes

This is my first contribution to this repository. Happy to make any adjustments as needed!

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/conventional-commits/conventionalcommits.org/pull/677 **Author:** [@shiraz](https://github.com/shiraz) **Created:** 12/18/2025 **Status:** 🔄 Open **Base:** `master` ← **Head:** `master` --- ### 📝 Commits (1) - [`5087b49`](https://github.com/conventional-commits/conventionalcommits.org/commit/5087b490286d3a1652cdb008aa9d4e742a30cd65) feat: add experiment type ### 📊 Changes **2 files changed** (+12 additions, -2 deletions) <details> <summary>View changed files</summary> 📝 `content/next/index.md` (+6 -1) 📝 `content/v1.0.0/index.md` (+6 -1) </details> ### 📄 Description ## Add `experiment` Commit Type ### Problem Developers frequently create POCs and experimental features deployed to preview environments (Vercel Preview, Netlify Deploy Previews, etc.) for stakeholder testing. These commits may never be merged to master or released to production, but are currently labeled with `feat:` or `chore:`, which can be misleading. ### Solution Add `experiment:` as a recommended commit type to clearly distinguish experimental work, POCs, and testing implementations from production-ready features. ### Use Cases - **POCs**: Experimental features deployed to preview environments for stakeholder evaluation - **Testing & Analysis**: Commits for testing purposes, performance analysis, or A/B testing - **Stakeholder Review**: Features deployed to preview environments where stakeholders can test before production decisions ### Benefits - Clear intent: immediately identifies experimental vs production-ready work - Better tooling: enables automated tools to filter/handle experimental commits differently - Improved workflow: helps teams distinguish experimental work in commit history - Semantic clarity: "experiment" clearly stands out from other types ### Example `experiment: try new caching strategy for API responses` `experiment(ui): test new dashboard layout for stakeholder review` ### Notes This is my first contribution to this repository. Happy to make any adjustments as needed! --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-02-17 12:11:06 -06:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
discussion
enhancement
greenkeeper
help wanted
meeting-agenda
operations
process
pull-request
Mirrored from GitHub Pull Request
 question
suggestion
support
triaged
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#653
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?