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.

I don't know that "the code is already out there", meeting the original OAE goals: purposefully aligned, open source, interconnected, quality, skinnable, supported, small and mobile. In fact I'm pretty sure that some required coding (esp regarding APIs and interoperability) will only happen if we develop the knowledge commons you wisely indicate @strypey: reviews, case studies, HowTos, handbooks etcetera. Not to mention, open source signaling protocols which could potentially circumvent any 'need' for an OAE coordinating/ stewarding team.

I work on open source person-to-person signaling protocols and collaborative frameworks. The OAE vision could crucially complement such tools (from any sources) as long as we prioritize human interactions, and become increasingly conscious and intentional regarding the actions we automate. I.e., focus on inclusively developing our software specifications, and IMO, let the code follow-- more or less per an essay of mine.

We could use that GH repo, but text can be stored almost anywhere, and I would prefer to be using a free network service, one not owned by a monopolistic corporation with a history of fighting against software freedom

I'm open to using open source alternatives to GH, etc; however, I think we're in a war (hopefully of ideas, not people) and I'd consider it unwise to refuse using the tools of the 'enemy' (multinational corps) if that refusal might sabotage our activities. Most cultural & tech revolutionaries I know, myself included, live precariously on limited resources. This includes many people & teams who provide open source alternatives to multinationals like Google; and I think it's important to be mindful to not multiply our points of potential failure.

For example, I use GH and GDocs extensively, because I literally can't afford to depend on alternatives which might vaporize either suddenly or gradually. Nor can I even really afford to do thorough research to ensure that specific alternatives are practically as stable (both technically, and in terms of attentive human support) as GH and GDocs.

I don't feel very dependent on GH and Google because it's easy for me to frequently export GH data & GDoc text.

With all that said: Yes, text can exist anywhere, and this could potentially include an effectively distributed/p2p directory of media resources. (Easier IMO if true distributed computing like Holochain effectively develops, but also possible without it.) We could probably even simulate distributed versioning with the right person-to-person protocols. That's kinda up the alley of my work; however, it's quite a lot of work to coordinate people in consistently performing predefined cooperative actions. In my experience, most people aren't anywhere near ready to reliably do that except when they're keenly motivated by direct personal (not collective) compensation or extractive profit.

For a start, I'd like to suggest again that we make more use of the editable context boxes at the top of each thread, to harvest the cream of each discussion.

If you think that you, anyone else or all of us could help facilitate some process which effectively and inclusively harvests the cream of each Loomio discussion, and advances OAE goals, please go for it: but I perceive that as being a labor-intensive process, requiring dedicated curators. I don't expect it to be P2P, because it will privilege whoever can afford to spend the most time curating. It could work, nonetheless, but I think that'd proceed slowly & methodically through inclusive 'baby steps'/ adjacent possibilities.

Regarding the origins of the OAE group: I suppose that one hope was to develop a code commons on Github; however, I'd also guess that creators felt flexible about how OAE might eventually manifest. I think that Joshua Vial (already tagged), @ahdinosaur and Simon Tegg may know the history most personally.

Seems to me, the important overviewing @strypey is proposing needs to be done in ordinary English, in spaces shared with app users? As distinct from dens of code?

Suggestions are welcome for what platform to use, either an existing service, or a piece of software and an offer to host it. For example, would anyone be willing to host an instance of Ward Cunningham's Smallest Federated Wiki (SFW) for use by the OAE group? The federated wiki offers the intriguing possibility that in future, each app and service group that has people participating here could run their own SFW instance with their own copy of the OAE knowledge base, so that no one group has overall control of its development.

@strypey @mikeh8 just wanted to say thanks for putting some thought into housekeeping and organizing this crazy bunch of content! :heart:

"the code (like the truth) is out there, and the real challenge is to strap it together, and convince people to use it instead of the datafarms. So the outputs of this group need to be knowledge commons; reviews, case studies, HowTos, handbooks, and so on. But beyond that, where are we going to a) collaborate on such texts, and b) publish polished recommendations for the people we hope to make use of them?"

My own two cents, that @strypey already knows, in part:

