The v3 iteration on Projects is winding down. Here are some remaining issues we're aware of or thinking about.
In many cases, particularly with subprojects, we're interested in collecting more feedback about use cases now that the core of this feature is available, so we can resolve product questions which have arisen during implementation.
Subprojects and Workboards: Subprojects do not currently appear on workboards as columns. If we make them appear, it will mean that cards may appear multiple times on the same workboard. For example, a T123 Tomacco may be tagged with both Produce > Tomatoes and Produce > Tobacco, and would thus appear in both subproject columns on the Produce workboard.
There is a (modest, surmountable) technical barrier to making this work, but if we do we're sort of stuck with the product complexity. We'd like to see more interest in having workboards work like this. It's possible the feature is not necessary and we can avoid the attendant product and technical complexity.
Subproject UI Concerns: Subprojects work, but have some rough edges in the UI. For example, if you have Candy Craze > Android and Flappy Candy > Android, both subprojects will appear as Android in some contexts.
Improving this in the general case is tricky. We don't want to simply render the entire hierarchy everywhere, because projects can nest very deeply and showing A > B > C > ... G on cards on workboards would require a huge amount of space and not be useful. It's not currently clear how to best balance these concerns, or to what degree we need to.
At one extreme, we may not really need to do anything. At least in this project we don't really have any ambiguous project names (i.e., no A > Android and B > Android). It's possible that very few of these projects exist in the wild, and that naming them something like Candy Craze > Candy Craze (Android) is reasonable in the handful of cases where they do exist.
I suspect this is a little too optimistic and we'll need to take at least some steps to decrease ambiguity, but we'd like a better sense of how common this problem is and where it is occurring first. A possible small change we could make is letting projects have a "Full Name", so Candy Craze > Android would have "Candy Craze (Android)" as its full name but still appear as Candy Craze > Android in crumbs and other places where full context is available.
Selecting Exact Projects: Searching for a superproject currently searches for objects tagged with that project or any subproject. We may introduce a function like exact(#superproject) in the future to search only for a superproject, exactly. However, it's not clear if this is really necessary or has any use cases.
Workboard Updates after Edits: Certain updates to workboards (like manually changing which milestone project a task is in) are not properly reflected in the client-side UI. This will work properly after additional work in pursuit of real-time workboard updates (see T4900). This may get fixed before that. In the meantime, a workaround is to reload the page after making these edits. I expect these edits to be rare.
Likewise, if you enable points, the milestone progress bar does not currently update automatically to reflect changes. You can reload the page to redraw it. This will start working automatically at some point.
Searching/Filtering Tasks by Points: This needs use case feedback, see separate discussion in T10339.
- Migration Tools: Some basic migration tools are now available in T10350.
- Watchers: Watchers now have more sensible behavior, and watching milestones isn't buggy.
- Column Position for New Tasks: Newly created tasks should once again float to the top of columns.
- Binding Project Membership to External Sources (T3980): This iteration mostly ended up in UI work and this feature didn't really make sense to keep in scope since it wasn't adjacent to anything else. It's still planned, but won't happen until the next time we do an iteration on projects.