Wiki Contribution - Editing versus Pull request to update Documentation

[niebert]

Previously users can contribute to the project by editing the Wiki. Now the comments in the Wiki moved to underlying web server. Easy typo fixing in the documentation needs now a pull request. It increases the barrier for simple contributions. Positive is a better structure for the navigation in the documentation.

Might it be possible to create a pandoc workflow from Wiki to corresponding web site in jamulus web content?

convert WikiPage1.md source with pandoc to WikiPage1.html with CSS and HTML headers for the web site. A new release for Website parses the Wiki sources runs a pandoc for each page and stores the page in the io web branch.
Best regards,
Bert

[corrados]

@gilgongo and @ann0see, you should comment on that.

[ann0see]

I think the pull request workflow was wanted from @gilgongo and @ignotus666 to have better control over the wiki content.

[gilgongo]

Hi @niebert Along with the move to jamulus.io, we hope to introduce proper language translation as part of our secret plan to take over the world. This means we have to be mindful of how changes are being done so as not to put undue pressure on the volunteers for that. We've put a freeze on the English for 30 days to allow translators to catch up, and to come up with a change control process after that.

There is also the wider issue of the management of the docs over time. My own view is that we should be careful not to portray Jamulus as being potentially too complicated for non-technical users and should try to structure things accordingly. As we accumulate more content, we therefore need to review additions and subtractions quite carefully,

(I'm not qualified to comment on your proposed workflow I'm afraid)

[ignotus666]

Open access enabled people to easily make corrections, yes - but also to make incoherent and sometimes unreadable contributions. The PR "barrier" doesn't stop anyone from making contributions but given the current size of the wiki some of us reckoned that there needed to be some kind of filter, not only to help translations keep up to date without going crazy chasing random edits, but also to maintain the coherence of the "master" English version. Furthermore, it left the door wide open for a joker to do mischief - it hasn't happened but it was a real possibility.
Seeing how things are going with the pandemic and with winter approaching, I think it can be safely predicted that there'll be another surge in the use of Jamulus. This makes it more important to have quality documentation which could otherwise be easily undermined by random edits made by what will probably be a significantly expanded userbase.

[ann0see]

I think we should migrate this to the repo of the website and close this. Feel free to comment in jamulussoftware/jamuluswebsite#31

[niebert]

No worries, please keep jamulus.io that was not my intension to revert to a Wiki driven documentation. A pandoc workflow in the release management, allows contributions in the Wiki and if they pass your quality assurance, they are updated in the jamulus.io with the language specific documentations in sync. see https://pandoc.org/try and you will notice how an easy update of the website could be performed owners. So my recommendation would be:

• migrate the Wiki comments to jamulus.io if they meet your quality standards and translate them,
• otherwise delete those comments in Wiki
  Having Jamulus as OpenSource software available is a very valuable conrtibution to keep music culture possible for musician in the pandemic.

Furthermore I want to ask you to remove the annotation "sonic emperor" from my name on the Web Site https://github.com/jamulussoftware/jamulussoftware.github.io/blob/main/wiki/en/en-Tips-Tricks-More.md - you can remove or improve my edits or use them or build on them if you think there are useful according to you quality assurance quidlines. My comments were good faith edits.

If it is Ok for you, I would use the Wiki for contributions and you decide if the quality of my comment meet your standards.

Just to clarify why I added the workflow of https://github.com/jamulussoftware/jamulussoftware.github.io/blob/main/wiki/en/en-Software-Synth.md to the Jamulus repo. It shows how to exchange a MIDI signal from the instrument "keyboard" "digital wind instrument" "digital drum klit" to a software synth that generates to audio. A MIDI communication layer in Jamulus that transmits the Midi-Signal reduces the traffic tremendously. The concept is MIDI exchange Layer similar to audio signal exchange between the musicians. This allows even to choose the keyboard sound on the client side or replace the trumpet sound by a flute sound (Using open Sound Fonts makes that possible. within Jamulus if you like that idea)

Thank you all for contributing to this amazing OpenSource project.

[corrados]

I think a better place for this discussion would be here: https://github.com/jamulussoftware/jamulussoftware.github.io/issues

So I'll close this Issue now.

[ann0see]

remove sonic emperor

Please open a PR on the repo since it will have to be removed in multiple languages (after the freeze is over).

[gilgongo]

@niebert We have been reviewing the content on the wiki from the point of view of maintaining and translating it, and have taken the decision not to host content that isn't directly about the use of Jamulus or that we cannot reliably maintain over time. For this reason we have removed the link the Software Synth (and other) pages for now. However, we are happy to link to content that is maintained externally.

[ann0see]

There is a discussion about reimplementing an open part of the homepage (maybe with another software). See this: jamulussoftware/jamuluswebsite#56 (comment)

[ann0see]

@niebert coming back to the pandock idea: we are currently using Jekyll, polyglot and multiple branches which does add complexity. How would a pandock workflow look like? Isn’t it almost the same? As far as I understand it, it can convert files from one format to another (md to html,...).

Actually this could also be something we could consider for the new open knowledge base. To allow non markdown files to be uploaded.

The new process will be a bit more difficult (if we use all the stuff with PRs, etc.) unfortunately. If pandock helps this would be great. Unfortunately I don’t really understand it yet.