• "the real challenge is to strap it together, and convince people to use it" : YES, +100 to this. with one specification: let me repeat that IMNSHO, the only way to convince people to use it is to offer it as a service, i.e. as something you can get (let's ignore the cost until we agree on this, is my view) with a few taps on a smartphone, hosted somewhere in the cloud. If all we produce is a nice package with a wonderful manual on how to install it manually on your own server, it's useless.

• "where and how we are going to collaborate and publish": as fas as I am concerned, that is the last of the problem. I could do that anywhere, for all I care. What I personally need to do it is being paid appropriately, for long enough to produce something decent. Otherwise I cannot afford to spend so much time on this, it's as simple as that. Of course, without good howtos, studies, etc, it is waaaay more difficult to find sponsors, I know that very well. It is the chicken and egg problem that has me stuck since about 2013. And is the reason why I have been saying from the beginning that whoever can do this http://per-cloud.com please DO go ahead by yourself with my thanks, just give credit where credit is due.

• This said, I've done a bit of thinking in the past about this. See for example the "looking for sponsors part" of http://per-cloud.com/percloud-proposal-2017/ , and then the rest of that website, starting from the current version of the proposal in the sidebar. Hopefully that is useful starting points for doing what Stripey describes.

@strypey Group conveners could also make use of the Loomio Gold 'tag' function now available in this group. And some pinned threads?

@strypey "I would prefer to be using a free network service, one not owned by a monopolistic corporation with a history of fighting against software freedom" Yes! In addition . . as a non code-hacker, I don't find Git repos generally easy to access and to find stuff in. That may be culture and lack of practice on my part. It's partly the (small) barrier of getting a login to get access. So . . pls think quite broadly and 'publicly' about "where are we going to collaborate on such texts, and publish polished recommendations"?

"make more use of the editable context boxes at the top of each thread" Definitely, exploit the thread headers. It might be that Git repo users don't routinely do much of this recurrent reframing, which might account for the difficulty I have finding my way to human-readable content and over-view?

Seems to me, the important overviewing @strypey is proposing needs to be done in ordinary English, in spaces shared with app users? As distinct from dens of code?

There have been at least two or three threads through this group:
* hosted collections of usually existing open source apps that may share a single signon (or not, but I think they usually do);
* hosted collections of usually existing open source apps with a dashboard and some navigation and some other shared features;
* flocks of usually new open source apps that work together via common protocols and vocabularies.

Examples of all three approaches continue, sometimes announced here, sometimes not.

And I might have missed an approach or two...but I can identify all of those.

Harvesting the discussions would be a wonderful idea.

One other thing regarding housekeeping, @joshuavial, @gregorycassel, or @richarddbartlett may be able to correct me on this, but as I understand it, the original goal for the OAE group was to produce a code commons, which is why there is a link to a GH repo on the front page.

I think most of us now realize that the code (like the truth) is out there, and the real challenge is to strap it together, and convince people to use it instead of the datafarms. So the outputs of this group need to be knowledge commons; reviews, case studies, HowTos, handbooks, and so on. But beyond that, where are we going to a) collaborate on such texts, and b) publish polished recommendations for the people we hope to make use of them?

We could use that GH repo, but text can be stored almost anywhere, and I would prefer to be using a free network service, one not owned by a monopolistic corporation with a history of fighting against software freedom. For a start, I'd like to suggest again that we make more use of the editable context boxes at the top of each thread, to harvest the cream of each discussion.

@mfioretti again I encourage you to start a new thread where can discuss the details of your PerCloud proposal and related issues. Just go to the main page of the Loomio group (https://www.loomio.org/g/exAKrBUp/open-app-ecosystem), and click 'new thread'.

I know it doesn't seem to make a big difference if when using Loomio by email. But when we work together to make sure our comments are appended to the relevant thread, it's a lot easier for folks to follow the conversations using the web interface. Opening new threads on new topics, allows us space to dive deeper into them, and makes it easier for new members to find the discussions most interesting to their projects.

Firstly, thanks heaps to @bobhaugen and @mikeh8 for sponsoring a gold package for this group, and supporting the Loomio crew! Does anyone have any thoughts about the existing subgroups, or any suggestions for new subgroups (subgroups can be a useful way to group and focus discussions on a related set of topics). Any ideas on how the 'categories' feature could be useful to us?

My apologies for the 2 month absence. With the holiday season looming, it's probably not the best time to start ramping things up. But if anyone would like to help me tidy up the community centre a bit, so to speak, ready for a fresh wave of activity in the new year, that would be great. Let's use this thread to discuss what tasks that might involve, and who can help. For a start, I'll have a look at the existing discussions and subgroups, and try to put together a one page summary of what's already here.

As always, anyone is free to start a thread on anything they think would be useful to discuss here, or revitalize an existing thread by adding a new comment. If you don't know how to do that, or you have any other questions about how Loomio works, please feel free to ask here, or join the Loomio Community group, and its user support subgroup, and ask there.

hello all,

yesterday I finally managed to put together some thoughts about this, and especially a request to some experts to seriously reconsider their proposals to "break up facebook" and similar, and to go the personal cloud / coop-hosted route instead. The post is here, obviously both feedback and help to circulate it online as much as you see fit are very welcome: http://stop.zona-m.net/2018/11/why-do-you-still-propose-to-regulate-break-or-clone-facebook-google/

As of now, this OAE group is Loomio Gold. This means (a) subgroups can be created as discussed above and (b) categories on the group page can be created and applied by coords. Means also, Loomio gets $90 to help support their development. Bob Haugen and I have sponsored the Gold account for one year. I'll open a thread on sponsorship so that next time round other sponsors might opt to kick in.

Strypey, I made you a coordinator. Really glad to see the initiative on getting this large and varied group organized!

Lots of great stuff here. I'm off to Aotearoa (NZ) in a week, where I’ll be for the rest of Oct, back in the studio on Nov 10. So I won’t be able to contribute much to OAE until then, but I’ll do my best to keep a weather eye on the discussions as they continue. A few quick things.

1) @mfioretti please feel free to start a new thread to discuss PerCloud, and the ways your vision for it is different from (and similiar to) related projects. You could just copy and paste your comments here as the discussion starter. Let’s keep this thread focused on housekeeping (how we intend to use this group productively).

