Multi-User Kanban boards on Nostr

[vivganes]

NIP to implement Kanban boards on Nostr to track work.

Features supported:

• Create boards that can track cards across columns
• Assign maintainers to boards, who can add/edit cards
• Add the same card to multiple boards without duplicate tracking
• Ability to add a tracker card that tracks some other nostr event (like a git issue) - particularly when you are not the author of the original event - This enables integration with already existing nostr features
• Automatic movement of the 'tracker' card to appropriate column in the board when the tracked event changes its status
• Zap any card

Read it here

[dluvian]

I think the column and order information of each card should be part of the board event. This way you can use any event as a card and don't need to create a dedicated card event. I was thinking to use kind:1621 GitIssues as cards in a Kanban board

[pablof7z]

on the 2, vs 4, vs 8 spaces indentation you fall on the ZERO INDENTATION MAXI camp? 😂😂😂😂

I think stringified JSON in content is a crime against humanity and should almost always be avoided; I think this can all be put as tags:

content: "My board to track bugs",
tags: [
  [ "a", "<...>", "column" ], // column 1
  [ "a", "<...>", "column" ], // column 2
  [ "a", "<...>", "column" ],  // column 3
]

[pablof7z]

Then I would add a column (or better yet "group") for the cards

[pablof7z]

This extensibility usually comes at the cost of unnecessary complexity; if you are already tagging the individual cards, do you really need this mapping? I think this mapping would be problematic and error prone and being explicit is the right, simpler approach

[vivganes]

This is sort of needed as any card can be added to a board.

What if we add a card that we did not create? We may not even be able to edit it. If we render a column for each unique status, we may easily get into situation of having 3 columns like "todo", "To-do" and "to do".

In such case, currently, in kanbanstr, I am showing a column called UNMAPPED to map this.

However, writing simple conditions of which card statuses belong to which column should be easy.

Not sure if my answer is clear.

[pablof7z]

no, the columns are explicit, cards exist, they are grouped by events (in kanban parlance, "columns") those events are grouped by events (in kanban parlance "boards")

[SilberWitch]

However, writing simple conditions of which card statuses belong to which column should be easy.

Yes, it's common to have multiple status per column, like "Done", "Canceled", "Closed" in the DONE column. Or "In Development", "In Test", and "In Review" in the IN PROGRESS column. Depends upon the ticket type and the workflow. Stories are "Defined", but bugs are "Reported", and both are TODO.

[vivganes]

This extensibility usually comes at the cost of unnecessary complexity; if you are already tagging the individual cards, do you really need this mapping? I think this mapping would be problematic and error prone and being explicit is the right, simpler approach

Yes, it's common to have multiple status per column, like "Done", "Canceled", "Closed" in the DONE column. Or "In Development", "In Test", and "In Review" in the IN PROGRESS column. Depends upon the ticket type and the workflow. Stories are "Defined", but bugs are "Reported", and both are TODO.

I have just changed the spec to have a simpler approach using arrays. Please let me know what you think

@pablof7z @SilberWitch

[pablof7z]

I would do the hierarchy a bit different that is less coupled with the kanban-presentation:

Cards: Are individual things to track
Groups (aka columns): These are just groups of things to track

Groups can contain cards or groups, they act (and should be defined) as NIP-51 events; they can contain individual items or other groups.

This way you can have a fairly flexible with no added complexity, a group could be an organization, that contains projects, that contains boards, that contains columns that contains the things you want to track.

[SilberWitch]

Yeah, we're using gitstuff issues for cards. Just need some structure to plug them in to.

[vivganes]

I think the column and order information of each card should be part of the board event. This way you can use any event as a card and don't need to create a dedicated card event. I was thinking to use kind:1621 GitIssues as cards in a Kanban board

Yeah, we're using gitstuff issues for cards. Just need some structure to plug them in to.

@SilberWitch @dluvian - These are great thoughts. Please let me think and get back to you with a solution.

My preliminary thoughts -

• Columns and their order are already a part of the Board event
• We need the Card to hold the status (as it can be updated only by the creator of the card or the delegates, when NIP-26 delegated event signing kicks in)
• One possible solution to wrap any event as a card (addressing the target event using 'a' tags so that it can track changes in the original event) at the cost of client complexity

I will think more about this and get back. Thanks for the suggestions :)

[dluvian]

• We need the Card to hold the status (as it can be updated only by the creator of the card or the delegates, when NIP-26 delegated event signing kicks in)

Shouldn't the owner of the board be able to update the position of a card of it's own board? Why should a board owner add a card to his board if he can't change it's position?

[SilberWitch]

I like having a replaceable kanban event, but I also would want to be able to track issues submitted by users, and I can't alter those.

