Add llms.txt discovery indexes to docs.fedoraproject.org #64
Labels
No labels
Contributors' Guidance
Improve written Material
Contributors' Guidance
technical support measures
effort
high
effort
low
effort
medium
good first issue
help wanted
meeting topic
needs changes
needs reporter feedback
needs review
needs vote
priority
high
priority
low
priority
medium
priority
on hold
type/content
type/misc
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
docs/tickets#64
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Propose generating llms.txt (https://llmstxt.org/) discovery indexes for the English Fedora Docs site as part of the existing build.
This is a v1, index-only proposal: it publishes a curated, grouped map of the site that links to the existing HTML pages. It deliberately does not generate per-page Markdown, translations, or a merged corpus.
Example
I have a PoC --> cverna/docs-fp-o → llms-txt (https://forge.fedoraproject.org/cverna/docs-fp-o/src/branch/llms-txt).
Why should we do this?
It would be generated on every English build:
Assited-by: OpenCode
AIUI, this aims to help LLMs and AI agents spend less time crawling the Docs site. I’m not sure if it will work, though, since the site is protected against data scraping by Anubis. @kevin is probably more familiar with the subject.
@hricky wrote in #64 (comment):
Not it is mostly to save tokens when working with AI agents and the Fedora docs. Instead of having to get the full HTML page, convert it to markdown and then find the links, an agent can directly get that information from the llms.txt.
It is not a huge optimization but it is also a small cost to implement.
It is not that difficult for Agents or tools to by-pass Anubis, which is good. Here the use case is a legitimate Agent or Contributor using a coding Agent for accessing Fedora Docs.
AFAICS this proposal modifies the Containerfile by adding an additional 700-line Python script (likely LLM generated), the
python3-beautifulsoup4module and some config. It also modifiesbuild-scripts/rebuild-site.pyto execute thebuild-scripts/gen_llms.pyscript.I don't know if it is not a huge optimization, but it's also a small cost to implement, and I'm not against it. I do wonder, however, if it's reasonable to run it every single hour just to save tokens for a hypothetical legitimate Agent or Contributor using a coding Agent for accessing Fedora Docs.
@hricky wrote in #64 (comment):
How often do we rebuild and publish the docs? Running the new script really doesn't take much time compared to the already quite long process of pulling all the docs git repos.
@cverna wrote in #64 (comment):
The English versions of the Fedora Docs sites are rebuilt hourly for both the
prodandstgbranches.I have researched the topic and have some questions and thoughts. Has anyone actually requested
llms.txtsupport? The indexing would only help with discovery. Agents would still need to fetch and parse full HTML pages. We're adding a 700+ line script, a new dependency, and ongoing maintenance for an unproven standard with no evidence of adoption. "Small cost" additions accumulate over time. We protect the docs from scraping for good reasons. Publishing a machine-readable index may make it easier to circumvent those protections, even if that's not the immediate intent.The real question is: what problem are we actually solving here? If contributors are struggling to use Fedora Docs with AI tools, that's worth discussing. But absent that feedback, this feels premature.
@hricky wrote in #64 (comment):
👍
Well I requested support in this ticket 😄, if we decide to go this way I have plans to make a skill (https://forge.fedoraproject.org/ai-ml/skills-library) to instruct agents to use these indexes.
Yes, this is for me the middle ground. We make it easy and cheap for Agents to find which page to actually fetch. As a first step I don't think it is useful to convert and serve all the docs pages as markdown files.
Well, it is not (yet) widely adopted but there is evidence of adoption https://llmstxt.site/
I don't think this has any impact or relation with scraping. These could/would still be protected by Anubis.
Well the current way to work with Fedora's Docs and AI is not ideal. What I am seeing the most is folks cloning the git repos (see example bellow). I agree that having llms.txt file will not radically improve things, but it's a small steps towards making it easier for Agents to do work in Fedora.
REPO_URL="https://forge.fedoraproject.org/packaging/guidelines.git"I think we'll need to do something like this eventually, so why not now.
Question, though - is there a way to validate the output? How do we tell whether the generated llms.txt makes sense? I'm concerned about possible future changes - this seems like something that would sit in our build pipeline with no way for us to tell if it still works or not.
@cverna wrote in #64 (comment):
In my experience, cloning Git repos is the way to work with Agents in the Fedora Project as a whole, not only with the docs. Let's try to add
llms.txtto the Docs site and see if it improves things at least a bit.@pbokoc wrote in #64 (comment):
I would suggest first adding a single
llms.txtfile, and then implementing the skill @cverna mentioned, to confirm that everything works as expected. To test this, I can migrate the Fedora Docs Build Repository to the Documentation Team Staging org. Then I can try to set up a CI/pipeline that generates the Docs site and a preview with thellms.txtfile included. For this, we can try to use ourrunnerhostmachine that is already set up and running.Oh hey, FYI
https://antora.zulipchat.com/#narrow/channel/282400-users/topic/Generation.20of.20an.20llms.2Etxt.20file.20at.20root/near/524780912
Interesting, I didn't think about checking existing Antora plugins. Might be interesting to try https://github.com/cerbos/antora-llm-generator