docs: Should Qdrant docs organize admin tools

[mjang]

Currently, Qdrant docs has a page for Administration tools. IMO, this is misleading, as Qdrant has several admin tools, currently documented in this and other sections.

I think the two tools in the current Administration page can be moved. Brainstorm idea:

• Move "locking" next to Authentication.
  • Even though "locking" is global, it's something that an admin would disable before others can create / add new data.
• Move "recovery mode" under Troubleshooting.
  • While the page title is "Solving common errors," the ToC entry is "Troubleshooting". I think the page title should also be updated.

Stretch goal: include a separate page, with at least links to and brief descriptions of all Qdrant admin tools.

[timvisee]

I agree that having an administration page with these two items may not be the best structure.

Move "locking" next to Authentication.

• Even though "locking" is global, it's something that an admin would disable before others can create / add new data.

This is a hard one. It only prevents accidental writes, because it blocks them if locking is enabled. But nothing prevents any user from disabling the lock again by accessing the locking API endpoint again. It is not like an ACL or similar. Because of it, I don't think we should categorize it in 'Security', as that might give users a false sense of security. It can be tackled by adding a warning box to it, but that may not be the best approach.

Move "recovery mode" under Troubleshooting.

• While the page title is "Solving common errors," the ToC entry is "Troubleshooting". I think the page title should also be updated.

The troubleshooting page is more for 'I have this problem, this is the answer'. While recovery mode doesn't fall in that category per se, I'd still be fine by putting it there.

I'm a bit on the fence about this one. It's hard to structure this in a nice way. Do you think there may be other things we can add to the administration page, to give that more volume instead?

[mjang]

Do you think there may be other things we can add to the administration page, to give that more volume instead?

Thanks @timvisee . I think you're right, we should set up an admin page (or a group of pages) with various Qdrant admin tools. I'm thinking it should include info from several Guides.

Maybe... Qdrant could rename Guides to Admin Guides which follow the Diataxis architecture -- and are actual tools used for administration. I think this would justify a page by page analysis of each guide, which should be a task for a dedicated Technical Writer, working with other full-time Qdrant employees.

[generall]

@mjang however you will move our doc sections, please make sure to include previous address as alias.
It is important so that the search engines like google really don't like suddenly dead links in the index.

[mjang]

I want to address some related issues first. Example: I'm going to recommend that we use absolute links (within pages) to minimize risks. I remember using Hugo aliases as well.

[timvisee]

I want to address some related issues first. Example: I'm going to recommend that we use absolute links (within pages) to minimize risks. I remember using Hugo aliases as well.

If talking about links within this Hugo site, don't absolute links create more trouble than they solve?

[mjang]

I want to address some related issues first. Example: I'm going to recommend that we use absolute links (within pages) to minimize risks. I remember using Hugo aliases as well.

If talking about links within this Hugo site, don't absolute links create more trouble than they solve?

I figure on pushing absolute links whenever I see a PR. Example in this screenshot:

@timvisee , if this is more trouble than it solves, tell me, and I'll stop. (There's plenty to do here!)

[timvisee]

@mjang Oh no, this is great actually! I thought you meant URLs including the host. Thank you for sharing an example.