I guess, I could always just quote an issue in a kanban card, which is how we're doing it with Jira, right now.

So, it's not a must. Just wondering if we can separate the mechanics of the board from the content. Also makes the cards more versatile/atomic for other use cases, like road maps, backlogs, release notes, etc.

[vitorpamplona]

I don't think we should git issue kinds for cards. They are not the same thing. Cards can point to one or more issues, though.

It would be nice if we could move the properties in the stringified JSON in contents to be tags in the tag array.

For attachments, for instance, we could even use imeta tags to provide blurhash, thumb preview, size, hashing etc to any file that has been attached.

[dluvian]

I don't think we should git issue kinds for cards.

We're not saying that cards should always be git issues but it should be possible to include them in the board.
The additional step required to wrap the git issue adds complexity and increases the likelihood of errors. You can still do it though, but I don't think it should be the default way.

[SilberWitch]

We're probably thinking about this backward. The problem is that the git issues should just be a kanban card.

[auggie-lahey]

couple of thoughts here:
i don't think the existing spec allows nested cards. in agile, tthis is important because epics are cards consisting of features consisting of user stories consisting of tasks.

Also i don't think the spec should dictate that board owners can create cards. it'd be ideal to use the list feature of nostr to delegate that.

another feature would be editing cards, but its more complex because one user (dev) could create a card, and another could groom (PM). maybe the ideal workflow for that is a way for a card to be forked or use the proposed edit functionality (i think this is in amethyst?)

[vivganes]

couple of thoughts here:
i don't think the existing spec allows nested cards. in agile, tthis is important because epics are cards consisting of features consisting of user stories consisting of tasks.

Also i don't think the spec should dictate that board owners can create cards. it'd be ideal to use the list feature of nostr to delegate that.

another feature would be editing cards, but its more complex because one user (dev) could create a card, and another could groom (PM). maybe the ideal workflow for that is a way for a card to be forked or use the proposed edit functionality (i think this is in amethyst?)

Thanks for sharing your thoughts. I will work on consolidating all the comments and editing this NIP this week positively.

[vivganes]

Yeah, we're using gitstuff issues for cards. Just need some structure to plug them in to.

I have just now added a new way to track already existing events on a board. See Tracker Card Event section. @dluvian

[vivganes]

couple of thoughts here: i don't think the existing spec allows nested cards. in agile, tthis is important because epics are cards consisting of features consisting of user stories consisting of tasks.

Also i don't think the spec should dictate that board owners can create cards. it'd be ideal to use the list feature of nostr to delegate that.

another feature would be editing cards, but its more complex because one user (dev) could create a card, and another could groom (PM). maybe the ideal workflow for that is a way for a card to be forked or use the proposed edit functionality (i think this is in amethyst?)

1. Nested cards - I have thought about it but do not want to add it to NIP before the basic implementation is done. We can add the linking of cards to another card technically using nostr events linking (or even creating a new kind to describe what the link is). So, I would like to wait for comments on the current version before starting work on the nested cards.
2. I just now added a maintainers list like you suggested who can add/edit cards.

Please let me know what you think

[pablof7z]

wow, did nostr really make it to this date? are humans still alive or is it all sentient dvms shitposting in a loop?

[pablof7z]

why do this? this greatly diminishes the usefulness of this NIP and makes it more complex to implement (as detailed by the next comment "However, the card....")

[pablof7z]

I think this is also unnecessary and is just here because the previous event introduced unnecessary complexity.

[vitorpamplona]

The new version looks great!

If you are looking for a way to get rid of the multi-author d-tag shenanigans, I recommend #1228

Basically, boards would be always created by a new nsec that is encrypted and shared with all the p-tagged members individually. To edit, the client would decrypt the nsec and use that key to sign a new version of the event.

We are using the scheme on http://sheetstr.amethyst.social and it seems to work really well.

[vivganes]

The new version looks great!

If you are looking for a way to get rid of the multi-author d-tag shenanigans, I recommend #1228

Basically, boards would be always created by a new nsec that is encrypted and shared with all the p-tagged members individually. To edit, the client would decrypt the nsec and use that key to sign a new version of the event.

We are using the scheme on http://sheetstr.amethyst.social and it seems to work really well.

Oh man! Why didn't I look at this thing before?

This is really amazing and let me explore how to adapt this NIP to use this

💯

[SilberWitch]

If you are looking for a way to get rid of the multi-author d-tag shenanigans, I recommend #1228

I like this concept, in theory, but make sure at least one npub on the project team confirms that they got the key before using the key to write. This failed for us, twice, in the past, and now there are npub-less projects floating around with our branding forever.

[fiatjaf]

I may be missing something, but I think can't be done otherwise and should really should be done inside the scope of an existing closed group interface, like NIP-29 or MLS groups.