2) There is already a thread started by @Lynn to discuss the vision for CommonsPub, so let’s discuss that and related projects there. @bobhaugen totally agree, this is not the place for projects to hold their internal discussions, but rather for people from different projects to compare notes, and help each other solve common problems. Perhaps that thread could also be the place for a more general exploration of the pros and cons of ActivityPub and the fediverse?

3) @olisb , I'm not familiar with the Loomio features for "archiving". Can you explain in more detail what you're proposing, taking into account the replies by @bobhaugen and others? My feeling is that even if old threads get archived, it would still be useful to have an up-to-date summary of their contents in the context box for each one (like the 'minutes' of a meeting). If we understand our history, we're less likely to go around and around in circles as new waves of people join the group.

4) @asimong I have seen comments from Loomio devs that their greatest expense by far is paying salaries. They don't seem to be worried about server load. Also storing old discussions puts no load on the server unless they are being read, and the space taken up by ASCII text is negligable.

5) @bobhaugen @mikeh8 thanks so much for offering to sponsor a gold membership for OAE for a year! That's very generous. I know the Loomio crew would appreciate it. Could you please open a new thread about actioning that? If anyone else is able to kick in, they could offer their pledge in that thread, and maybe we could come up with enough pledges to cover 2-3 years of gold membership?

6) @olisb @gregorycassel I would like to be a coordinator of this group. When I'm back, I volunteer to look into who are the coordinators of our existing working groups (subgroups of this Loonmio group), and make sure there are some who are still active here.

@mfioretti this spinoff of the Open App Ecosystem might overlap with your plans in some useful way: https://docs.opencoopecosystem.net/

We're building on ActivityPub, which runs on the open Web, and can offer both group pubs where people can just register for an account as well as self or service hosted personal pubs. The first app is designed for phones.

It will develop slowly, though, because we got some user bases who will transition from monolithic systems and want to keep those running for a year or two while trying out the decentralized solution.

One of the groups, Freedom Coop, started as a refugee work solution, but that effort has not gotten very far.

Public Loomio groups and threads have RSS feeds available.

Just add .xml to the end of a url

Its a way to quickly get all the text from a thread.

They dont appear to render well in most web browsers showing all the xml tags. They do render properly in desktop Firefox, including adding the context post at the beginning (Android Firefox also shows all the xml)

I've been using Feeder from FDroid on Android to read feeds, unfortunately it doesnt display the context post, but does quickly provide all the comments from a threads feed, which sometimes helps with frustrations of interacting with Loomio via mobile.

I guess there may well be add ons that will provide decent RSS parsing for desktop chrome/chromium.

Hello @mikeh8 and all.

FTR, the "commons transitions UK" thread is not accessible by me. No idea, sincerely, if my point of view/proposed priority warrants a subgroup, I leave that for all the others to decide. But I do want to add one more important reason for me to feel the "AS A SERVICE" approach as a priority: environmental impact. Consider one million people, each with their individual physical server, each with its own cheap batteries or UPS, vs the same million people hosting the same individual digital clouds on, say, 100 independent datacenters, one every 10K users, but all with top notch boards, power supplies, cooling ...

