Use scenario-based approach for server type description

[gegeweb]

When I started working on the French version of Choosing a server type page, I felt the need to specify and explain what the different types of servers were and in what context they could or should be chosen. And especially for the central server type.

So I added an introduction in the spirit of the proposal below.

This could be something like after the main title:

---

Start by first (re)asking yourself the question(s), do I really need my own server, and if so why do I need it?

The server can be configured in three modes, whether the server is at home or at a service provider (cloud, dedicated server...). The answers to the "why?" below will help you choose:

1. The Jamulus concept is great! I have the bandwidth or already have a server in the cloud or a dedicated server and I too want to contribute and expand the range of public servers available with low latency in my region.
2. The concept of Jamulus is great! But... for my band's training sessions, it's annoying to sometimes be disturbed or listened to by others on public servers.

3. You are, for example, an organization (school, conservatory... ) and want to reference several servers by groups, musical genres or classes administered by your organization, your teachers or your students.

[ann0see]

Yeah. This would be a good option.

But let's first wait a bit. I'd add it to the next version (not the one for this weekend) to allow translators to translate the current changes.

[gilgongo]

Right now, it's not intended that the reader begins with the Server Types page because the "spirit" of Jamulus is not to have to think about servers and just connect to an existing one.

That said, if your intention is to re-cast the page in terms of "use cases", then that might be a better way of explaining it (assuming we're right about those use cases) so it's worth exploring. I don't see why "whether the server is at home or at a service provider" is relevant to server type though, but perhaps that means we should address the case of large numbers of channels here too?

[gegeweb]

I don't see why "whether the server is at home or at a service provider" is relevant to server type though, but perhaps that means we should address the case of large numbers of channels here too?

I have a defect... I like to explain or clarify ;) It's just to say that the server can be hosted at home or on a remote server (cloud or dedicated server)

[gegeweb]

That said, if your intention is to re-cast the page in terms of "use cases",

Not necessarily, but if you start reading this page, it means that the intention or query about the use of a personal server exists. So to specify here again the reason(s) for choosing the type of server seemed to me judicious.

I have a defect, I said. ;) In my work, when my users (miraculously) read my documentation, they ask me : « where is the digest ? » :D

[gilgongo]

In my work, when my users (miraculously) read my documentation, they ask me : « where is the digest ? » :D

Well yes :-)

I'll have a go at re-casting the English for the release after this one and we can discuss on this ticket.

[gegeweb]

I'll have a go at re-casting the English for the release after this one and we can discuss on this ticket.

OK.

Before editing your reply you said :

However, if you mean you think the current "digest" page (Running-a-Server.md) is not direct enough, then we should examine that issue on that page.

Reading the doc (before wanting to translate it) I had understood that multiplying public servers on public central servers could be problematic. (I am curious to know and understand why. Because I run a public server - which is often used by European musicians! - up 24/24. I started in private mode, but I was desperately lonely! I've new friends, some near my location, since I run it in public mode.) But not a private server, or a private central server? That's why I also wanted to emphasize the purpose of each type of server. Why, before howto. And above all is it really necessary?

And I've aded this introduction on Choosing-a-Server-Type page because on the Running-a-Serverpage :

---

If you really want to run a server, it’s very important that you read and understand what type of server you want to run.

[links to Read about server types]

… then come back here.

---

So, you start reading 'running a server' and at the beginning of the document you are invited to read the page about server types. It seemed logical to me to place this introduction in the begining of the server type page.

And as a reader it seemed logical to me to browse the documentation this way when I searched for information about servers.

[gilgongo]

I had understood that multiplying public servers on public central servers could be problematic. (I am curious to know and understand why).

If you look here you'll see about 90% of public servers are empty most of the time. There is also a limit (150) on how many servers each central server can list. It's possible that people set up public servers without understanding these issues and a) fill up the central servers so that "legitimate" ones can't connect and b) make Jamulus look like a ghost town.

Because I run a public server - which is often used by European musicians! - up 24/24.

But if you used somebody else's public server instead of setting up your own, you will have done Jamulus a greater service, because the more servers there are, the more they are empty, and people don't want to to join empty servers.

