Hubzilla | Contribute - contribute@zotlabs.org

Fri, 31 Dec 2021 17:26:36 +0000 last edited: Mon, 17 Jan 2022 00:47:14 +0000

emanuel @ la bonne heure wrote the following post Fri, 31 Dec 2021 17:26:32 +0000

Interim report on contributions to Hubzilla (as of 31.12.2021); Fundraising campaigns? Unifying documentation and tutorial writing?

Hi friends involved in Hubzilla,

I made an attempt to get an overview over the actual contributors to Hubzilla, in order to identify possibilities of improvement of our collaboration. Here's what I found out. Please comment below what is missing or what is wrong, then I can correct the summary. And please react to the questions raised in the end of the post. Thanks.

Contributions subdivided by tasks and subprojects:

Coding + reviewing issues (core + official addons): 5 members (@Mario Vavti, @Max Kostikov, @M. Dent, @Andrew, @Zap)
Documentation:
- The "official" 3: 1 for users, 1 for admins, 1 for developpers (en/pl; especially the one for users hasn't barely been touched for 3 years; a considerable part needs to be updated): Apparently almost nobody devotes themself to these. Spanish translation partially done by @Manuel JF , available here and here
- Another one, for users (de, mostly untouched since 2 years): 1 author (@PepeCyB)
User tutorials:
- The "official" one (covers only how to set up a channel for the first time; not touched since 3 years): apparently nobody in charge or assigned
- the ones by Disroot for Dishub (en/es, cover a lot; untouched since 2 years): 10 authors?
- the ones by TheChangeBook (fr, very recent, growing, including videos): 1 author (@Dan d'Auge)
- the ones on tiksi.net (ru, seems to cover a lot, seems to be updated): 1 author (@Max Kostikov)
- the ones by The Lazy Teddy (en, cover a lot; untouched since 9 month): 1 author (@The Lazy Teddy)
- the ones by PepeCyB (de, cover a lot, mostly untouched since 2 years): 1 author (@PepeCyB)
- the ones by Manuel (es): 1 author (@{manuel-j@zotum.net})
- the one by Ashley Eversole (en, covers only how to set up a channel for the first time; recent): 1 author (@Ashley Eversole)
- the one by adnan360 (en, covers a lot but not extensively; untouched since 10 month): 1 author (@adnan360)
- the ones by @hEARt PhoniX (yet to be published, in progress): 1 author
- the overview video by Danie van der Merwe (en, 2 years old): 1 author (@GadgeteerZA)
Translations
- of user interface (through Transifex): 372 members
- of "official" documentation (through Gitlab): except for polish translation (author unclear; this one seems more or less complete), all other attempts of translations seem to have been sufficated at the core more than 2 years ago
- of Disroot/Dishub documentation: 10 authors?
Website (not yet published re-work in progress since some months): 4 members (@hEARt PhoniX, @RockyIII, @Witcraft, @emanuel @ la bonne heure )

(I know there are also some admin tutorials existing, but I'm not sure if there's a need for them, thus I didn't collect them here.)

Subdivided by usage of tools for quality assurance:

Gitlab for coding and reviewing issues: used by 5 members
Transifex for translations of the code: used by 372 members
Gitlab for documentation and its translations: barely used, at least not in the last 3 years
Gitlab for tutorials and their translations: barely used, at least not in the last 3 years
Gitea for tutorials by Disroot, including its translation into spanish: used by 10 members? But not anymore updated in the last 2 years
Hubzilla wiki app (has only changelog and no approval functionality):
- tutorials by The Lazy Teddy, untranslated (used by 1 member)
- documentation + tutorials by PepeCyB, untranslated (used by 1 member)
- tutorials on tiksi.net, untranslated (used by 1 author; combination with hubzilla articles)
- tutorials on TheChangeBook, untranslated (used by 1 author)
Cryptpad (has only changelog and no approval functionality): tutorial by Ashley Eversole, untranslated (used by 1 member)
socialhome page (I guess, there's no changelog and no approval functionality): tutorial by adnan360, untranslated: used by 1 author

Why did I do this overview?

The re-worked Hubzilla website will contain a "get involved" page. There, we want to indicate how people can contribute with donations, as coders / issue reviewers, as addon developpers, as documentation authors, as tutorial authors, as translators or as part of the website team. Just for that alone, we need to be able to indicate where people can knock or send their money. In addition, we must be able to specify on the website links to usable and, above all, updated resources for the documentation and tutorials.

Before we can state these informations on the website, we need to know

from all people interested in writing/updating/translating the user documentation: Do you feel the need for joining forces and working on the same document (en + translations)? If yes, please consult among you and inform us from the website team as soon as possible about the choice of technical means, the (possibly new) publication location and how interested people can contact you for participation. The choice of technical means should consider how to deal with quality assurance of content and translation as well as inclusion of non-techie people. I dare to assume that many involved and active people are not confortable with git/gitlab/gittea/... this could at least be a reason for the scattering of the efforts in the past years...
the same thing from all people interested in writing/updating/translating the admin documentation
the same thing from all people interested in writing/updating/translating the user tutorials
if some people are willing to coming up with an overall crowdfunding solution which aims to remunerate / fund the contributions to be done to Hubzilla by different people. This solution should state thoughts on how the funded sum will be distributed and maybe a roadmap (definition of task packages, time period for deployment per package, time period for fundraising per package, platforms for campaigns)

!@Hubzilla Support Forum

show all 46 Comments

Emanuel

Fri, 31 Dec 2021 18:23:11 +0000

Conceptual draft for info on website if decentral tutorial solution is kept. Does not correspond to reality. Is not conclusive.
Image/photo

Max Kostikov

Fri, 31 Dec 2021 18:25:59 +0000

@emanuel @ la bonne heure
There are several articles in Russian Hubzilla wiki on @tiksi@net
https://tiksi.net/wiki/net/(d0ad)(d0bd)(d186)(d0b8)(d0ba)(d0bb)(d0be)(d0bf)(d0b5)(d0b4)(d0b8)(d18f)(20)Hubzilla/Home

RockyIII

Wed, 05 Jan 2022 14:40:09 +0000

maybe it is a good idea to post this also at https://zotadel.net/channel/support

adnan360

Thu, 06 Jan 2022 09:14:25 +0000

When I first started out with Hubzilla, most information I got was from blogs where other people tried stuff and wrote about it. This has issues like information was scattered over different blog posts/sites and some details were missing for which I had to search even more to get to further information. Blogs are good, but they are inconsistent and not good enough for official documentation, especially for users.

I think there should be a single user documentation covering everything for Hubzilla with acceptable detail. Other articles can be mentioned for extra reference.

adnan360

Thu, 06 Jan 2022 09:22:31 +0000

I dare to assume that many involved and active people are not confortable with git/gitlab/gittea/...

GitLab would be perfect for this since it has a WebIDE and it can handle single/multiple file edits within the browser without ever using the terminal.

hEARt PhoniX

Thu, 06 Jan 2022 09:37:16 +0000

@adnan360
The first step will be my tut for the changes with roles etc coming with HZ7.
I am writing in Markdown using pandoc so that I can easily render various formats, including an epub for convenient offline reading.

adnan360

Thu, 06 Jan 2022 10:25:28 +0000

@hEARt PhoniX Are you using Pandoc's markdown? Or converting from Markdown to those formats?

I haven't tried Pandoc's Markdown that extensively. But it seems close to markdown. So I guess either one should be easy to write and collaborate on.

Emanuel

Thu, 06 Jan 2022 11:58:31 +0000

I added the russian sources by @Max Kostikov and the partial spanish translations by @Manuel JF to the overview. @RockyIII , as I thought, mentioning @Hubzilla Support Forum retroactively did not make this thread show up in that channel, because the access control list is set for a post at the creation and can not be changed anymore. Anyway, I think we should boost the channel @Hubzilla | Contribute to be used more intensively, it should not be considered as a child channel of @Hubzilla Support Forum

hEARt PhoniX

Thu, 06 Jan 2022 13:52:09 +0000 last edited: Thu, 06 Jan 2022 13:54:28 +0000

@adnan360 I am not familiar with the various flavors of markdown. But I quite love pandoc for these purposes. I have not used it in a few yeas as I have hardly written anything worthwhile since then, but I am picking up where I left it off and refresh my memory.
What I love is that it easily goes into git.

Once I have got something to shareI will be happy to so, the more eyes and minds go over it, the better. I am a lonely writer, though. Please do not be disappointed, I do prefer coming up with something to myself and only sharing if it is at a certain level of "completeness".
Hubzilla sure is a huge beast to pour into text.

adnan360

Thu, 06 Jan 2022 17:53:48 +0000 last edited: Thu, 06 Jan 2022 18:13:38 +0000

@hEARt PhoniX Then probably you are using normal markdown. I thought you were using Pandoc's Markdown. That's why I was asking. :)

Once I have got something to shareI will be happy to so, the more eyes and minds go over it, the better. I am a lonely writer, though. Please do not be disappointed, I do prefer coming up with something to myself and only sharing if it is at a certain level of "completeness".

No problem. I thought the community will be preparing something together.

Edit: If any help is needed with documentation, I will try my best to help.

hEARt PhoniX

Thu, 06 Jan 2022 18:26:37 +0000

@adnan360 I will be very happy for proof readers, to iron out misunderstandable explanations, get things clearer and so on. At that point help will be very much appreciated.

Haakon Meland Eriksen (Parlementum)

Thu, 06 Jan 2022 19:37:22 +0000 last edited: Thu, 06 Jan 2022 22:55:33 +0000

Interesting write-up, the heading could be "Decentralized Community Collaboration".

Given /help has been available at all Hubzilla sites for a decade, in several large languages, I find it bittersweet when people in 2022 write they found help "scattered across the Internet", as if this was a bad thing, and it should have been in a central place (be gone foul fiend), like closer to you, on your own hub, which it is. Clearly, someone is wrong or something is wrong. The question is what is wrong, and maybe - if the patient has incompatible symptoms - more than one thing is wrong at the same time, and each thing needs separate treatment.

The code repository has been central, if moving three (?) times. The documentation has been in the same location. Contributing has been to the same location. Translation of strings has happened at Transifex, and is as far as I know the only exeception to the centralized repository for contributions.

Why then the perceived difficulty of contributing, when the reality is no different than say Spacy (a Python library)? Even I have managed to contribute.

Collaboration is hard if someone says "I have an idea" and people answer "Great, let us help you make something else.", and easy if people answer "Great, let us help you make that." To a large degree, the decentralized Hubzilla community has been of the latter category, a big thank you to you all.

I think quite a few people conditioned on centralized solutions have a hard time accepting decentralization features, but once they grokk it, they wonder why they accepted centralized features in the first place.

However, till that enlightened maturity sets in, there have been numerous suggestions, both technical and none-technical, which flip-flop between centralization and decentralization, with a bias towards centralization.

I think if we embrase /help as the place for contributing documentation, replacing the static pages with an editor, and add a sync mechanism to notify other hubs about available updates, and then allow the hubmin to merge what they want or subscribe to good documenters, then this can be resolved in a decentralized community manner.

Edit: I would also suggest a standard web page channel be included with every site upon installation, containing the synced content from hubzilla.org or zotlabs.com or whereever the main contributors agree upon is the current main site. When visitors come to the hub, this could be set as the default at the hubmin's discretion, so it does not matter which hub new people are pointed at, or it could simply be turned off or deleted by the hubmin who wants to offer something else.

Witcraft (Hubzilla)

Thu, 06 Jan 2022 23:49:21 +0000

@Haakon Meland Eriksen (Parlementum)
One of the strengths of the constitutive decentral principle of the web is that it allows parallel approaches, and offers for different perspectives - without any need to enforce a specific way to "resolve" it, or talk down other ways.

So I guess it is just as valid for those of enlightened maturity to prefer research in a system of a large numer of servers with varying software versions and many parallel, more or less relevant URLs (influencing search engine ratings), and with content contribution via git, gitlab, or editors (to a central code repo) as it existed in the past decade - as it is valid for plain users and interested hub-less non-users to prefer to look up relevantly compiled and recommended information in a more mundane system of a uniquely identifiable, easily referrable, and representative web address, like other, more prevalent Fediverse projects offer.

Witcraft (Hubzilla)

Fri, 07 Jan 2022 00:15:37 +0000

@emanuel @ la bonne heure
Review and Guide, EN: https://medium.com/we-distribute/the-do-everything-system-an-in-depth-review-of-hubzilla-3-0-692204177d4e
Russian Content (not sure what's in there, though...): https://blog.desdelinux.net/ru/hubzilla---%D0%BF%D0%BB%D0%B0%D1%82%D1%84%D0%BE%D1%80%D0%BC%D0%B0-%D0%B4%D0%BB%D1%8F-%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D1%8F-%D0%B4%D0%B5%D1%86%D0%B5%D0%BD%D1%82%D1%80%D0%B0%D0%BB%D0%B8%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D1%85-%D1%81%D0%BE%D1%86%D0%B8%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D1%85-%D1%81%D0%B5%D1%82%D0%B5%D0%B9/

Review with a great connectivity matix (even though a bit sceptical towards Hubzilla), DE: https://www.hasecke.eu/post/hubzilla-vs-mastodon/
Intro guide video, DE:
https://www.youtube.com/watch?v=KlEw_KehI2g

1 hr overview video, EN:
https://www.youtube.com/watch?v=_9nCAOM5V1g

How to register video, EN:
https://www.youtube.com/watch?v=8Vnm7f9Mc8Y

Register an account and get started video, EN: https://www.youtube.com/watch?v=dSB_767G8Uc
Hubzilla Preview video (on mobile), EN:
https://www.youtube.com/watch?v=iBFRSvndSOo

Sign up / Set up profile video, EN:
https://www.youtube.com/watch?v=qleLIHi5NXk

How to setup install Hubzilla on Ubuntu video, EN:
https://www.youtube.com/watch?v=OoeARil4iAc

Haakon Meland Eriksen (Parlementum)

Fri, 07 Jan 2022 06:32:16 +0000

@Witcraft All the sources you mention have great content, I am not talking down the content or content creators.

I am not talking down say Medium or Wikipedia or Drupal or Wordpress for its content or content creators, all of which I frequently visit.

However, I am talking down those very same solutions as centralized solutions, which even the creator of wiki does.

The Fediverse offers another possibility, content sync across space. Why should I have to visit say Mastodon's official domain space when any Masto-hub at any other domain could have done the job, if sync of these resources could be added?

As I wrote, I find it bittersweet we - collectively, including me - have not grasped fully what that means. My suggestions are just pebbels in this context, and maybe they hit the shore, or maybe they hit water and create rings that resonate.

hEARt PhoniX

Fri, 07 Jan 2022 06:36:06 +0000 last edited: Fri, 07 Jan 2022 10:23:53 +0000

@Haakon Meland Eriksen (Els Mussols) I have to admit, I do not fully understand the intention of your post and what exactly you are targeting at.
I will try an answer by writing what comes to my mind when reading your comment. It may be going into another direction than you intended, if so I am sorry and ask for correction / clarification.

The very nature of official documentation is that there is a kind of centralized necessity: It should be included within the software.
This means there have to be some instances that coordinate and lastly approve it in some way.

The problem with documentation that is "scattered all around the internet" is that I as an information seeker have to check: is it up to date, are the given advice valid?

Even the documentation which is included within Hubzilla as it is now has got one drawback which I think needs to be taken into account: It is publicly accessible. on every hub. Which means - and I have seen this - these documentations appear in search engine results. I think this is something we need to keep in mind or either accept, or find another way.
Not only do search engines punish content that does appear on several web pages and rank it down, but also if we update the official documentation, can we be sure that the hubs which appear in search results have updated? Then this would appear to a novice information seeker as valid information, but probably is not. Take into consideration the changes for Hubzilla 7.

Which is why I ask the question: should we find another way to present the documentation? Maybe include a static basic information page with every hub that links to the centralized resources? And I am very aware of that this is just a compromise. But I want information to be as accessible as possible, and that means decentralization is exciting and I do want it (obviously). Even one of the world's biggest decentralized collaboration projects have got a centralized main access point, take Wikipedia, or the Linux kernel. With GNU/Linux you have an example for the other approach: there is no real centralized access point and this does create an entry hurdle for absolute newbies: which information is relevant for me, which distribution should I try, how do I differentiate all the documentation and tutorials I find as valid for me, or not valid?

I have not yet come to an idea I like through and through.
One way I had in mind was:

create a "documentation" channel with every hub
this channel is only accessible from that very hub
there is a webpage with the documentation provided by this channel
connect every channel to it or at least provide the hub-wide accessible webpage to the menu

There can be different approaches to this channel:

It is local and somehow updated via database updates
This channel will be the largest cloned channel ever

While the latter does have it's charme, I see a problem: If something happens to the main channel and for example it's content gets tinkered with it will be synced everywhere.
Perhaps a combination of both may be interesting.
Though obviously any channel can be cloned, which would a must for such an important channel. We would also need concepts for shared administration / responsibilities and that would very much need a good backup concept for channel content so that if broken the channel could be recloned.

Another thought I had was to automatically link any admin channel to the official main announcement channel. My thought behind that is that that way all important information will be delivered to the admin. Unless they disconnect, obviously, which still is a choice.

And just in case the criticism has also been targeted at my approach that I do not want to share the actual writing process: Please accept that as my decision. I love writing, but I am a lonely writer. I have got a concept in mind. I do not care too much if that is going to become the official documentation, or not, I will just do it.
Saying that, any writing process does have a point where it should become a collaborative process, and that involves proof-reading, lecturing, finding bugs, ironing out edges and beta-testing instructions and the general understandability. This is where I am hoping that there will be friendly hubzillians who will be willing to add.
Not sure, if this has been relevant, though.

adnan360

Fri, 07 Jan 2022 06:59:29 +0000

@Haakon Meland Eriksen (Parlementum) Decentralized documentation is not bad. I found many important details through the /help documentation.

I think the point is that there are some areas that need change/updates (I assume this is the reason for this post). Design also changes as the time passes. The design that was once cool 5 or 10 years ago might not impress users of today. The help page has huge paragraphs with small font size which attracts only the ones who are eager to learn, not average people. People associate social media with fun, not reading huge paragraphs of text just to understand the system and post some pictures.

Having documentation available centrally doesn't mean we can't have decentral documentation. /help can stay on every instance too like it currently is. I like this setup. But there could be something wrong with how it currently exists, because I couldn't find anything about Hubzilla when I first started out. Maybe it was bad SEO, maybe it's the Help option being under a menu, maybe the information was burried inside a paragraph, or maybe it was something else.

We should not forget that people starting out are not the same as someone who is experienced with the software. Something might be so obvious to experienced users, but can be really difficult for someone starting out. Documentation has a responsibility towards those users. This makes a difference between an ok project and a very loved project.

Another point is that some well-thought software doesn't even need users to refer to a reference manual. They use popup tooltips, useful hints within the interface text so that the user is not lost on what to do next. I think Hubzilla can improve on this.

Now that I read your comment, I thought of searching "hubzilla help" and found https://hubzilla.org/help/en/about/about which would've been helpful if I found it when I first started. But I couldn't think of searching with that exact phrase and find it back then.

Witcraft (Hubzilla)

Fri, 07 Jan 2022 07:50:59 +0000 last edited: Fri, 07 Jan 2022 08:30:06 +0000

@Haakon Meland Eriksen (Parlementum)

As I wrote, I find it bittersweet we - collectively, including me - have not grasped fully what that means.

I understand your frustration. Yet, we should not forget that this is the specific perspective of one highly technology capable Hubzilla-experienced insider who knows how to contrubute code in a git process. This may represent a prototype, a specific share of people who could use next gen social media like Hubzilla.

Other target groups may have other needs, and those may be a bit more prevalent in the world. I was (and still am) one of those, and although Hubzilla is, in the end, no witchcraft ( :wink: ), I see the hurdles of using it, grasping what is is, or even just finding it - from own experience and with every attempt to promote it to my social circle. Technology development is one thing, but I understand it's the developers' philosophy to leave it up to the users to create communities. However, communities grow around a crystallization nucleus to spawn around, and if we want a prospering project community, that needs a home, too. We tend to forget that community building is no side job, but dedicated work: It needs an infrastructure, knowledge management, strategies, info material.

Decentralization is a good thing - Letting everybody work isolated from others is not. If devs thought differently - Why are there central code repos like github, framagit, codeberg? If scattering is a good thing: What do linux admins need distro repos for?

In philosophy, society, and technology many a genious system has been invented: Most of them work perfect - That is, until you add humans to the recipe... For me, it comes down to the question: Do we want the people who cater for the technology (and segregate all others) - Or do we want the technology to cater for a relevant portion of (prospective) users? And I'm not even saying it has to be "either - or", just that - If our goal is to make people aware, truely offer them alternatives, expand the user and the developer community, we should be less picky about and not mourn society's enlightment status of grasping and submitting to the grand philosophy, but maybe try something in our range of influence that works better.

"Take the people as they are, because there are no others"
- Konrad Adenauer, the first chancelor of the modern Germany

Dan d'Auge

Fri, 07 Jan 2022 09:22:42 +0000

#fr : Quand j'aurais terminé le wiki d'aide de TheChangeBook, je veux bien participer à la traduction fr de l'ui
#en : When I finish the TheChangeBook help wiki, I'm willing to participate in the fr translation of the ui

Haakon Meland Eriksen (Parlementum)

Fri, 07 Jan 2022 09:47:54 +0000

@Witcraft , please try to forget Hubzilla for a second, and read me again, this time with "workflow" in mind.

What you are saying is akin to saying there should be one menu for Burger King and only available at one Burger King outlet in the entire world.

What I am saying is akin to saying there may be one menu for Burger King and it should be available at all Burger King outlets in the entire world.

Now, which model is used in the real world by Burger King, yours or mine? Why is that? Because the latter model works much better for those who Burger King?

Witcraft (Hubzilla)

Fri, 07 Jan 2022 09:59:34 +0000 last edited: Fri, 07 Jan 2022 10:49:58 +0000

@Haakon Meland Eriksen (Parlementum)

Now, which model is used in the real world by Burger King, yours or mine?

Paper menu for guests who know a restaurant's address and are read to order: yours (which makes sense because the stock for specific meals / participation in franchise activities may differ between franchise regions and single restaurants).

For informing people about the profile of Burger King and its typical food, helping them find their regional restaurant, staying up to date, Burger King has exactly one central website (just like anybody else in the web). It would be interesting how they would do without one, and without paying ads and commercials...

I know that there are other restaurants that do not have the budget for commercials, and no webpage - Some of whose menu I happen to have seen, because I went past them, was accidentally hungry, and went in - In not so few cases, I went out again, after looking at the menu and deciding it was not for me. So when deciding where to eat, I usually look in a central compilation of restaurants, and for details on their specific webpage, to decide where I eat (If the threashold is really low, I might just have a short look inside to decide further). When a friend (whose taste is about the same as mine) strongly recommends a restaurant, and I cannot find a webpage with reasonable effort, I might try it when I have nothing better to do (I am, after all those years, technically not too bad at eating and tasting food - So I would probably understand immediately why it's worth a try).

RockyIII

Fri, 07 Jan 2022 10:26:47 +0000

@Haakon Meland Eriksen (Parlementum) we got your point from your fist post but this Burger King analogy just does not fit...

@hEARt PhoniX made some interesting suggestions - What do you think of it?

We hope that you like to participate by putting the new info pages together, will you help?

Haakon Meland Eriksen (Parlementum)

Fri, 07 Jan 2022 10:47:40 +0000

@RockyIII I think not. Yes it does. Each Burger King instance has its own set of customers as each Fediverse instance has its own set of members, each has it own budget with expenses and income, and if one instance fails there is no impact on any other instance. There is very little difference other than words between a community hub, a coop and a franchise, though those differences are important. I suggest to draw a map and try to see where those are.

PepeCyB

Fri, 07 Jan 2022 11:10:40 +0000

My perspective on things in general and the intention for my own contributions:

In general, the documentation should be urgently revised. The section for the user is very dry, omits a lot because it was not thought of when it was written that the normal user, who is not technophile, does not know many things that are "self-evident" for the creator. An unsophisticated person has "question marks over his head" when he reads it (although the documentation is not bad). But that is a completely different issue from the question of whether it should be centralised or decentralised.

In fact, the current form is good in approach, but still unfortunate. A web search for Huzilla help yields numerous hits because each hub provides the documentation. The problem is that it depends on chance (and the algorithms of the search engine) which documentation ends up in the top ranks. The previously uninformed searcher may thus come across documentation that is located on an instance with an older Hubzilla version... and he may thus receive "outdated" information. He may end up frustrated because he then creates an account and a channel on a hub with the brand new version and suddenly things are completely different. "You see, I knew it right away. It's far too complicated this Hubzilla!" And he's gone. Or vice versa... he reads the latest documentation and ends up on an older hub where some things don't work the same way or not at all.

This problem would again suggest a centralised documentation. However, a certain number of different versions would have to be kept available in parallel. This is also a barrier for newcomers ("Yes, which version is mine???").

This knot is difficult to dissolve. A spontaneous idea would be to keep the hub's own documentation, but to prevent it from being (completely) crawled/indexed. And a central documentation for several versions (if they differ significantly) would have to be kept ready to be indexed by search engines. Within the decentralised-local documentation, one could additionally refer to this documentation - suitable version.

It would also be important for the normal user - especially the very new user - to have better access to the help. I don't know if it is still the case, but in a newly created channel the menu item "Help" is not even available. It has to be activated and displayed first. At this point, however, a newcomer is already out of the loop. The optimal standard would be that the help is generally displayed in the upper bar (can be hidden... then it's in the help

). Even better, of course, would be an additional context-sensitive help that shows up without being obtrusive.

Now to my intention... that is, to what I have written on Hubzilla (apart from the few translations of the official help). These are all (I hope and believe) very simple explanations. Exactly for those who come from the data octopuses and just want to switch. You always have to take a step back and put yourself in the shoes of a new user who has only ever known Facebook and co.

One way to improve the user documentation would be not to overwhelm the reader right away. Hubzilla is an „eierlegende Wollmilchsau” ("egg-laying wool-milk-pig"… this is a fun German expression for something that can do everything), but that puts off many. The basic mistake lies with the recipient, because he thinks he has to know and use everything right away. But we have no influence on that. The user documentation should therefore initially be limited to the perspective of a classic social network user. The possibilities that go beyond this should be available, but not immediately visible (and thus outshine the basic information). Certainly, important hubzilla-specific core functionalities have to be mentioned from the beginning, but more specific functions should then only be presented if the user is also interested in them. There will be many who are satisfied with the basic functionality. And it is precisely those who should not be scared away.

Witcraft (Hubzilla)

Fri, 07 Jan 2022 11:22:19 +0000

@Haakon Meland Eriksen (Parlementum) I am confident, each of us can make his point on a proxy stage like Hanmburger franchise restaurant chains. But while that may be a fun challenge for some, I doubt it will take the community any further.

Since I announced that I work on a Hubzilla webhome (and in fact, long before), I have received feedback and encouragement from quite a few users who genuinely liked this idea (or rather said it was overdue). So that path seems to serve a few users who express it, probably a few more who do not, and probably yet more who will express it once they have become users (altghough that is projection from own experience). I was encouraged by several project acteurs (including you) to just contribute where I feel something is missing - So I did. But there is no need and (from my side) interest in a theoretic discussion about an "either ... or": I think it can only be of benefit for a decentral project to have multiple contributions from different perspectives. So I will be following activities on your preferred path with interest.

hEARt PhoniX

Fri, 07 Jan 2022 11:25:43 +0000 last edited: Fri, 07 Jan 2022 11:47:14 +0000

@PepeCyB

The problem is that it depends on chance (and the algorithms of the search engine) which documentation ends up in the top ranks.

This is exactly what I addressed with my thoughts above, which I would like to drive the attention to before this meanders into other discussions.

But I just checked: As soon as you have created a channel, you have got the help link in the menu.

I am following the approach of targeted information from basic to detailed and divided into little chunks. It will become obvious when I have got something more substantial to show. The drawback: We DO net Screenshots. I think we CANNOT do without. But they can also become outdated. But that is a task that will need to be done.
More important is to get it more accessible in any way.
As of now it is a "wall of text" as a colleague calls such stuff. That is difficult for many people not inviting.

You are very right to criticise this.

I am trying several approaches to address this.

Edit:
If anyone is not happy with me writing my own doco, feel free to take over. I will write anyway. If it will be used here, or not. I have got plans with that for Hubzilla and can achieve that either way.

RockyIII

Fri, 07 Jan 2022 11:31:33 +0000

@Haakon Meland Eriksen (Parlementum) do it does not at all ...
If you see a commercial on TV about a Burger King product - who has produced and paid for it?

The image you have from an whopper - who has created it in your head?
Can a franchise change the products?

The Burger King Cooperation is a very hierarchic organization
The HZ community is not a all a coop and there are no franchise

...
First we need better help pages, The way they get distributed is a second question...
Sad that you don´t want to help to get better help pages... why not?
What do you think of @hEARt PhoniX suggestions ?

Witcraft (Hubzilla)

Fri, 07 Jan 2022 11:49:20 +0000

@PepeCyB

However, a certain number of different versions would have to be kept available in parallel. This is also a barrier for newcomers ("Yes, which version is mine???").

This knot is difficult to dissolve. A spontaneous idea would be to keep the hub's own documentation, but to prevent it from being (completely) crawled/indexed. And a central documentation for several versions (if they differ significantly) would have to be kept ready to be indexed by search engines. Within the decentralised-local documentation, one could additionally refer to this documentation - suitable version.

I agree, it takes a mix: You need, too, a good inline help in the version you work with, for specific workflows. For general info and guidance, for people who do not even know a hub, you need an address to inform yourself. I understand you have been involved in the rejected wikipedia article about Hubzilla, and one of the reasons it may have been perceived as a "not relevant project" might have been that it did not claim relevance anywhere where normal people look, but in files and help subpages on parallel servers. I doubt that they will probe the empty login masks of a one of the hubs, test the menu, go to help and then accept this as a valid source.

And this info needs to be layered for a wide range of initial knowledge (We had a lot of constructive discussions on that issue), while at the same time making clear its character as the Swiss Army Knife of the Fediverse.

BTW: Your How-Tos were one of the main ressources that saved me from giving up before I finally arrived here - Thanks!

oRx-Qx pirateradio

Fri, 07 Jan 2022 12:03:47 +0000

I never understood why there is in Help page Administrator and Developer sections. Certainly something what makes feel non-tech people the help is not meant for them.

If this sections could be moved separately into Admin area and member help would become much clearer and understandable with guides for most frequent things, It would be valuable for newcomers.

PepeCyB

Fri, 07 Jan 2022 12:07:12 +0000

If this sections could be moved separately into Admin area and member help would become much clearer and understandable with guides for most frequent things, It would be valuable for newcomers.

@oRx-Qx pirateradio

I think that's a very good idea!

hEARt PhoniX

Fri, 07 Jan 2022 12:12:13 +0000

@oRx-Qx pirateradio Something like that is at least on my list, I want more targeted information chunks that are admittedly overwhelming enough, but if you then still need to face info that goes even more over your head as you are neither admin nor developer, this is couter productive.
Just not 100% sure how.
The above mentioned doco channel may help with that as it would enable more possibilities, but also create other challenges and complications.

Haakon Meland Eriksen (Parlementum)

Fri, 07 Jan 2022 12:30:56 +0000

@RockyIII I think @hEARt PhoniX and I understand each other very well. I will comment more on this if time allows.

The Burger King analogy is of course not perfect, the point and parallell I intended is very direct - is there a common menu for all Burger King customers, yes, do we in the Fediverse want common updated documentation written for the new member, yes, should the Burger King customer need to visit a BK in Washington, USA to find the menu, no, it should be at the local Burger King, and similarly, should the Fediverse member need to visit some other site than the one they have found their way to, no, it should be available where they already are.

oRx-Qx pirateradio

Fri, 07 Jan 2022 14:08:43 +0000

@hEARt PhoniX

If i can add another opinions
- Hubzilla can be implemented offline, somebody can happily use it connecting communities via wifi in the dessert, in the forest, in countries cut from internet, which can happen anytime in Iran, China, Russia, Kazakchstan, Burma. Hubzilla can also be used in organisations internally connecting systems. Having all needed documentation locally is better.
- Doc not to be scattered on internet could be done by restricting search engines on those hub doc pages, having them indexed just on Hubzilla project site with proper versioning like other software projects.
- Doc channel or synchronized wiki is nice idea but I dont know if it is possible. Clone can be made just by original channel owner and i would not want to be in the skin of owner of hundreds clones channel. Much easier is to provide exported content of such a channel to import on hubs in installation process or anytime and provide a Doc-wiki app with settings to channel name. But that is for wiki-like doc, not meant to remove UI integrated help. Making clones and update docs content in a network is better to setup among admins of trusted cooperating hubs.
- Community support and guidance for template repository and docs repository and contribution would be great.

Haakon Meland Eriksen (Parlementum)

Fri, 07 Jan 2022 14:55:12 +0000

@adnan360 I think we are very much in agreement.

Yes, the documentation needs updating. This is currently centralized as explained above. The main crew found by @emanuel @ la bonne heure are busy programming, so who will contribute the updated documentation and how?

One method is to get an account at the current centralized git repo at Framasoft, use the built in GitLab Web Editor or GitLab Web IDE in your browser to update the documentation, and submit it for review and inclusion. Whenever hubmins pull a new version, your included updates will be available to all from a central location, and it will be updated and "official documentation".

However, this centralized option, which is fine and works, has been an available option for years, but you are not happy with the result so far, so maybe it does not work that well?

Enter many good suggestions for improvements in this thread, which does not depend on the old way.

However, I would say any solution which rely on other centralized software is just a new take on the old, saying to the world "yup, our own decentralized publishing solution sucks so bad we have to use those other centralized solutions". Such a result would be sad, not true, and counter-productive for promoting the Fediverse.

Dan d'Auge

Fri, 07 Jan 2022 15:18:42 +0000

@Haakon Meland Eriksen (Parlementum)

One method is to get an account at the current centralized git repo at Framasoft

When I wanted to create an account on Framagit, I could never use it because the account is always awaiting approval by an administrator.

hEARt PhoniX

Fri, 07 Jan 2022 15:58:27 +0000

@oRx-Qx pirateradio You are very right with that sich a channel would be ... responsobiliy. That I think I mentioned too. Another way could be for example via database updates, but that would require someone programming a safe way to transform files into readable databaae dumps.

I would like to think that doco channel that exists on every hub idea further, though. It could be used as an automated teaching tool. Upon channel creation you get a message that explains how to navigate to another channel and so on. It could make you write (automatically private not distributed posts to that channel. It could automatically send you posts that link you another piece of basic information and slowly teach more very basics, unless you opt out.
I do not know how to program this, though, it is just an idea. I can only provide a concept and texts.
That channel could also automatically show off different aspects of Hubzilla's functionality. File storage access at another channel, wiki, a living, breathing website (doco). That again could include different media to get one started, how to post text and videos, a downloadable book with the documentation that is also the website ... ... ...
On the long term I would like to get using Hubzilla for what it has been built: sharing information. And where to start better than with Hubzilla info?
These are all just very rough ideas, and will surely need refining. Ideas are welcome.

But this is a long haul. The very first step is to get the doco back into a more usable form and let it grow. All that is nothing that can be done in a day. But I am sure that that can and should be done by a team. But that team needs something to work with, which I am trying to get going. The beginning is, as mentioned earlier, a doco on the channel role and access management changes coming with Hubzilla 7. I am already sectioning that, one basic part, ibe more advanced part and one targeted especually for those upgrading, giving a comparison of the old concept and the new one so that you can hopefully understand the changes and decide how to continue.

@Haakon Meland Eriksen (Els Mussols) I am not sure if I really understand fully where you are aiming at. Your restaurant franchise analogy says: a central point develops the main concepts, the individual branches work with them. So far so good. I am just not sure where exactly you are aiming at. Yes, HZ is somewhat like that. The kernel develops concepts, codes, creates doco and all that. This has to be somewhat centrally managed, if it is you, me, whoever. Each hub admin relies on that kernel to do the right thing and to take development into the right direction, or to learn from failures. And in turn each member relies upon their admin(s) of the hubs where they have got clones.
I just do not get what you are critisizing. IMO we need a central place, hubzilla.org as a kind of public frontend. That is the place to get info out, especially for those who are still searching for a solution. That is a logical place to go to, if I am someone interested in Hubzilla, asking the question, if it is the tool for me. We would be stupid to forgoe that chance.
That does not rule out to have basically the same info on each hub, on the doco channel, if that idea gets traction and we think it could ve useful. But for SEO and other reasons that should not be publicly accessible. We cannot make sure that if you get to a hub and start reading, that the info is both accurate and still valid.
But that doco channel would also give the local admin the chance to document what individual settings that channel has got. Perhaps that can also be automatically generated, and the admin can also write comments.

I do not know. Before I lose myself into meandering ramblings, I'd better hit submit.

Haakon Meland Eriksen (Parlementum)

Fri, 07 Jan 2022 17:03:55 +0000

@Dan d'Auge , thank you - you just illustrated my point perfectly! I take this as a +1 for my suggestion for changing to a mechanism for decentralized updating of documentation with a sync-and-merge to interested parties.

Note: I am not one of the git repo admins.

This is not a critique of those admins for not answering your request for an account. I do not know if you have tried to contact say @Mario Vavti to introduce yourself as a trustworthy person who should be given access. In any multi-user system, those with power must be trustworthy, so they do not introduce malicious features due to incompetence or malice. This can be done through documentation, see https://capec.mitre.org/data/definitions/63.html by a bad actor. I hope you understand I am not saying you are a bad actor, I am saying it is prudent by any admin to protect their members by vetting a new admin. I am advocating as little centralization of power over documentation as neccessary, but not less than that.

This example just illustrates a typical challenge in most multi-user computing systems I have used the last 25 years - where to draw the line of power between who is allowed to do something and who is not, and how to do it not to anger or annoy people by being too strict, too slow moving or too unwilling to accept suggested improvements.

adnan360

Fri, 07 Jan 2022 17:45:31 +0000

@Haakon Meland Eriksen (Parlementum)

However, this centralized option, which is fine and works, has been an available option for years, but you are not happy with the result so far, so maybe it does not work that well?

Enter many good suggestions for improvements in this thread, which does not depend on the old way.

However, I would say any solution which rely on other centralized software is just a new take on the old, saying to the world "yup, our own decentralized publishing solution sucks so bad we have to use those other centralized solutions". Such a result would be sad, not true, and counter-productive for promoting the Fediverse.

I think how the documentation is distributed is all fine. I agree with this point by @OrX_Qx pirateradio :

Hubzilla can be implemented offline, somebody can happily use it connecting communities via wifi in the dessert, in the forest, in countries cut from internet, which can happen anytime in Iran, China, Russia, Kazakchstan, Burma. Hubzilla can also be used in organisations internally connecting systems. Having all needed documentation locally is better.

It makes it really handy. Since it works I'm not suggesting any change in this distribution style. I was suggesting change in the content and presentation.

@Dan d'Auge

When I wanted to create an account on Framagit, I could never use it because the account is always awaiting approval by an administrator.

Yes, their staff is having trouble keeping up with increased signups due to the pandemic (I read something like that on homepage or somewhere). I used GitLab.com account to login and had no issues. Didn't even have to register.

adnan360

Fri, 07 Jan 2022 18:17:11 +0000

@PepeCyB

The previously uninformed searcher may thus come across documentation that is located on an instance with an older Hubzilla version... and he may thus receive "outdated" information. He may end up frustrated because he then creates an account and a channel on a hub with the brand new version and suddenly things are completely different.

This is an absolutely good point. The PHP documentation solves this by showing a note on which features/changes were new to which versions. (example 1, 2) This way, even if someone is reading the latest docs they'd have an idea that a feature might not be available in older versions.

This knot is difficult to dissolve. A spontaneous idea would be to keep the hub's own documentation, but to prevent it from being (completely) crawled/indexed. And a central documentation for several versions (if they differ significantly) would have to be kept ready to be indexed by search engines.

I think this would be a complex way to solve this. I just realized GitLab also does documentation similarly. e.g. There are /help pages for gitlab.com and framagit.org and subpages are linked in a way that point within the instance, just like Hubzilla does. And still I can find an answer quite easily. Searches mainly go to gitlab.com, with sometimes other instances as later entries. It works maybe because they broke down the topics in multiple pages or they have good SEO.

Haakon Meland Eriksen (Parlementum)

Fri, 07 Jan 2022 18:20:58 +0000

@hEARt PhoniX , thank you as always for being kind and not too rash to dismiss what others are trying to say, unlike me, who is often guilty of being blunt and uncouth. At soon 48 years old, I am also getting more impatient, rather then less, and generally of the opinion that I am okay with saying what I think directly and not worry too much if people agree or disagree with me. I have just as much a right to express my opinion as everyone else, and neither of us are by default bad people for doing so. On that note...

Bilbo Baggins, LOTR wrote:

I don't know half of you half as well as I should like; and I like less than half of you half as well as you deserve.

I think a documentation channel as you suggest is a very good idea. I do have some questions as to how we can optimize the attributes of such a beast using the current feature set of Hubzilla. For instance, do we use the article feature, the wiki feature or the web page feature of the channel for content creation? I think a choice of one of these is best, to ensure all the content is in one one format. Who is allowed to contribute? Is it public or member only?

I think a default public web page channel might serve a similar function. I am not sure if these two channels are complementary to each other, or one is redundant. I guess that depends on how it is actually done. If I as a curious person and potential new Fediverse member get a link to visit hubzilla.rocks or elsmussols.net or some other domain, and the hubmin there has this default channel turned on as a start page, then I would see what I needed to see, regardless of which domain I was pointed to. I do think stripping out potentially malicious documentation (scripts etc) would be a required step before merging.

I do not agree official documentation has to go through a centralized power.

Nupedia failed after 4 years because of this, see https://en.m.wikipedia.org/wiki/Nupedia . I was there, hoping to see an article about world religions, it never happened, because of their seven step approval process. Wikipedia's open editing with undo killed Nupedia in a few months. Now, Wikipedia has "armed guards" preventing contributions about decentralized publishing solutions unless weird criteria are met, which are arbitrarily enforced by self-apponited subject "experts". See also @Dan d'Auge example in this thread.

If I can accept to merge good bits of documentation from others, just like I can accept posts and apps from others today, then the documentation I need is available where I am. Hopefully, I would be able to contribute something back. That is community writing.

Scott M. Stolz

Wed, 13 Apr 2022 07:06:42 +0000

@Haakon Meland Eriksen (Parlementum) I can understand how you dislike centralized solutions, but self-hosted WordPress, self-hosted Drupal, etc. are not centralized solutions at all. They might not be federated, but they certainly are not centralized. Wikipedia is centralized. Facebook is centralized. But not self-hosted independent websites.

As far as the documentation goes, the documentation that is included with Hubzilla is centralized from the standpoint that it gets modified in the master GIT repository and is distributed to everyone that updates Hubzilla. It is decentralized from the standpoint that every installation of Hubzilla has its own copy.

For the help documentation that gets distributed with every copy of Hubzilla, some coordination is useful so we don't duplicate effort or step on each other's toes.

As far as posting documentation on independent websites, no coordination is needed, but collaboration and feedback would be useful to produce the best possible documentation.

So I think a documentation channel would be very very useful and I would definitely participate. I've been thinking of writing some Hubzilla documentation, so working with some like-minded people would be great.

Haakon Meland Eriksen (Parlementum)

Thu, 14 Apr 2022 08:41:48 +0000

Scott, I do believe a documentation channel was started, and I encourage contributing to it, rather than not.

self-hosted WordPress, self-hosted Drupal, etc. are not centralized solutions at all. They might not be federated, but they certainly are not centralized. Wikipedia is centralized. Facebook is centralized. But not self-hosted independent websites.

I once held this view too, probably over a decade ago. Times change, what I held to be sufficient to call something decentralized 15 years ago does not hold up in 2022. When your self-hosted site goes up in flames for the n-th time, you too may reconsider that position, but that is up to you.

You are of course right, federation is a part of this "update" to decentralization as I see it, and so is cloning, remote auth etc. Resilience is then also a part of my updated understanding of decentralization.

The consequences and implications may not be immediately appreciated, but a single example may at least provide food for thought:

Given I contribute documentation to a self-hosted instance of <whatever> located <whereever> from my own self-hosted <whatever>, and this remote <whatever> burns to the ground, blows up, stops working, is abandoned by the remote hubmin, or the doc channel is deleted by mistake, I and all the other contributors would like a copy of our own contributions to be at my own self-hosted site and hopefully similar for the other contributors.

This is not an unreasonable request in 2022 with the updated decentralization we now have, but with the old one we would have say too bad, and start over.

Scott M. Stolz

Thu, 14 Apr 2022 18:53:47 +0000

@Haakon Meland Eriksen (Parlementum)

I once held this view too, probably over a decade ago. Times change, what I held to be sufficient to call something decentralized 15 years ago does not hold up in 2022. When your self-hosted site goes up in flames for the n-th time, you too may reconsider that position, but that is up to you.

Then what is the alternative?

Even with Hubzilla, you have two choices:
1. Have a hosted Hubzilla instance.
2. Create an account on someone else's hosted Hubzilla instance.

With option 1, you have the same exact issues with self-hosted WordPress. So I do not see how that is any different.

(Hopefully, you install Hubzilla via Softalicious on cPanel instead of via command line, so Softalicious updates Hubzilla for you, but either way, someone has to host Hubzilla somewhere.)

With option 2, the users themselves are not decentralized because they are still depending on someone else's Hubzilla website being up and running, and are subject to that particular Hubzilla website's rules.

Sure, the federated nature of Hubzilla and the Zot protocol allows multiple websites to interact with each other, but each public Hubzilla instance is basically a mini-Facebook that is federated with other mini-Facebooks. The competition and federated nature of Zot are good and much needed, but it still depends on Hubzilla instances which have to be hosted somewhere.

What is the third option?

Even if you create an app that people can download on the Android, iOS, and Amazon app stores, that is basically a closed-source self-hosted instance of Zot or Hubzilla and you are dependent on maintainers to keep the app running.

When people talk about decentralized, I always ask "whose computing resources are being used?" Does the user have an app and their personal device is the host? Or does it need to be hosted somewhere (on a web host / in the cloud)?

I can see how identity can be decentralized since that does not have to be running 24/7/365, but published content has to always be available and can't solely be stored on a personal device. Your content shouldn't disappear from the internet every time you reboot your phone or you run out of battery. Typically a web host provides a server that is up 24/7 that your copy of Hubzilla resides on.

Even if we are talking about the content being copied and distributed so it can be pulled from multiple nodes, that isn't exactly what Hubzilla does, and because of privacy concerns, should not do. For example, if you upload confidential documents to your Hubzilla cloud storage, you don't want copies of them all over the internet. They are private. Not to mention the issue of third parties paying for storage space for content that they are not even allowed to access. And even with this, someone is still hosting a copy. Someone is still paying for storage space.

I can understand your frustration with self-hosting. But when you are talking about content, it has to be hosted somewhere if you want it to be available on the internet. Identity can be on your phone, but realistically, not content that needs to be available 24/7.

Is there a better way? If so, what?

I haven't figured out how to make content available 24/7 on the internet without a computing device, an internet connection, and software. And that is the challenge you have when talking about decentralization. Someone somewhere has to provide computing resources and host the app or script.

Haakon Meland Eriksen (Parlementum)

Thu, 14 Apr 2022 23:09:57 +0000

@Scott M. Stolz , the premiss of this old thread as I recall is collaborative updated documentation, so I have tried to answer in that context.

Some in our community seem to agree it is wise to have a single channel at some single hub for this, rather than contribute to /help , which is available to all sites, even in several languages. You do not need to know anyone, nor any channel, it is just there if you fancy a read at the hub you are at or anywhere else. That is decentralized documentation, right?

The old way of contributing updated documentation is considered too difficult, which I have no problem with.

I just think it would be even better to fix a mechanism to the decentralized benefit of all hubs at the same time. We write collaborative documentation with a new mechanism, and all get a copy. Easy.

Scott M. Stolz

Thu, 14 Apr 2022 23:35:08 +0000

@Haakon Meland Eriksen (Parlementum), perhaps you create some sort of decentralized document system, where individuals create their own documents, and each hub or node decides whether to host a local copy or not. And then allow collaboration. The challenge will be version control and forks.

But it would be nice if someone could see all of the available documents on the network, and then decide which ones would be copied to their local copy of Hubzilla. And perhaps make packages of articles so they could all be downloaded with one or two clicks.

So anyone can create documents on the network, and other hubs decide to use that documentation on their site or not.

Scott M. Stolz

Thu, 28 Apr 2022 16:59:25 +0000 last edited: Thu, 28 Apr 2022 17:07:11 +0000

I saw something interesting in Github. Another project had a Github repository that simply held documentation in markdown format. It could be updated by multiple people, and could be forked. It got me thinking.

If you took those files, and placed them in a certain directory, the script could display those documents as help files / documentation for the user.

You could have certain ones bundled with Hubzilla that are updated every time Hubzilla gets updated, but the site owner could override them or add to them by placing their own set in a specific docs-override folder (similar to how you can overwide tpl files by creating a new theme).

You can set it up so that site owners can download multiple languages of the docs, and the site could display multiple sets of documentation, a set of docs for each language. You can also set it up so that the site owner can create supplemental documentation without affecting the Hubzilla main documentation.

Would something like that work? Collaborative yet decentralized distribution?