Closed Beta: Opt-in by request
If you are using the Fork and Branch Git workflow, you now can increase your team's efficiency by automatically advancing issues in your primary repo for newly created branches in your forked repos. This will help your devs stay at the command line and keep your PMs informed of issues that have begun development work.
If you are interested in using this feature, please reach out at andrew@codetree.com
Many of you have shared with us that you found the hardcoded To Do stage frustrating. You wanted to be able to setup your own workflow stages without us forcing a particular workflow on you.
Message received! We have removed the hardcoded To Do stage.
For those of you that liked having a To Do stage you can follow these steps to get back something similar:
Create a new custom stage called 'To Do'.
Create a filter to get all open issues that are in a milestone (or assigned if you are in assignee mode) and exclude all issues labeled with a stage label (e.g. 'in progress'). Use bulk edit to apply the stage label for the custom 'To Do' stage you created in step 1.
If you need help with the above please contact support.
As part of our on-going work to improve workflow we've removed the Sticky Stages feature and replaced it with a new workflow rule, "Add label when issue is closed".
We removed Sticky Stages because:
You can enable its replacement workflow rule via Project Settings > Workflow > Automated Workflow Rules > When an issue is closed.
You might find the workflow rule useful for scenarios like adding a 'to-verify' or 'release-notes' label automatically after an issue is closed.
Next up, making the "To Do" stage optional!
Previously you were not able to check or uncheck task lists in comments, but you could do so if the task list appeared in the issue body.
Now both issue bodies and comments work identically and you can check or uncheck items no matter where they appear.
Codetree's workflow feature automatically moves issues through your custom stages, without you having to explicitly add/remove labels or drag issues between columns.
You can setup rules to move issues into a stage of your choosing when a branch is created, a PR is created, or a PR is merged.
Take advantage of the workflow feature:
Navigate to Project Settings -> Workflow
Tell Codetree what branch naming pattern your team uses. Codetree uses this to identify which issues to move through your stages. A typical pattern would be ^(\d+) which allows you to start your branch names with the issue number. Or (\d+)$ if you end your branch names with the issue number.
Tell Codetree what you'd like to happen when:
The Epic feature is great when you're in Codetree but what about when you're in GitHub? How can you quickly see what's going and jump to child issues?
Codetree will now optionally maintain a table detailing an Epic's child issues in the first comment of the Epic issue in GitHub.
The Epic child issue table looks like this...
When changes to an Epic take place like adding or removing child issues or when a child issue changes the table automatically updates to reflect the current status.
You can jump to a child issue in GitHub by clicking the title of the issue in the table or open the issue in Codetree by clicking the Codetree icon.
You can enable the GitHub epic comment feature from project settings.
Include dependency info for needs/needed-by and epics in the JSON export of issues.
Codetree now provides Epics for your GitHub issues. Epics are a building block to help you get better insight into the state of your software project. With Codetree Epics, you can:
Here's how Epics help you understand the state of your software project.
1. Group a large feature's component issues together
We look at an Epic as a temporary (it gets closed) container that represents a feature that can be broken into smaller issues. The epic groups together the set of "component" or "child" issues that make up the feature. When the child issues are completed, the larger feature is ready to deliver to customers.
In GitHub you can group issues together with labels or milestones (if your milestones aren't date-based), but it's painful.
A Codetree Epic is simply a GitHub issue with some special sauce: you can add it to a milestone, and add assignees and labels to it. The Codetree special sauce means an Epic acts as a container for any child issues you add to it.
Here's how to add an issue to an Epic:
Once you've added issues to your epic, you want to understand what's left before the feature is done. Which brings us to the second scenario we built Epics to solve...
2. Easily understand the state of a feature's component issues
Once you have an Epic, you can get insight into the status of its issues.
For example, you can see at a glance the progress on that Epic in terms of issues closed or points completed:
You can see what stage the Epic's issues are in:
You can visualize an Epic's issues in stages on the board:
And you can re-milestone or re-assign them in list view:
We've been dog-fooding Epics internally for over a month. We've found it useful to understand what's going on with the Codetree project we use to build Codetree. We hope you find it useful too, and remember: we're always keen to hear how we can make it better for you.
Two things to make Codetree much faster:
In two GIFs...
Here's the old Codetree database:
Here's the new Codetree database:
What was that issue I just edited? Oops... forgot the milestone! There is now a handy little list of your five most recently accessed issues in the sidebar below your custom filters.
