Follow

@organizingInFedi
Final
(at least for now):

Part 1 of n.

This is a repeat of my first conclusion: organizing will require topical discussions. Group actors that relay messages to all followers are useful for keeping those discussions together .

Current group actors include @GuppeGroups and git.ondrovo.com/MightyPork/gro from @piggo

@organizingInFedi is a MightyPort group actor.

Continued...

@organizingInFedi
Final
(at least for now):

Part 2 of n.

Those group actors are not the same as organized (or even disorganized) groups of live people, although their followers might constitute such a group.

They are just message relays, something like a mailing list inside fedi.

@organizingInFedi
Final
(at least for now):

Part 3 of n.

Threaded discussions are an important method for organizations to make decisions online.

Mastodon threads are just sequential lists. They don't show who replied to what.

This weakness has give rise to a bot called @Chartodon which you can invoke by the method shown on its profile.

Here's an example: solipsys.co.uk/Chartodon/10712

They disappear after awhile, but I have saved a few which I can show on request.

@organizingInFedi Final
(at least for now):

Part 4 of n.

Chartodon thread diagrams are lovely, but difficult to read (IMO).

But all the ones I have seen are tree-shaped, which means that an indented tree view like this valueflows.pythonanywhere.com/ would work and be more compact and easier to read.

I wonder if they could be presented as a treeview in the same UI as the main timelines, when you click Show Thread...?

@organizingInFedi
Final
(at least for now):

Part 5 of n.

But I think for operating an organization in fedi, real groups of some kind will be needed.

Otherwise the firehose of federated timelines interferes with people who want to get something done.

At least something like what other social media apps sometimes call rooms or channels or even groups...

Here's an ongoing discussion about implementing groups in ActivityPub: socialhub.activitypub.rocks/t/

@organizingInFedi
Final
(at least for now):

Part 6 of 6.

If an organization wants to coordinate work or economic activity (production, distribution, and provisioning), they might want to look at the extensions that @bonfire is working on: bonfirenetworks.org/extensions

Problem with those extensions is that only Bonfire pubs will understand them, as of now. Could change in the future. That would make them more generally useful.

@bhaugen @organizingInFedi @bonfire FWIW

I do have an experimental tool that lets you have the discussion directly in the "Chart". But it also lets you reply to multiple nodes, so discussion threads can be drawn together. If you want a discussion to reach a conclusion, pulling the threads together is the objective. Mastodon discussions don't enable that.

So you may be interested in exploring the DiscDAG tool. If so, let me know.

@bhaugen @organizingInFedi @bonfire If you're interested in DiscDAG then you're probably best to have a look at this first:

solipsys.co.uk/cgi-bin/DiscDAG

It's not a discussion, it's documenting some of the major/primary features. Let me know when you've had a look at that.

(I need a proper on-boarding experience)

@ColinTheMathmo
> Let me know when you've had a look at that.

I skimmed. Also prepping for a meeting. Will come back later when I have more time.

@organizingInFedi

@bhaugen @organizingInFedi Not a problem ... it's late here and I'm going off-line soon, so we might have to do it in "slow time"

But come back to me later.

@bhaugen @organizingInFedi For later consideration ... DiscDAG has a "Local Neighbourhood" mode, and I'm looking at implementing a generalisation of "collapsing", so you can navigate around, hide the bits you have seen, and then potentially add "Summary Nodes" to hide sections of the diagram.

It's a work in progress, but I have no front end skills at all, and cannot implement by ideas.

@bhaugen
Had a look at the Chartodon png. Network mapping like this is a basic generic tool for the toolstack. Sadly, different tools for different media? Chartodon for Mastodon.

The wiki wizards are on the case with generic network-mapping tools? Via Graphviz plugins and massive scraped data in fedwiki.

In this version though, visual design leaves a lot to be desired - centred text, roman fonts, illegible black-on-colour combinations. May it evolve!
@organizingInFedi @Chartodon

