As a minor note, I'd put this under the "Procedures" in the navigation instead of as its own category.

More substantially, when I saw "data", I assumed it would be a link to the results data, not the input. So we might want to make that clear (and add links to data for each year?)

I wonder if storing the LimeSurvey XML might be a better choice than a rendered AsciiDoc file that will have to be copy-pasted instead of importing and making small edits in the LimeSurvey UI. In either case, does this need to be in the rendered docs, or would checking a markdown file into a repo (that doesn't get published to docs) make more sense?

So there are 2 things here
1. Community members should be able to see existing questions (to request change/addition/deletion)
2. For limesurvey "wrangler" to upload those questions in the system

for 1, we definitely need a markdown/html/asciidoc - XML is not really easy to navigate
but we also don't want PRs to land just into readable formats! It will be very tedious to keep both of them sync if we are thinking of updating things at the end - we might miss some small change

I think having both is a better idea. When someone wants to propose a change or addition/removal, they can open a ticket, or post a discussion thread. Once agreed, we can open a PR with both markdown and LSS file change at the same time.

In either case, does this need to be in the rendered docs, or would checking a markdown file into a repo (that doesn't get published to docs) make more sense?

I am in favor of it NOT being in rendered doc (but a link in doc somewhere to the file)

for 1, we definitely need a markdown/html/asciidoc - XML is not really easy to navigate
but we also don't want PRs to land just into readable formats! It will be very tedious to keep both of them sync if we are thinking of updating things at the end - we might miss some small change

I think having both is a better idea. When someone wants to propose a change or addition/removal, they can open a ticket, or post a discussion thread. Once agreed, we can open a PR with both markdown and LSS file change at the same time.

That sounds unpleasant. It requires the person making the PR to make the same change twice, including in a system they may not have used (the LimeSurvey UI was not easy to navigate when I created the XML for you to use in the Retrospective).

If we're going to keep the questions in a repo, somewhere (which I think is a reasonable thing to do), let's just go with a markdown/whatever version and not also keep the XML. Or say "if you want to suggest an edit, use your own LimeSurvey account to generate an updated XML file".
The latter choice is user-hostile, but I leave it in for completeness.

That sounds unpleasant. It requires the person making the PR to make the same change twice, including in a system they may not have used (the LimeSurvey UI was not easy to navigate when I created the XML for you to use in the Retrospective).

I was thinking of someone who knows and already uses limesurvey to make the PR (like you and me) but I understand it's a task taking upon ourselves..
Maybe have a change note somewhere that can be followed?
My thought process is coming from "if I have to create a new survey for next year": how easy for me is to check the delta. If it's going through the whole of markdown and comparing the not just questions but options, it would be a little awkward (in limesurvey you can just copy the survey to create a new one).
but it also doesn't feel right to say "you should have a limesurvey account where you can import questions to see, and then make changes, export and open a PR" - of course review would also be similarly complex.

In favor of welcoming more suggestions, I think we should go with markdown if we don't want both

As we discusses with @riecatnor and @siddharthvipul1 the original sources of the LimeSurvey LSS are not suitable for direct editing.

Thus the optimal update process for Survey is:
* collect changes in the markdown file over a year
* before running teh survey upload the old version of the survey to LimeSurvey interface, update it according to the changes in the Markdown file, then save the updated file as a snapshot and keep for the next year.

Thus I updated the pull-request with markdown file which contains questiosn, and also added the content for two pages: overview and how-to with content added by @riecatnor

Those pages can be adjusted and polished further, but I'd rather merge the request now, and update it later, so that we have initial information in place.