The amount of hardly recyclable hardware (i.e. the amount of raw materials, often coming from child labor...) AND energy consumption, both for producing the hardware and using it with MANY cheap power supplies is surely much bigger in the first case. NOT good.

@mfioretti Note a brief related sub-thread in commons transition uk This seems an important orientation - and yes, warrants a subgroup here? As marco is saying, this is a whole other politics, by no means inconsistent with self-management of P2P servers, apps-wise and protocol-wise, but built on distinct user-community priorities - the point regarding freedomboxes , holohubs etc and 'rich' users is germane. This is very 'solidarity economy'. @michelbauwens1 - on the lines of Bruno Frere and 'precarious' ppl. Getting off-topic now, pardon me. Yes, a subgroup!

Hello all, just a flash comment for now, to clarify what my main interests are. Yesterday @stripey wrote:

"For example, Marco is interested in deploying a set of open apps for use by an individual who wants to self-host, on their own end user PC, or a Rasberry Pi, or a spare desktop in the closet. This could also be of interest to anyone from IndieWeb who's here, or from projects like FreedomBox/ FreedomBone/ YUNOHost"

This is not completely correct, albeit there surely is a lot of overlap with those other projects. My main interest is to develop software AND infrastructure for individuals who CANNOT self-host their own personal content, data etc, on ANY personal physical server, of any kind.The idea that refugees, senior citizens with zero IT skills, native people living where no24/7 electricity or broadband are available... can use a Facebook account on their smartphones, but not "solutions" that in practice are reserved to "rich" people with enough skills and money to personally own and manage a freedombox upsets me. Even ignoring those "special" cases, I seriously fear that anything beyond the skills and means of today's average FB user is doomed to fade or remain irrelevant. Like desktop Linux. Please see here for more http://per-cloud.com/percloud-and-the-others/

Software-wise yes, there are a lot of pieces that should be common between my proposal (why it still is only a proposal is clearly explained in the website) and all the other projects that Stripey mentioned.Probably, Indieweb is the closest one. but the essence of my proposal is packaging mostly existing stuff to be really usable AS A SERVICE. Something that sure, geeks could still install on their own RaspberryPi, but the other 99.99% of people will simply "order"/activate from any provider of their choice, NOT on their hardware, with procedures not more complex than setting up a facebook account.

I am not only inclined, I will commit to kicking in with you and whoever else on that, if needed. We'll need to figure out how to manage the kicking in.

I've no stance on the tech issues being raised re archiving, durable links etc. As @bobhaugen mentions, what I have offered - if @strypey fails to get a free Gold upgrade from the Loomio crew - is to sponsor Gold at 'community group' rate, for the OAE group for a year. Seems to me, the significance and complexity of the work warrants helpful facilities, like subgroups. Happy to note that @bobhaugen is also inclined to kick in on that.

Yes it's an unresolved issue, and I am probly more behind the times than you. But in this case, if there is no real reason to kill the existing threads, why do it?
My understanding of Loomio is that the discussion threads are ordered by most-recent activity, so the old ones will scroll off the bottom anyway.

I'm all in favour of CoolURLs (or I suppose CoolIRIs as they might now be called). But it's an unresolved issue, isn't it? PURLs ... what is the latest thinking on that, anyway? How do CoolURLs integrate with blockchains? Do you get my point about the unsatisfactory nature of long-term reliance on one particular domain name? Unless that domain name is going to act as a PURL server in the longer term? Or am I behind the times somehow?

Unless you can keep the links alive, I would prefer to keep them where they are. Cool URLs don't change. If there's a server load problem, let's figure out what to do with that.

I was just speaking from ignorant speculation -- maybe the server load is of no consequence... The general question of keeping past discussions alive is a good one, though. Surely they shouldn't be tied to any one domain, or one server, or one system? I'd love to see some distributed system (ok, probably like Secure Scuttlebutt, which I know very little about but would love to get into somehow...) where I imagine discussions could really be securely archived?

I tend to cite whole discussion threads, not individual posts, so a solution that would keep the links alive would be fine with me. Don't know about other peoples' practices.

But what is the issue to whom about the load on the Loomio servers? Is this group getting out of hand? I understood that @mikeh8 offered to pay for the group, and I would happily kick in as well. I think it is a useful historical record that some projects have already spawned from and more will spawn later.

I enquired recently about the apparent lack of ability to download a whole (public) thread in Loomio, and my enquiry was received positively. Personally, I envisage downloading a thread as an HTML file, ideally with some generic Javascript that would enable some of the same functionality as in the live thread. Links from wouldn't be a problem, of course, but links to the thread -- hmm -- but don't you think, @bobhaugen that it would be good to have old ones made static somewhere? Otherwise the load on the Loomio servers will just keep increasing...

