Proposing 'custom status states' for issues via bd config

[cpdata]

I was reviewing issue #341 posted by @ejconlon and I think his recommendation for adding a status for "review" is a good idea and it got me thinking about the potential for adding custom status states that could be added by the user.

I'm curious about the implications of making issue status options expandable by users adding custom status states by enabling them to add additional allowed statuses via bd config.

That way users using or building multi-step pipelines to process issues (where each step of their issue processing pipeline correlates to a specified issue status) can define an optional issue status enum as a comma separated string saved in the db config table. (i.e. Table: config by adding issue.status.enum = awaiting_review, review_in_progress, awaiting_merge, merge_in_progress ) This could default to additional statuses to the existing ones ie. open, in_progress, closed, etc. OR another config such as use.default.issue.statuses = true for if to include the default statuses. (I anticipate that that may be problematic, I'm just tossing up the idea.)

This would enable various teams/collaborators or their agents (which may be configured for performing certain operations on specific issue states) to claim issues based on issue status signaling the issue is in a state that is ready for their domain or step of the user's issue processing pipeline.

I'm thinking along the lines of an issue processing pipeline where each step transition would need to signal that the issue is in some form awaiting its next step therefore awaiting_<next_step>.

Some custom awaiting_<next_step> status examples :

• awaiting_verification
• awaiting_docs
• awaiting_testing
• awaiting_human_review
• awaiting_agent_review
• awaiting_merge

Furthermore additional statuses could be used to indicate which process or pipeline step is currently working on an issue with statuses similar to in_progress therefore <process_step>_in_progress.

Some custom <process_step>_in_progress status examples :

• verification_in_progress
• docs_in_progress
• testing_in_progress
• human_review_in_progress
• agent_review_in_progress
• merge_in_progress

Need for 'custom status states'

As one might imagine there could be any number and variation of potential status+state scenarios that users may need for their unique workflows.

Benefit of 'custom status states'

Adding custom status state would enable more flexibility in how users may use beads along with clearer implementation intent when designing systems that integrate beads for issue tracking (such as multi-step issue processing pipelines or agent orchestrators).

Being able to define custom status states for issues would allow for beads to also track each issues status and issue state with expandable to any arbitrary number of status/states. Instead of needing to add additional logic for handling a new 'state' field this would allow storing the state with the status using just the status field (thus minimizing additional re-work).

How I would actually use this

I'm currently building a multi-step issue processing pipeline that uses beads for issue tracking and a custom orchestration flow to process various aspects of issues. I've been considering how I'm going to handle orchestrating issue state transition (i.e. each processing step a issue needs to transition between) and I would prefer to not have to handle it with separate logic outside of beads nor use beads labels (using labels seems like a hacky work around for what should be defined by the issue status.)

Alternative method to achieve similar results

Using a combination of the current statuses and labels or assignees could potentially achieve the same results.
For example if status is open and assignee = 'docs_agent' and label = 'awaiting_docs'. However this would be inflexible and convoluted especially in scenarios when multiple agents of the same docs_agent type wouldn't have a way to set individual agent instances of the same type as the assignee with unique names e.g. 'docs_agent_1', 'docs_agent_2', etc.

However in my opinion:
labels should only be for issue classification and categorization filtering
assignee should be for delegating the specific individual actor instance on a specific issue that is responsible for the issue at any given time.
status should be for describing the current issue state

Compare to scenario with 'custom status states'

Propose (for an external processing pipeline) that status is awaiting_docs which allows any agents/collaborators authorized to process issues with status awaiting_docs may claim the issue or an agent-orchestrator sets an individual assignee (i.e. agent instance or person name) of a agent/collaborator authorized to process issues with status awaiting_docs. This would allow multiple agents/collaborators authorized according to issue status to claim an issue or they can be individually assigned to and process an issue that has the appropriate status.

---

I would like to hear others thoughts on this regarding viability, project consistency, usefulness, etc. or if there are better ways to achieve configurable issue states.

Please comment on this issue with any thoughts, opinions, and/or critiques.

If enough people like this and a maintainer endorses this plan I'll implement it and create a PR for it.

I'm looking forward to any replies.

Thanks for reading :)

[maphew]

Steve gave his view in the associated issue - #344 (comment) - namely: don't change status types, labels can be leveraged to do this, or use a table extension.

For myself, I've twisted many times on how to use status vs labels vs tags when trying to figure out how GH issues, trello, jira, and many nameless others could be used for my work. Tracking systems seem to be inherently tilted towards ever increasing complexity. Frightfully easy to start joyous -- this works! -- only to become rube goldberg monstrosities demanding constant feeding and maintenance as each extra is applied.

So yeah, customization is needed, the initiating itches are real, but apply remedies carefully and be ready to rip them off and try something else. Don't commit early to a particular architecture.

[cpdata]

I really appreciate the feedback. You and @steveyegge both make very valid points and I agree with you about how tracking systems seem to inherently tilt towards ever increasing complexity and the need to balance between introducing more code that will need to be maintenance and carefully applied features and solutions. After thinking it over more I can see how existing labels could achieve the same end result I was seeking without introducing any changes.

I am loving beads so far. Using beads in my agent workflows has dramatically increased my throughput and I'm eager to integrate beads into all of my projects.

[steveyegge]

Awesome to hear, @cpdata! And thanks for all the PRs!

[maphew]

you're welcome @cpdata and also thanks in return. I almost deleted the comment several times while writing because, well, it's a buit hand-wavy and I wasn't sure if it contributed any substantive thoughts.

[cpdata]

First, my apologies for not responding sooner. I was out of town visiting family for Thanksgiving and am just now catching up on GitHub.

@maphew, regarding your note that your comment felt a bit “hand-wavy,” that was totally fine and actually welcomed. Informal brainstorming and cautionary thoughts help frame open questions and guide future work. So please don’t hesitate. I’m always open to feedback, thoughts, or opinions, as I feel it improves the overall quality of communication.