Configuration Page for Jitsi Web Configuration
I was looking to document the feature I hopefully add in https://github.com/jitsi/jitsi-meet/pull/11052 but did not find a matching page.
Should we add a new page for jitsi-web configuration in the "Self-Hosting Guide / Configuration" Section? It would document features like Youtube, Etherpad etc. Or even some normal modification like changing the icon.
Sounds good yeah!
The generic iframe is in PR and is no ot yet part of the project.
sure, I will only create the page documenting what is in master.
That's what I understood, FWIW :-)
While adding the feature descriptions, is there a clear distinction between Configuration and Deployment? Because it kind of blends together in the guide. E.g. Docker has its own Configuration section: https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-docker#configuration
Also can I introduce a third folder level to the documentation?
docs/devops-guide is getting confusing with all the files for "Configuration" and "Deployment" mixed together.
I would seperate them in:
docs/devops-guide/deployment and docs/devops-guide/configuration
On the web part we have a general configuration section, which is where I think this belongs.
Docker is different because it translates environment variables into the aforementioned config.
On the web part we have a general configuration section, which is where I think this belongs.
Docker is different because it translates environment variables into the aforementioned config.
On the web part we have a general configuration section, which is where I think this belongs.
Docker is different because it translates environment variables into the aforementioned config.
On the web part we have a general configuration section, which is where I think this belongs.
you meant https://jitsi.github.io/handbook/docs/dev-guide/dev-guide-configuration ? This is kind of tugged away for, maybe it should be moved to the "self hosting guide/configuration" section?
Docker is different because it translates environment variables into the aforementioned config.
They are named a little bit different but they do nothing else (at least the web configuration variables). I would vote for it being all in one, e.g.
as table:
config.js Option |
Docker-Jitsi-Variable | Example | Description | Remark |
|---|---|---|---|---|
etherpad_base |
ETHERPAD_URL_BASE |
http://etherpad.meet.jitsi:9001 | If set, it adds a "Open shared document" link to the bottom right menu that will open an etherpad document. | You may need to add 'etherpad' to the buttons section. |
Like the sectioning already done:
etherpad_base
type: String
If set, it adds a "Open shared document" link to the bottom right menu that will open an etherpad document.
Examples:
etherpad_base: 'https://your-etherpad-installati.on/p/'
ETHERPAD_URL_BASE: 'https://your-etherpad-installati.on/p/'
The examples could be structured with multi language tabs.
Or one could use tabs in general.
The benefit would be that the same configurations aren't split between two files and do not have to be documented twice, as they are currently, e.g.:
- https://jitsi.github.io/handbook/docs/devops-guide/devops-guide-docker#shared-document-editing-using-etherpad
- https://jitsi.github.io/handbook/docs/dev-guide/dev-guide-configuration#etherpad
The problem is that not everything maps one to one. Related to config.js sure, but putting every component's config together would be too large IMHO.
I agree the current situation is not great and could be improved.
Maybe a way to split them is semantically. You'd have options related auth for example, transcriptions, etc, which require multiple components, and then the core config.js reference, which would indeed have tabs or a table or something to reference the Docker counterpart.