how to review wiki-changes before piping them to file exports?

[meus-rls]

hi, my goal is setting up a collaboration environment for a digital edition of the HKWM. i deal with a classical community of technically unsophisticated but content-motivated intellectuals from social sciences, philosophy, aso. as a first step, i want to inspire as many of you as possible to improve spelling mistakes and formatting inconsistencies via an online system. for the time being, i want to prevent content changes or additions from taking place, since the dictionary articles are named author texts. so thumbs up @xldrkp for your "flattened learning curve" approach pointed out in #32 .
my first step will be an experimental setup on gitlab.com along the tutorial "Kollaborativ Bücher schreiben mit dem GitLab-Wiki" with the text corpus of hkwm vol. 1, sec. corrected edition (from 1996).

my question is, seen from the tutorial linked above:
if content changes flow automatically via the wiki into the pipe and into the final product, how can an editorial check of individual wiki commits be realised and guaranteed? this would be the condition for inviting a wider interested and professional public to participate.

discussion of answer paths as i see them:
a) defining user rights in combination with personal trust: particularly the latter doesn't scale.

b) there is an open relevant gitlab-issue. based on that stackoverflow discusses a workaround.
this workaround, in my opinion, is ruled out because it requires cloning the repo of the wiki and thus significantly increases the technical hurdle for technically unsophisticated but content-motivated proofreaders, which is this approach goes through the wiki in the first place, if i understand it right.

so, practically, i guess i have to think about the question: how do i rebuild the pipe (proposed by that tutorial) between wiki and product respectively reconfigure the webhook in a way that it delays the trigger until something like a merge request is answered positively. right?
my git-experience is limited, so i would be very happy about anything that points me towards a workaround that doesn't annoy or overwhelm "unsophisticated but content-motivated" contributers - except of course for the unavoidable delay of the publication of their modifications.

or do i have to completely leave the framework of the tutorials approach?

[xldrkp]

Hi @meus-rls, thanks for checking in here and the detailed description of your approach. I would say that we should discuss your questions in the next meeting on March 2nd as they bring up lots of interesting topics around group authorship from an ethical and technical perspective. Before hacking the GitLab/wiki approach I'd like to know more about the authors' requirements and then see how they can best be implemented in a CMS-like authoring system.

[meus-rls]

thanks @xldrkp for your quick reply. i am looking forward to the session on march 2nd.

a few remarks about the authors i have in mind and their requirements:
almost all authors and editors and the very few female authors of the hkwm write in ms word and have probably heard of at least one wiki: wikipedia. very few have already edited there. against this background, i found the tutorial's approach great.
the logic and relevance of markdown as minimum knowledge for an online text "supply chain" should though be immediately obvious to most of them - and therefore apparently justifiable. besides: for a simple typo, you don't even need to know any markdown. you just need the faith to open the edit window, edit, save, and close. i hope a relevant part of them will find the energy to leave their familiar wysiwyg-editor environment and enter changes in a wiki. it helps that "wiki" is not perceived as new territory. into a "git" less than a hand full would surely follow me...
beyond that the whole project would open towards the crowd of theory interested that are already familiar with wiki/markdown online text editing. the latter should therefore be the common ground to start from.