@bhaugen
A thought that I can't make concrete just now -

If the set of messages within 'a group' (or 'a thread' within a group) were viewed as a commons, what would the implications of that be?

The discussions you flagged seem to be objectifying 'Group" - or rather, lamenting the fact that 'group' has no agreed formal defintion that can be coded-for.

What if this were seen as a governance/stewarding challenge rather than a doc-management algorithm challenge?
@organizingInFedi @Chartodon

@bhaugen
Maybe participants in a group (contributors in a commons) might be obligated to *tag* communications? Instead of expecting some network algorithm to 'make sense' of a set of exchanges?
Then, maybe a network map of sequences of msgs within a tag-topic can be useful?

This way, an assumption you made - of branching tree - can be abandoned. A city is not a tree. Communication across a commons is multi-topic, weaving, hybridisng? Thus, tags, not hierarchies?
@organizingInFedi @Chartodon

@mike_hales
"This way, an assumption you made - of branching tree - can be abandoned. A city is not a tree."

That's not an assumption I made, as far as I can tell, that's how threads in Mastodon work.

Most online discussion spaces tell you what a reply is replying to.

"Communication across a commons is multi-topic, weaving, hybridisng? Thus, tags, not hierarchies?"

Hashtags work ok, even better via a group actor.

But I am not thinking multi-topic threads.
Continued...

@organizingInFedi

@mike_hales
...continued:

I am thinking of single-topic threads aimed at helping groups make decisions.

For example, one of our local groups wants to organize a multi-generation cooperative housing complex.

They have a bunch of complex decisions to make, which get scattered in multiple email discussions, and never settle.

And it's hard to meet F2F given covid surges.

@organizingInFedi

@mike_hales
But Mike, thanks for all the questions! Helps me think and possibly explain better.

@organizingInFedi

@mike_hales
We set up a mailing list, which several geographically-related groups use, but it's very multi-group and multi-topic and has no structure beyond email, so I'm wondering if Fedi could work better.

@organizingInFedi

@mike_hales @organizingInFedi
"If the set of messages within 'a group' (or 'a thread' within a group) were viewed as a commons, what would the implications of that be?"

That's sorta like the set of messages in a fediverse instance, or across instances, all the instances represented in your timelines.

Threads are different. They are composed of chains of replies to an original post.

They tend to be "about" the original post as something like a topic, but can and do drift.

Continued...

@mike_hales @organizingInFedi
...continued:

I want to see if threads could be used for group decision making. (More about "group" below.)

"The discussions you flagged seem to be objectifying 'Group" - or rather, lamenting the fact that 'group' has no agreed formal defintion that can be coded-for."

Yes, I am thinking about using Fedi to organize a group of people to do something collaboratively. We have three local groups who have three different goals.

Continued again...

@mike_hales @organizingInFedi

"What if this were seen as a governance/stewarding challenge rather than a doc-management algorithm challenge?"

That is how I am thinking of it. I think such a challenge needs a bit more structure than the fedi firehose provides as of now.

E.g. those people I cited who wanted to organize something that affected fedi immediately switched to another medium.

@mike_hales
Chartodon is impressive, but I think overkill.

I think all that is needed is to know what replied to what, which many online discussion spaces tell you in much simpler ways.

One way is a treeview. Another way is a link or excerpt-with-link showing the message being replied to.

That is assuming a reply references one and only one message, which I think is the case in Mastodon, and maybe in ActivityPub (?). Graphs are harder, but I think possible.

@organizingInFedi

@bhaugen
> But I am not thinking multi-topic threads

Hmmnn. Any discussion on something real will fork. And folks are really poor at explicitly forking. So eventually any thread on a significant topic/decision will become multi-topic. Hence the relevance of tagging too

Most folks won't adopt the discipline of being clear and focused? But at least, maybe a careful READER of a thread should be offered tagging as a tool, to create their own view of what comes out the firehose?
@organizingInFedi

