Housekeeping for this Loomio group

I copied this email to Robert Guthrie. There’s something just doesn’t work, when clicking in to a thread from an email notification (or notification within Loomio?). I frequently get dropped into a thread, glimpse the required comment, highlighted, for a moment, then it gets replaced by . . . some other stuff in the thread. And like Bob, I then fail to find it. There is no within-thread search, of course.

I got one of those emails from Loomio notifying me of new messages in this group from @Danyl Strype @Daniel Harris and @mike_hales

I clicked the links in the email, which brought me to this very long thread.

I can't find any of those three messages, by scrolling or ctrl-f. Ironically, one of Mike's comments was about the difficulty of finding anything in these long threads...

This forum offers an interesting approach to introducing members: https://discourse.covid-oss-help.org/c/Areas-of-expertise

They have a subgroup where each person can post their introduction as a new thread, with their name/ project as the title. Then the group can offer welcomes, make comments, ask questions, etc which can make a single introductions thread a bit unwieldly. The subgroup itself remains a simple list of names, easier to scroll through for newcomers.

This all sounds very reasonable. Thanks for the clarifications. We are in total agreement about striving to:

make [edited titles and] summaries so simple, clear and uncontroversial that all responsible participants would be willing to agree with them (and possibly add to them) by rough consensus

This is exactly how I see it. In fact, if you want to put this wording up as a formal proposal, I would definitely click 'agree'.

My goal is to avoid having every new wave of members that joins the group repeating discussions we've already had, instead of building on them, and starting new ones. Do we agree that this is a worthwhile goal?

Yes, and it's inherently risky for newcomers to depend upon the inevitably incomplete and subjectively-biased reporting which any individual or subgroup creates (or iterates) for existing conversations. Sorry if I seem 'difficult' on this, but I'm painfully critical of reporting in general. (Not all reporting; just much or most of it.)

If titles and context box summaries are occasionally updated, ** I simply suggest to make summaries so simple, clear and uncontroversial that all responsible participants would be willing to agree with them (and possibly add to them) by rough consensus.** I might even recommend using Loomio proposals to establish any especially important shared facts.

In fact, I think it's way more important to directly establish future-oriented agreements than to summarize any conversations. I care way less about what happened in the past than most people seem to. I'm focused on establishing shared understandings and plans for future activities. (Such understandings include protocols, of course, and much else besides.)

I note, I do work on 'structured conversation' principles, and I certainly do ultimately desire to inclusively map the mutually-recognizable traits (including subjects) of prior Loomio discussions. However, IMO we lack the technology (including distributed versioning, and subtle metrics indicating attitude/valence and uncertainty) to inclusively do much of that directly in this forum. If I attempted to identify the traits of complex conversations in a group like OAE, using nothing other than shared editing of titles & context boxes, my goals would simply be extremely modest & limited.

Can you lay out, in very specific terms, the worst-case scenario of changing the titles of threads that contain something obviously different to what it says on the tin, or adding TL;DR summaries at the top of context boxes, or making bullet lists of specific technologies mentioned in a thread?

I could if I really wanted to, but I respectfully don't intend to craft very specific examples. I'm just trying to indicate the generally limited value and risks of focusing much attention and effort upon the history of any specific written discussion, in an ungoverned community like this, using the very limited available tools. Here's a very generic bad-case example: A specific author summarizes a discussion to emphasize their preferred conclusions, and omits non-desired conclusions, and none of the potentially-conflicting people notice it.

Please note BTW that 'bullet lists of specific technologies mentioned' is a relatively easy thing to do simply, clearly and non-controversially. My concern is mainly with prose written reports of any significant length.

Anyway, please note I'm not suggesting for people to not change titles or context boxes! I'm indicating some risks I perceive. I'm confident that you can accept my skepticism and the limited amount of support I may give to others' reporting efforts. I would support people who 'fix' clearly outdated titles, and who update context boxes in obviously responsible ways.

I notice that interpersonal conflict has been coming up in in this group, both in the form of references to internal politics of other projects, and in what I read as well-meaning miscommunication between participants here.

Can I suggest a few things:
1. not everyone in this group is a native English speaker. As a result comments may sometimes come across more aggressively than they are intended. To quote the great Bill and Ted, "Be excellent to each other!" I recommend everyone here read the GNU Kind Communication Guidelines, and maybe look into Marshall Rosenberg's ideas about Compassionate Communication (or NVC = Non-Violent Communication). Also check out some of the excellent group culture resources that Nati Lombardo and @richarddbartlett of The Hub have developed.
2. We are all busy people, trying to save the world. Discussions about general principles and other people's personal and professional conflicts will quickly get circular, boring, and frustrating for everyone. The fediverse is a great place to engage in general banter about these topics. In this group, let's try to focus on solutions; what already exists, what do we need to create, and how can we put it all together to make a better UX for everyone trying to save the world with us.
3. One of the most basic descriptions of the open source methodology is "rough consensus and running code". We can't know another developer or project's motives, so it's a waste of time trying to infer them from technical decisions, and it tends to create feelings of distrust and disease in the community. We are mostly likely to find consensus, and produce useful results, when we focus our discussions on things that can be tested at our end. Does the code compile? Does the build crash? Does the software successfully connect with different software over a protocol? Can a non-geek use it without step-by-step instructions from a geek (this one is a bit more subjective, but can still be independently tested)?