But all this is a separate issue. If I understand you correctly, the question here is whether we need to get people to understand the type of server before or after things like (for example) "running a server doesn't mean you'll get better performance." Is that right?

It seemed logical to me to place this introduction in the begining of the server type page.

To re-state the question, yes. No harm in that.

But as I said, I think I'll have a go a re-casting the English for both of these pages according to your suggestions and see what that feels like.

[gegeweb]

But all this is a separate issue. If I understand you correctly, the question here is whether we need to get people to understand the type of server before or after things like (for example) "running a server doesn't mean you'll get better performance." Is that right?

Yes, and after.

I plan to switch back to private mode when the new friends will have integrated the usage of the private server and will meet each other there by connecting directly to it. I just have to add a status page on the web page indicating the musicians currently online.

Nothing more to do with the doc, but maybe more central servers per region/music genre would allow to have more public servers permanently available.

Or to see with the documentation, a page, to reference "private" servers permanently available and open to all who are not referenced on a central server.

[gilgongo]

maybe more central servers per region/music genre would allow to have more public servers permanently available.

a page, to reference "private" servers permanently available and open to all who are not referenced on a central server

These things would (if I am correct) make the situation worse. We do not want to encourage people to set up even more public servers because doing so increases the "ghost town" effect. The only time we want people to create public servers is when there are people who do not have a server close enough to them to jam on.

It's a bit like chat forums. The more forums you have, the less chat happens in them because the audience for each is lower.

In fact maybe this is the point we should be making on Running-a-Server.md: that you should only create a public server if you and your band mates can't find an existing one that's fast enough. Every time an empty server appears, the chances of anyone joining it goes down, and because nobody wants to jam on their own it's a vicious cycle. The more servers, the less people will play on them.

As an aside, I think I'm going to stop running my server (based in London) as there are already about 20 there.

[gene96817]

@gegeweb @gilgongo Seeing all the idle (empty) servers is frustrating (and sad). I am missing the JamKazam feature of posting (announcing) a planned jam session. This feature is wonderful for inviting friends and future-friends to make music together. I have met many musicians that way. It also notifies the community if you have a session that is open to visitors or if it is a closed rehearsal.

[gilgongo]

@gene96817 Yes, it's a complicated situation (and a bit hard to interpret so I may be wrong), but I think the more public servers are available, the less people will play on them, unfortunately :-(

BTW there have been calls to "expire" unused servers from the lists, but there are legitimate problems with that so we don't do it.

[gene96817]

@gilgongo Have you looked at the JamKazam's session listings? Take a look. Perhaps we should have a real-time discussion.

[gilgongo]

@gene96817 I think a similar system exists for Jamulus (so that you can declare you are looking for a jam and then other can join). This is very new though and I've lost the link to it...!

Also the issue of ping times complicates things. I'm afraid I don't know anything about JamKazam - what/where is their system for this?

[ann0see]

WorldJam has something like that, I think.

I'd suggest to discuss this either on the main Jamulus repo or on SourceForge so that this repo can focus on documentation

[gene96817]

@gilgongo You can get all the relevant information from the JamKazam UI. I suggest you install the client and look at the "Find Sessions" section. Just a few minutes of looking at that display should be enough for our discussion. I really like the ability to publish a jam many days in advance for others to join.

[gegeweb]

These things would (if I am correct) make the situation worse. We do not want to encourage people to set up even more public servers because doing so increases the "ghost town" effect. The only time we want people to create public servers is when there are people who do not have a server close enough to them to jam on.

That's wy I've bring up my own server. When I look for server with good latency and located in France I now see only my own (referenced on Rock Central Server), and none before. I'm now happy to see that a band (musicians located near Strasbourg) regulary use my server for their training sessions (one or two per weeks).

The ghost town effect should also appair if there is not enough server with good latency. As I can see, a lot of French people discover Jamulus and are looking for solution to playing online because our second lockdown. The ghost town effect could also appair if there is not enough server available with good latency. As I can see when i meet someone using my server (I help a lot of people! :D), a lot of French people discover Jamulus and are looking for solution to playing online because of our second lockdown in France.

