Wagn's commenting system is cool but unusual and awkward in some ways. This is an attempt to bring those concerns together and put together a unified plan.
We'd like to preserve (possibly in one unified technology?) the highly valuable parts of our current system, including and especially the ease of moving comments into the core card content, while addressing the following needs
The core idea here is that both patterns make use of a +*comment trait (and we get rid of the +*comment permission).
[Aside: "Traits" are, arguably, not fully baked ideas, but the core of it is that they are plus cards that get some special interface, especially around permission. +*account is trait, for example. There is some discussion that +*name and +*type could some day be traits to affect permissions for editing names and editing types (which could then be separated from general update permissions).]
The two patterns will share lots of configuration / behavior. In both patterns:
However, they differ in these ways:
How do you configure which kind of commenting you want? My first idea is that this determined by the *autoname setting on the +*comment card. If the *autoname rule is blank or "_self", then you have a content card. How exactly we handle the configuration for card comments depends on the data representation, which is perhaps the biggest question mark in the proposal.
This is deeply related to Managable Patterned Contextual Lists idea, and for now most of our discussion about this representation (especially the comments themselves) should probably happen there.
My first inclination is to say that +*comments is actually a Pointer and that, for card comments, each comment is added to the pointer. This has some cool benefits over using search, including performance, potential support for threading, being able to remove comments from a conversation without renaming or deleting them, being able to move comments to an entirely different discussion...
Straightforward pre-Decko-1.0 steps:
once we have our action API it should also be relatively straightforward to:
Note that this is all within the "append" model. The "own card" model would still be after Decko 1.0
Development Tickets (by status)