Concept for an IssueTracker working across a loosely-formed group of people, each of whom is in multiple such groups, so a single unitary SaaS would be in inappropriate. cf Graph-driven SoftwareForge, (2013-07-15) Taco Task Hub, Object Browser, Group-forming, Software Bootstrap As DAO, microformat, Webs Of Thinkers And Thoughts, open source, portfolio life...


Meta/related: what about non-task items?


  • Different people have different amounts of time to offer.
  • A given person's time investment will change over time.
  • Different people have different kinds of skills to offer (dev, strategy, design, marketing/marcom, community growing).
  • Even if participating for intrinsic reasons, having the possibility of a financial compensation can increase motivation (note counter-arguments where motivation is reduced by rewards).
  • People will participate in multiple groups. Some are even offline!
  • Some groups are public/transparent, others are closed/private.
  • People don't want their out-of-group tasks visible to the group/public.
  • Running software (in the cloud) costs money.
  • Some tasks/deliverables are more urgent/important at a given point in time to deliver value.
  • If one person is 20% done with a task and gets busy with other things, it might make sense for someone else to take it over.
  • If one person is 80% done with a task and gets busy with other things, it might not make sense for someone else to take it over.
  • Tasks should be integrated into a wiki (and DVCS, if there's any software being built) → SoftwareForge
  • Within a group....
  • ??

Candidate (existing) solutions

A take by Venkatesh Rao, complaining about pseudo-web3 tools... Discourse, Roam, Social Warrens....

Let's say I want to build something that handles this plus discussion (e.g. Graph-Driven Software Forge)....

  • if everything's a fractal cloud, how do you (a) control access, (b) scope NameSpace
  • it smells like the fundamental UX challenge is (a) following the right set of stuff...?
  • every node has a UUID; it can optionally also have a WikiName/PetName
  • an "instance" can support a single user, a "team"/"project"/"space", or multiple teams/projects/spaces
    • an instance caches the union of nodes followed by its users
  • (for a small organization, should that be a single space? Why does it matter? How do multiple spaces "within" an "organization" get managed?))
  • 2 big questions/issues
    • can a node be edited? (cf ScuttleButt's version of this)
    • if this is supposed to support "discussion", does it need to be real-time, a slack.com replacement? Need a CRDT? Yes it needs something pretty real-time, but the CRDT is only when people are simultaneously editing a single node, which will be relatively rare (before that, we can have a locking mechanism).


  • what problem am I trying to solve? For whom?
  • what's the adoption-growth model?
    • would I use this myself?
      • my main complexity needs are for dayjob - My CollaborationWare History
      • I could use this to organize my own work
      • I could slide it into use when there's a messy discussion/decision to work on (but what SSO would i use?) (it's been an effort to get people to recognize that Slack-flat-thread doesn't work well).
  • then offer as SaaS plus open-source it?
    • this would probably stick with the "formal group controls a space"
    • would it be possible to build a cross-space view for a single user?
  • this lead to moving non-decentralized notes below to TeamGarden

Some specific user scenarios (focused on the decentralized aspects)

  • I dream up a project, I define a "space" for it
  • I write some docs in that space
  • then I decide I want to get other folks involved in 1 of them....
  • so I make a new space
  • and I move the "top" of that project to the new space...
  • all the children are now inherently moved to that space
  • which means you need to be a little more thoughtful about picking the node to spin off a new node from, since that becomes its parent
  • I can make that space read-public, write-invite
  • then I define a group for that space - I'm automatically a member, and the administrator
    • administrators are the only ones who can invite new members, or change any node rights
    • a group can have multiple administrators
    • maybe a smaller group of super-admins who have ultimate control (root space/group) (could think of this as just 1 but with redundance/backup)
  • I add people to the group page, and send invites (email? DM?).
    • when someone accepts, they set their WikiName
      • can I save my own PetName for someone? I suppose that could be auto-translated when I save a node.... but that raises weird uniqueness games...?
    • as admin I can set each person to read-or-write-or-admin
  • before accepting each invitee needs to pick an instance?
    • my instance might accept other users. Maybe that's temporarily free, or maybe it's free if limited to the space I created?
    • a user identifies their instance when they join; they can change it at any time, but there's just 1 per person
    • a user could belong to separate instances for separate projects/spaces? Is this necessary?
    • if I "run" a "company", am I ok with an "employee" mirroring their nodes to a different instance? What happens when they leave? I remove them from the space, and their instance purges all the nodes from that space? Can I trust that?
  • SecondMember has his own instance, joins project/space
    • his instance caches the root node; then it lists all the children+backlinks to that node, for SecondMember to pick which ones to follow/cache
    • when you follow a node, you automatically follows its children. But for every node, you see a Follow checkbox, and you can turn it off for any node at any time. (You can always change your mind later.)
  • I assign a task to SecondMember... he she accepts
  • She adds a subtask to that task - it starts on her instance, but because I'm following the original task my instance automatically picks up the subtask
  • She can add a private subtask
  • a task has a single Status at a time: InPrep, ReadyForWork, InProcess, InReview, Completed, Abandoned. (multiple sets of status are possible, controlled at the Space level?)

Edited:    |       |    Search Twitter for discussion