Public server is useful when you can't or don't know how to open or redirect the UDP port.

That's why (off topic here) i suggest a page to reference (by the owner) "private" server that accept public connexion but aren't referenced on the puclic servers. (Not sure if i'm understendable because of my english).

If my server hadn't been public, these musicians might not have found a "home" to rehearse. (One of them uses a 4G connection, it seems to work!)

[gilgongo]

When I look for server with good latency and located in France I now see only my own (referenced on Rock Central Server), and none before.

Yes, this is a different issue, as I have said. If you do not have a server you can jam on that's fast enough for you and people near you, then it's worth setting up a server for that reason. Otherwise it's not. This is why I said in my previous comment "maybe this is the point we should be making on Running-a-Server.md: that you should only create a public server if you and your band mates can't find an existing one that's fast enough."

(I don't want to appear rude, but this discussion would be easier if you read what I was saying, then responded to those points. We are just going around in circles otherwise.)

Public server is useful when you can't or don't know how to open or redirect the UDP port.

While this is true to an extent, I think it's still subject to the "ghost town" point: don't set up a server just because you want to.

"private" server that accept public connexion but aren't referenced on the puclic servers.

Yes, this is off topic. But again, unless those private servers are there to help people who would otherwise not be able to connect to any (public or private) servers near them, then I think it makes things worse for Jamulus overall.

[gegeweb]

I don't want to appear rude, but this discussion would be easier if you read what I was saying, then responded to those points. We are just going around in circles otherwise.

In fact we agree. For the best way to formulate it in the documentation, I leave it up to you.

I was (again) doing an off-topic to explain why, after reading the documentation, I decided to set up a public server, even though it is not recommended. This is just what is missing (I think) in the documentation, and the purpose of this request for improvement. Push the reader to wonder if he really needs his own server, if so why, and therefore in which mode. I asked myself these questions... Also understanding the function of the central server can also help an organization (school) how it can use Jamulus to set up a distance learning infrastructure.

The currently undocumented (but I think it will be) feature that consists in :

1. launch the server in public mode (no port redirection to do)
2. wait until all the musicians have joined the server
3. switch to private mode

Should prevent unnecessary squatting of public central servers.

[gilgongo]

I see. And your general point is a good one too. I do think we could improve the server documentation, and your idea of re-writing it around use cases (particularly with the central server) is a nice one. I'll draft something and we can discuss it on a separate issue.

BTW the "public to private" technique is described in Tips & Tricks now.

[gegeweb]

What are we doing for the French translation in progress? Can I keep this introduction, or do I have to keep the French document in accordance with the current English version?

[trebmuh]

I thought we agreed on that already, a translation isn't a place to make documentation change. A translation is only and uniquely a place where we translate. Am I misunderstanding something here?

[gegeweb]

@trebmuh say,

I thought we agreed on that already, a translation isn't a place to make documentation change. A translation is only and uniquely a place where we translate. Am I misunderstanding something here?

Rest assured it would be difficult to be any clearer.

However, just because you think so, doesn't mean that everyone agrees. I am curious to know what other members of the community think.

Especially since we are in a phase of setting up a more structured procedure for documentation. On this subject, a point that is not yet very clear to me, what should be the reference for the version to be translated? The changes branch or the translation branch? If I understood correctly, we push in translation which will be merged into changes before being merged into main and pushed into production. If so, then I don't see any contraindication or blockage to a translation initiating an improvement.

I reformulate and re-explain the question:

When working on the translation of this page, as explained, it seemed to me that these precisions was missing in the introduction of the page. Now that the procedures are a bit clearer, I opened this ticket. If this proposal is accepted, then I can keep this paragraph in the French version before opening the MR and the English version will be updated (by a native English speaker if possible. I am never sure that my English reflects the meaning of what I express in French). There would only be a few minor corrections left to keep in sync both versions. Otherwise, I won't keep it.

So what do I do? (So we don't have to go back on it if it's approved.)

Below the french version of this introduction (not yet submited):

# Les types de serveur

Commencez d'abord par vous (re)poser la (les) question(s), **ai-je vraiment besoin de mon propre serveur, et si oui pourquoi faire ?**

Le serveur peut être configuré dans trois modes, que le serveur soit à domicile ou chez un fournisseur de service (« _cloud_ », serveur dédié…).  
Les réponses au « _pourquoi ?_ » ci-dessous vont vous aider à choisir :
1. Le concept de Jamulus est génial ! J'ai la bande passante ou déjà un serveur dans le « _cloud_ » ou un serveur dédié et je veux moi aussi contribuer et agrandir l'offre de serveurs publics disponibles avec une faible latence dans ma région.
2. Le concept de Jamulus est génial ! Mais… pour ma formation, c'est gênant de parfois être dérangé ou écouté par d'autres sur les serveurs publics.
3. Vous êtes une organisation (école, conservatoire… ) et voulez y référencer plusieurs serveurs par groupe, genre ou classe administrés par votre organisation, vos professeurs ou encore vos élèves.

[gegeweb]

There would only be a few minor corrections left to keep in sync both versions.

And if everyone agrees here on the content of the paragraph, the MR is then only a technical formality.

[ann0see]

No. The process is changes --> translation (only translate what's on this branch changes can move on until the next release) -> main (this will be then uploaded to the website)

[gegeweb]

No. The process is changes --> translation (only translate what's on this branch changes can move on until the next release) -> main (this will be then uploaded to the website)

OK, but I've noticed that some new or peviously undocumented features are documented on the changes branch wich aren't present in the actual translationbranch (created before these modifications). That's why I'm asking about the reference for the english version to be translated.

[gegeweb]

OK, but I've noticed that some new or peviously undocumented features are documented on the changes branch wich aren't present in the actual translationbranch (created before these modifications). That's why I'm asking about the reference for the english version to be translated.

Waiting the conclusion of this discussion, i'll submit the MR for this page with the improvement commented. So not ready for merging, as a draft, waiting the feedback.

[ignotus666]

Translations should not have content that isn't in the English version yet. The English version takes the lead in 'changes' - that's why there are new documented features that aren't in the 'translation' branch. We're going to wait until all translations are level with the English version in the 'translation' branch. Then, when the next release approaches, all new text and edits committed to 'changes' are merged into 'translation' in a single commit (via 'squash and merge') and translators update their languages in that branch.

In short:

• Translators should only make commits to 'translation' and their reference English version is the one in that branch. No new content can be added in this branch, in any language.

• Any modifications or additions to the documentation must first be made to the English version in the 'changes' branch. This branch is for changes to the English version only.

[gegeweb]

Waiting the conclusion of this discussion, i'll submit the MR for this page with the improvement commented. So not ready for merging, as a draft, waiting the feedback.

Now that it's much clearer. I will keep this version aside and remove the additions in the MR #75 . And I will post them here for discussion.

Is it possible to submit the french version here? I am sure of the initial meaning in French. I don't have a big problem with English -> French, but the reverse may not be what I meant.

[trebmuh]

However, just because you think so, doesn't mean that everyone agrees. I am curious to know what other members of the community think.

That's a bit unfair, @ignotus666 already agreed here a few days ago. Thanks @ignotus666 for having taking the time to write it again here.

[ignotus666]

@trebmuh to be fair, it's quite possible @gegeweb wasn't aware of that conversation, which is why I tried to lay it out clearly here again. We're having conversations all over the place and I find it difficult myself to keep track of what's going on... I expect things will be less chaotic when the translations are done and then it's just a matter of keeping them updated when the English version changes. BTW, does anyone know if someone's working on the IT and DE translations? I see they're only partially done.

[ann0see]

DE was updated by me and should be up to date with the english one. @SmuSmu is the official translator. Italian is still missing but I think it's in progress.

[ignotus666]

DE was updated by me and should be up to date with the english one

Are you sure? There are about 25 files in the wiki/en folder but I see only about half of them in wiki/de, fewer in wiki/it. I'm not being snotty BTW, I know you have a lot on your plate as it is, but maybe you hadn't realised. Or maybe I'm missing something (likely).

[ann0see]

Yes. DE is not complete. I initially only translated the most important pages since I was waiting for someone taking over which @SmuSmu did. At least at that time I thought- and still think now - that some pages might not need a translation since they're not often viewed.

I wanted - and still want - to focus on development and not really on translation.

[ignotus666]

No worries - I understand.

[gegeweb]

@ignotus666 say,

it's quite possible @gegeweb wasn't aware of that conversation, which is why I tried to lay it out clearly here again. We're having conversations all over the place and I find it difficult myself to keep track of what's going on...

You're right. On the other hand, there are sometimes opposing discourses.

Thanks a lot for clarify.

For « enfoncer le clou » as we say in French: The reference is the version in translation branch even if it is not in sync with the last modifications in changes branch, that for all translators. Right? I hope!

[ann0see]

The reference is the version in translation branch even if it is not in sync with the last modifications in changes branch

Yes. At least that's the current policy.

[SmuSmu]

Hi @all,

sorry had some trouble around here. Still willing to finish my translation job. So in which branch should I now put the translation? Or should I stop translationg because of a new system? Or just translation some sites? Sorry I did not read all stuff from the last weeks :-)

[ignotus666]

The current procedure is that all translations are done in the 'translation' branch against the English version in that same branch. You might have to check past translations in case there have been changes to the English version since they were done - specifically 'Installation for Linux', 'Compiling' and 'Software manual'.

Before each release of Jamulus, the 'changes' branch is merged into 'translation' and then the updates are applied to each language again.

[trebmuh]

@trebmuh to be fair, it's quite possible @gegeweb wasn't aware of that conversation [...]

It isn't my understanding since I've been telling him and pointing him out to that conversation a few times already.

Moreover @gegeweb : you keep doing it. See #80 . Why?

Once again, please stop adding stuff in the French translation when they are not in the original English version and open a PR against the English version first. Then, it'll be assessed and discussed by the documentation writers and accepted or not by @gilgongo .

Already said but I'm writing it here again:

1. if you make additions into the French translation which aren't in the English text, then slowly but surely, all the translations will diverge.
2. you're not sharing your additions with the whole community (ie: all the non-reading-French people)

Already said but saying it again here: note that I'm not against some of the additions you're proposing (I find some very relevant and would +1 those if you were to propose them on the English version).

That said, I'm pinging @ann0see too because I've asked you to do so maybe already 10 different times and it seems you're not listening to. It's starting to be painful. Can you please stop doing this? The insistence with which you continue to do it is making me wondering if you're doing that on purpose just to try to get me upset. I hope and believe that it isn't the case. Please confirm.

[gegeweb]

That said, I'm pinging @ann0see too because I've ask you to do so maybe already 10 different times and it seems you're not listening to. It's starting to be painful. Can you please stop doing this?

For Command-Line-Options, I'm sorry. I've reviewed all the pages that was already translated from the main branch and take care to keep these in sync with the EN version. But for this, it seems I've been to fast. I'm on it… please wait for the commit.

I've planned to open issues for improvement after this translation finish.

It is not intentional here !

[trebmuh]

Thanks for answering.

Note for the future reviews I'm doing: before starting, I'll check at which quality level is your PR. If the quality is good enough, then I'll do a "review" (in the github sense) asking for changes. If the quality is too low, I'll do another superseding PR. The reasoning for that is that doing a proper review (such the one I'm doing on your PR) is taking more time than making another PR. For "Command-Line-Options", it took me ~45 mins to make another PR, doing a proper review of it (explaining for each mistake the "why and how") would have roughly take around 2.5 or 3 hours.

[gegeweb]

Note for the future reviews I'm doing: before starting, I'll check at which quality level is your PR. If the quality is good enough, then I'll do a "review" (in the github sense) asking for changes. If the quality is too low, I'll do another superseding PR.

Agree with this way of work. My apologies again. I had really take care to be in sync with the En version in the translationbranch. I've not make a good job on this. :(

[gilgongo]

Fixed with https://github.com/jamulussoftware/jamuluswebsite/pull/527