Klemens Böswirth

> It has a separate structure defined in src/tools/website/resources/structure.json.in which could be totally different. I saw that. I just wasn't sure how flexible this is since it is something totally...

> I don't think that creating issues of missing docu by us leads anywhere. It would tell us about the current state of our docs. Right now I have no...

> We are actually in a quite good situation: not much is outdated. It's hard to say without reading and checking everything. For example, I'm not sure [this](https://github.com/ElektraInitiative/libelektra/blob/master/doc/dev/architecture.md#modules) is fully...

> There seems to be a misunderstanding: I asked "only" about removing docu that is now definitely incorrect because of changes in new-backend. No I got that, but if I...

> I would prefer more suggestions in PRs. My problem with that is that the first suggestion often needs a lot of work and those PRs and their discussions then...

> the first PR should only be a very high-level sketch Even this high-level sketch is not always something that can be agreed upon. Or it is so high-level that...

> Closing obviously not. But merging would. Merging is only an option if some consensus reached and the controversial parts are removed before the merge. Even then you loose the...

> Not in decisions, as all discarded ideas should still end up in "Considered Alternatives". Merging a decision with just "Considered Alternatives" and _without_ an actual decision also seems wrong....

How about `ksInsert` and `ksInsertAll`? I think the main issue is that "append" suggests adding to the end, which is not at all what happens.

In general, people should prefer different issues over these simple rename/API change issues, because the renaming/API changes can (hopefully) be done with the tool I'm developing for my thesis. If...