In my team we use kanban (aka swimlanes/trello) for planning programming work.
I want to stop using gitlab issues / trello boards and use discourse as one place to co-ordinate all this.
(Why? I love the UX of discourse and everyone hates using multiple systems)
Here is my idea for coding a kanban interface:
Each sub category will be a separate column.
Topic in each category are cards in each column.
So for e.g. Under the features category I can create sub categories like
Incoming feature request.
Being planned
Being developed
Being tested
Released to production
In the kanban interface on one page i will be able to see all the features separated out in the above 5 columns.
Dragging and dropping the card between column will move them along the process.ā
I have coded something similar in the past and programming it would be trivial.
The order of the cards in each column will be determined by the votes of that card.
Is this the right spec? Or is there a better way to do things?
Tags and ātag groupsā would likely be a better match for this 2nd level category list as you donāt need any further security definition at that level.
This would enable multiple boards without them having to be top level
Definitely use tags for this. Subcategories is far, far too heavyweight, and topics moving around willy-nilly tends to be disconcerting to onlookers. I like the general idea, though, as a fellow āletās put everything on a boardā enthusiast.
Use specific tags for status. s:new, s:planned, s:dev, s:test, s:released. You could get around having a new of those tags by putting any closed topic into āReleasedā, any anything open and with a special tag into āIncomingā. As a sanity check/safety valve, if someone manually adds another tag (say they āmoveā the topic by adding s:test without removing s:dev), either put it into a (dynamically-created) āWTF?!?ā column, or just leave it in both columns and have someone fix it up by hand when they notice one topic in two places.
Donāt let the perfect be the enemy of the good, here. Youāre after a quick visualisation, not a strongly-consistent transactional distributed data store.
Iām not sure all this is needed, as already mentioned above you ācanā use āTag Groupsā to restrict what tags can appear i.e. only one tag from the group ["new", "planned", "dev", "test", "released"].
Visit /tag_groups after enabling the tagging enabled site setting (disabled as default) to configure these.
Also note that within a category you can then set the following per category āTags that can only be used in this categoryā, āTag groups that can only be used in this categoryā.