I want to code a kanban interface to categories .. lets put a spec together

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:

  1. Each sub category will be a separate column.
  2. 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?

5 Likes

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

5 Likes

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.

3 Likes

The problem with tags is that there can be more than 1 tag applied to the same topic.

There has to be a 1-to-1 relationship between the columns in the kanban and tags inside discourse.

How will I achieve this ?

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.

8 Likes

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ā€.

6 Likes

Well, I for one didnā€™t know that tag groups did that. So yes, this would be much better than needing safety valves.

2 Likes

Is there any follow up work concerning this great idea?

2 Likes

Iā€™m very interested and available to help revive this idea.

This is done per

12 Likes