@bhaugen
I'm jusing a distinction I made in 'extended trinity' here:
learnstack.federated.wiki/view
Tools for maps (ie curating items out-there in the world, for a specific use, here in a location) are differentiated from tools for issue threads

I think the former needs to be overlaid on the latter. The former is a field that's poorly developed, especially in terms of generic mapping tools rather than custom ones. Tagging is an approach that seems well developed and pretty generic?
@organizingInFedi

@mike_hales
P.S. your 'extended trinity' is excellent, especially
"The elements in this 'mapping and navigating trio' are affordances rather than stand-alone apps. They're essential for systemic engagement in a real-world external environment..."

@organizingInFedi

@bhaugen
Your bulletlist of requirements looks good to me. All four overlaid, I think (as affordances within a single UI/app)

* what replied to what
Both threads AND thread-network maps?

* separate channels, rooms
A chatroom with only one thread (ie 'chat' in extended trinity terms) can easily be a pain in the arse, especially if you're not in the room all the time. ¿Radically? asynchronous use is an affordance of both issue threads and library/repo in the extended trinity
@organizingInFedi

@mike_hales
>> what replied to what
> Both threads AND thread-network maps?

Both might be good.

Could start minimally with maybe having a toot in a timeline showing on the bottom something like a "Replies" link if it has any, and if it was a reply to something else, maybe showing on the top a "Replying to" link.

Or @bonfire is working on an indented view something like Reddit.

@organizingInFedi

@mike_hales
"* separate channels, rooms
A chatroom with only one thread (ie 'chat' in extended trinity terms) can easily be a pain in the arse, especially if you're not in the room all the time."

I'm thinking of async rooms as in Matrix, Mattermost, Telegram, Slack, etc. Not chat rooms.

"¿Radically? asynchronous use is an affordance of both issue threads and library/repo in the extended trinity."

Hope that (above) clarified my intentions.

@organizingInFedi

@bhaugen
'Room' is a very unstable term (like all these)

A 'room' in Matrix/Telegram is just one thread. Easy to lose track of when not in the flow (ie radically async - another timezone, hiking for days in the woods, governed by childcare responsibilities, etc). Surely, Matrix is a 'chat' room. No threads, no intra-room nav sidebar for threads, only multi-room sidebar.

A 'room' in Mattermost = a group (or somesuch name) with multiple threads in it. Likewise in Slack.

1of2
@organizingInFedi

@bhaugen 2of2
In Zulip the former (ie 'room') is 'an organisation', the thread is 'a stream'. And within a stream there are 'topics'. Nice! All navigable in a two-level sidebar. Now THAT's more like it?

Basically 'async' is a flaky term too. Isn't it more about 'curatable' or 'easily retrievable' or 'multi-thread navigable' or 'durably encoded and searchable'. Or something of that kind? In the extended trinity, the original trinity constitutes a continuum of that kind.
@organizingInFedi

@mike_hales
I'm looking for some boundaries now and then. All of those are examples of different kinds. Not sure yet what fits best into Fedi. Experiments help.

@organizingInFedi

@mike_hales
P.S. I think we are using different definitions of "thread".

I'm using it like what you see if you click "Show thread" in Mastodon: one original post followed by however many replies, all roughly following a thread of conversation.

A room in Matrix and Telegram can contain many such threads of conversation. Might or might not be separable as different threads. But they do have limited membership, and you must be a member to post.

Does that make sense?

@organizingInFedi

@mike_hales
P.P.S. I am not claiming my definition is correct, just noticing that we have different ones...

@organizingInFedi

@bhaugen
> they do have limited membership, and you must be a member to post
This brings some kinda focus. but nothing like enough. Folks wander, and fork off at different posts within a thread. But posts are linearised

