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

Feature
1

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
2

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
3

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
4

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 ?

5

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
6

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
7

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
8

Is there any follow up work concerning this great idea?

2 Likes
9

I’m very interested and available to help revive this idea.

10

This is done per

12 Likes