Please don't archive older discussions here. They are linked to many other places, and you will kill those links. Alternatively, implement redirects, but that's a lot of work.

Great ideas @strypey I'm an Admin and keen to stay as one - if volunteers don't come forward I could try to chip in but it might make more sense to archive a lot of stuff and write up a summary which links to all the useful bits...? I'm very up for more guidelines like @gregorycassel suggests - and would even go further to suggest we might want to define how "decisions" could be made, if the OAE, or any of its subgroups were ever to evolve into more than chat groups... Keep us posted about activities in HK! ;)

Could be a good idea. Suggestion: start with one or two subgroups that you know would be interested and see how it works.

I doubt that the CommonsPub (P2P economic network software project) will want to coordinate work here, because we are trying to live in our own evolving system, but at least some of us will continue to participate here in one way or another, and be available for discussions.

@Bob Haugen:

That’s interesting. Whatcha got in mind?

What I'd like to do is find consensus on a program of work for this
group over the next few months, to make sure we're getting value out of
the time and attention we're all putting in here. If possible, I'd like
to get the Loomio crew to sponsor OAE with a free gold service level so
we can create and manage subgroups to focus on different aspects of OAE.
If not, I guess we can try to break into a larger number of aspect
discussions using threads.

For example, Marco is interested in deploying a set of open apps for use
by an individual who wants to self-host, on their own end user PC, or a
Rasberry Pi, or a spare desktop in the closet. This could also be of
interest to anyone from IndieWeb who's here, or from projects like
FreedomBox/ FreedomBone/ YUNOHost. I would make this one subgroup, in
which a number of discussions could take place about the different use
cases for these projects (and others relevant to single-user
self-hosting), and how a user could decide which one to use for their needs.

Then there are the folks who joined since Open 2018, most of whom are
interest in the "commons cloud" concept, deploying a set of open apps
for use by community organizations. This may or may not overlap with the
work Bob and Lynn are doing on ValueFlows and CommonsPub, which could
also have its own subgroup (or set of threads) focusing on open apps
sets for implementing mutual credit and other economic transactions.

Basically, what I'm proposing is that we try to identify some generic
families of open app ecosystem, so folks can focus in on the discussions
that are most relevant to the work they're doing, or the projects they
want to get started. I think this is where we can drill down into the
nuts and bolts of our implementations, our tech choices, and our
successes and failure, and help each other avoid dead ends, or identify
areas in which we can pool dev resources.

I'm in the Hyatt Regency room 1301 (sha tin), for tomorrow's platform coop meetup as well, have a lunch and dinner appointment today, but if you were in the neighborhood,

else we talk in the next days!

I am right in the middle on our fundraising campain at Startin'blox, and won't be able to help with the tyding, but I love the intiative ! Kuddos !!

I like your generic community guidelines, @gregorycassel !

What doesn't work for you in long threads @mike_hales ? People could decide to put the most recent posts at the top, that might help alleviate your issues? I prefer the newest and flat options, personally. Cheers!

I'm one of the (many) coordinators and I'd like to remain one. The coordinator role here is minimal and I hope it stays that way. If we ever have intense conflicts, perhaps we could consider adapting something such as these p2p-oriented Generic Facebook Community Guidelines which I've written. Loomio groups aren't structurally so different from facebook groups -- no offense meant!-- so I suppose that such adaptation would be easy.

@strypey , your request for some volunteers to summarize old big threads by editing the Context box is potentially quite valuable, if anyone responsibly pursues it. Thanks for asking. I find responsible reporting to be quite hard to do, and I will pass because I'm over-committed in duties for various groups.

This thread is very long now. The Loomio interface is not great with very long threads? Would it be helpful to open a new branch of this one?

Hopefully, it's about to get very busy

That's interesting. Whatcha got in mind?

The main group has a lot of coordinators. If you look at the member list, it's everybody through Mikey (assuming they show up in the same sequence for you as for me, I am a coordinator). I don't know how coordinators for subgroups work.

@Danyl Strype Is it possible to start a thread in the main group for each of those topics (or any topics we decide we want to move to a sub-groups) and then move those threads to a subgroup after we get traction in that thread? Kind of: spawn if off from the main group? It would kind of be a more natural transitions and possibly easier to get people to come on board?

Also, if you no longer have any interest in lurking in this group, now might be a good time to unsubscribe. Hopefully, it's about to get very busy ;)