>A room in Matrix and Telegram can contain many such threads of conversation. Might or might not be separable as different threads
Quite. This makes it hard to read threadwise. I feel visibly-separable threads are needed. Author-tagged or user-tagged. Both?
@organizingInFedi

@bhaugen
> different definitions of "thread"

Hmmnn. I recognise your definition - a chain of posts in response to particilar posts. Of course visibility of threads in this sense is needed

Assuming this, my concern is 'thread of meaning', focus, intention. Hence tagging (or 'topic' in Zulip) or some other map-making affordance. Available to a considerate and attentive author. Also to a reader wanting to follow what 'a thread' in fact engages and contains. And retrieve it too
@organizingInFedi

@bhaugen
I have to say - I never use tags here in Mastodon for example, as an author. I guess I don't perceive persistent topics of concern. I don't preceive Mastodon as a place to learn or curate (it's not!) - just a place to chat, and see the toots streaming by and off the top of the screen. Favourites are little use here

So I guess, tagwise, I'm thinking mostly of reader-taggable posts

Eg when I store webclips (in Joplin) I tag 'em. Would make better sense in 'a room'?
@organizingInFedi

@mike_hales
> I don't preceive Mastodon as a place to learn or curate (it's not!) - just a place to chat, and see the toots streaming by and off the top of the screen.

That's Lynn's perception, also. My experiment was to see what would take to make it work for organizing some collaborative activity, and then progressing to operate as an organization.

I'm following this 2017 ramble about "a minimal bottom-up P2P economic system":
docs.google.com/document/d/1fN

(1 0f 2)

@organizingInFedi

@mike_hales
(2 of 2)

It's difficult to start from a shared idea and develop a working organization to create and operate it.

Every organization we've worked with uses a lot of conversations to get and stay organized.

And then they use some other "tools" for more structured activities.

And all of the info gets fragmented.

So I am experimenting to see how it might work to evolve from casual conversations to more structure while keeping all the info integrated.

@organizingInFedi

Show newer

@mike_hales
> my concern is 'thread of meaning', focus, intention. Hence tagging (or 'topic' in Zulip)

Group actors and hashtags and even better group-actor-hashtags are good for topics in Masto.

@organizingInFedi

@mike_hales
> I feel visibly-separable threads are needed

Agreed. Mastodon UI does that. So does eg Mattermost, but they do it more annoyingly. Your messages in a thread disappear from the main stream unless you check an easy-to-forget checkbox. Masto messages in a thread appear also in the main stream with a "Show thread" link. Much better.

@organizingInFedi

@mike_hales
I've used Zulip in two groups and liked it.

One is a Category Theory group, which continues to use it happily, although I don't visit much anymore, because I am not really a Catster, so most of the chatter was over my head.

The other was a local fablab that failed to get organized, which was most likely not Zulip's fault.

@organizingInFedi

@mike_hales
My conclusions of what is needed include:
* group actors (which exist);
* hashtags (which exist, and group-actor hashtags are better);
* clear indication of what replied to what (which does not exist in fedi, and chartodon is inadequate: simpler methods exist in other spaces);
* and I think also separate channels, rooms, etc, as in other discussion spaces.

continued once...

@organizingInFedi

@mike_hales

"Most folks won't adopt the discipline of being clear and focused?"

I think they will and often do try, but the medium (email) does not help.

And I have also seen people often want to return to a previous group decision to learn how it was arrived at, especially if they were not involved in the decision. If the info is not available, it can lead to arguments.

@organizingInFedi

@bhaugen @organizingInFedi element/matrix have just implemented threading functionality. Its in the 'labs section of Element Android. Guess may need to sign into the testing/dev version element web client at matrix.org to see them (forget the url)
It looks like it could work pretty well once people start use them. Although thread replies will be back in the timeline so may at times have to also post a reminder/link to prompt room members to check them

Sign in to participate in the conversation
social.coop

A Fediverse instance for people interested in cooperative and collective projects.