I'm going to be on a writing retreat (No internet!) until the end of Feb, working on Email Ate My Life. I look forward to catching up with you all then :)

@gregorycassel

I don’t think it’s very important for me to abandon ‘using the tools of the enemy’ compared to my many urgent priorities.

This is a complicated discussion, and I think it needs its own thread, so we can keep this thread focused on housekeeping issues. I've opened a new thread here:
https://www.loomio.org/d/yZ1Ei4uJ/stable-well-supported-platforms-we-can-for-this-group-instead-of-corporate-datafarms

No matter how slowly it goes, most people aren't going to have much time to carefully inspect anyone else's curation / reporting decisions.

My goal is to avoid having every new wave of members that joins the group repeating discussions we've already had, instead of building on them, and starting new ones. Do we agree that this is a worthwhile goal?

If so, you still seem to be concerned about some potential negative outcome here that I can't see, and I very much want to understand what that is, so we can avoid it. Can you lay out, in very specific terms, the worst-case scenario of changing the titles of threads that contain something obviously different to what it says on the tin, or adding TL;DR summaries at the top of context boxes, or making bullet lists of specific technologies mentioned in a thread?

I agree with most of what you wrote @strypey ; thanks. I don't think though that I was really indicating a false dichotomy. You wrote

we are capable of creating reliable community spaces

And that's true, but I always find it important to clearly distinguish between the present and the desired future. I.e. right now, I don't personally have reason to sufficiently trust any of the community spaces or alternatives to GDrive and Github. That could change at any time, although I don't think it's very important for me to abandon 'using the tools of the enemy' compared to my many urgent priorities. It could quickly become very important to me depending on some variables-- say, I attract unwanted attention from a corporation-- and it certainly will be increasingly important over time.

FedWiki allows us to have multiple copies of our knowledge base, on multiple servers (and many of the projects represented here operate servers), all kept in sync automatically.

That's great; however, each server is controlled by one or more persons. Most of my work is focused on how to consistently govern intentionally shared resources such as data servers. I think that distributed computing like Holochain (but not necessarily Holochain itself) can sidestep some but not all of the basic governance issues.

If we did it as a sprint, that's true. What I'm proposing is that we do it gradually, as folks have time

No matter how slowly it goes, most people aren't going to have much time to carefully inspect anyone else's curation / reporting decisions. Thus, it seems highly desirable to me for curation to play a very limited and simplified role. It can genuinely serve the community if it's performed moderately, with humility regarding the limits of each curator's perspective, and patiently integrating any alternate perspectives.

I'd consider it unwise to refuse using the tools of the 'enemy'

I'm a pragmatist, and I have no objection to mirrors being hosted on GH, GDocs et al. But if we are building a suite of organizing tools, I think there is value in eating our own dogfood.

I literally can't afford to depend on alternatives which might vaporize either suddenly or gradually

There is a false dichotomy here, between reliable corporate spaces, and unreliable hobby spaces. Surely the whole point of this group is that when we pool our resources, we are capable of creating reliable community spaces? I do agree that designing for resilience is important, thus my mention of mirroring, and my suggestions of using the Smallest Federated Wiki (FedWiki).

Yes, text can exist anywhere, and this could potentially include an effectively distributed/p2p directory of media resources.

FedWiki allows us to have multiple copies of our knowledge base, on multiple servers (and many of the projects represented here operate servers), all kept in sync automatically.

I don't expect it to be P2P, because it will privilege whoever can afford to spend the most time curating

If we did it as a sprint, that's true. What I'm proposing is that we do it gradually, as folks have time. For example, I only spent a few minutes skimming the Holo thread, and copy'n'pasting Bob's protocol list into the context box, and renaming the thread to better reflect its contents. The conversation about the rename took longer than any other part of the process ;)

In the thread that started about Holo (now called P2P/ Distributed Network Protocols), @mfioretti asked:

Not HOW (i.e. protocols or platform etc), but WHAT?

It's a fair question in general. But there are many projects here (and hopefully many more in the future), all building different things. The Introductions thread is the place for folks to describe those. This Loomio group is about how we get them all to work smoothly together, to create a better experience for non-geek end users. The focus on the thread about Holo, SSB etc is how these protocols might help us do that.