refac

docs/alternatives/llama-cpp.mdx

@@ -36,7 +36,7 @@ import Head from '@docusaurus/Head';
 - **OpenAI-compatible API** via `llama-server` so any tool can connect to it
 - **Multi-model router mode** for serving multiple models from one endpoint
 - **One of the most actively developed projects in AI** with a pace of commits that's hard to match
-- **MIT licensed** and genuinely community-driven
+- **MIT licensed** and actively maintained
 
 ---
 

docs/faq.mdx

@@ -125,7 +125,7 @@ Everything you need to run Open WebUI, including your data, remains within your
 
 ### Q: Why does Open WebUI emphasize the use of Docker?
 
-**A:** The decision to use Docker stems from its ability to ensure consistency, isolate dependencies, and simplify deployment across different environments. Docker minimizes compatibility issues and streamlines the process of getting the WebUI up and running, regardless of the underlying system. It's a strategic choice by the project maintainers to harness these benefits, acknowledging that while Docker has a learning curve, the advantages for deployment and maintenance are significant. We understand Docker might not be everyone's preference; however, this approach is central to our project's design and operational efficiency. We view the project's commitment to Docker as a fundamental aspect and encourage those looking for different deployment methods to explore community-driven alternatives.
+**A:** The decision to use Docker stems from its ability to ensure consistency, isolate dependencies, and simplify deployment across different environments. Docker minimizes compatibility issues and streamlines the process of getting the WebUI up and running, regardless of the underlying system. It's a strategic choice by the project maintainers to harness these benefits, acknowledging that while Docker has a learning curve, the advantages for deployment and maintenance are significant. We understand Docker might not be everyone's preference; however, this approach is central to our project's design and operational efficiency. We view the project's commitment to Docker as a fundamental aspect and encourage those looking for different deployment methods to explore independently maintained alternatives.
 
 ### Q: Why doesn't Speech-to-Text (STT) and Text-to-Speech (TTS) work in my deployment?
 

docs/security/security-policy.mdx

@@ -52,7 +52,7 @@ If your report describes a real vulnerability under this policy, here is what yo
 - **Coordinated disclosure.** We will not publish out from under you while you are still working the issue with us. Status moves visibly on the advisory itself, including the CVE request, and GitHub notifies you of those updates, so you can follow it through to publication.
 - **A real fix, handled responsibly.** For findings with broad or severe real-world impact, we may hold publication for up to roughly two weeks after the patched release so administrators can update before details are public.
 
-We are a small volunteer team, so what we **cannot** offer is a bounty or a guaranteed turnaround. What you get is a serious fix, honest credit, and a process that treats your work as the contribution it is.
+Open WebUI is led by a small core team with clear ownership of the security process. Valid reports receive serious review, real fixes, appropriate credit, and coordinated handling through the GitHub advisory record.
 
 ## Alignment with the CVE Program
 
@@ -70,7 +70,7 @@ To ensure your findings truly help protect users and are addressed swiftly, plea
 
 **We accept vulnerability reports only through [GitHub Security Advisories](https://github.com/open-webui/open-webui/security/advisories/new).** Reports submitted through **any** other platform, including but not limited to third-party vulnerability reporting platforms, vulnerability brokers, social media, email, Discord, or Reddit, will not be processed.
 
-This is not a procedural preference. As a volunteer- and community-driven project, our security process is built around the same transparency and direct community interaction as the rest of our work, and GitHub Security Advisories is where that process lives. We do not and cannot monitor or engage with external reporting platforms, and reports arriving through them will be closed without review.
+This is not a procedural preference. As a project led by a small core team, Open WebUI uses a single, authoritative reporting channel for security work, and GitHub Security Advisories is where that process lives. We do not monitor or engage with external reporting platforms, and reports arriving through them will be closed without review.
 
 A report filed on another platform has **no standing** here: it confers no priority, establishes no filing date, and creates no obligation for us to triage, publish, or otherwise consider it. Only the GitHub Security Advisory record exists for the purposes of this policy, including determining who filed first.
 
@@ -127,11 +127,11 @@ Non-compliant submissions may be closed, and repeat or extreme violators may be
 
 ## Expected Timeframe
 
-We aim to triage new reports, ship fixes, and publish advisories promptly. However, due to the very high volume of incoming vulnerability reports, issues, discussions, pull requests, and general project maintenance, lately compounded by a high number of (AI-generated) reports (see [AI Report Transparency](#reporting-guidelines)), our capacity to respond is limited. Open WebUI is a community-driven project maintained by a small team, and security reports are handled alongside all other project responsibilities.
+We aim to triage new reports, ship fixes, and publish advisories promptly. Reports are prioritized by validity, severity, reproducibility, and user impact, alongside releases and core project maintenance. Open WebUI is led by a small core team, and security reports are handled through that core process.
 
-**Please expect several weeks** for your report to be triaged, investigated, fixed, and published. Periods of silence lasting weeks are normal and **do not mean your report has been ignored**, only that we have not yet had the capacity to address it. Feel free to post a follow-up comment on your advisory for visibility if you feel your report may have been lost; we will get to you as soon as our capacity allows.
+**Please expect several weeks** for your report to be triaged, investigated, fixed, and published. Status updates are posted on the advisory when there is a material update to share. A quiet advisory does not mean the report has been ignored; it remains in the security process.
 
-**We do not accept reporter-imposed publishing deadlines.** We coordinate disclosure on our own schedule, and we will triage, fix, and publish as fast as we reasonably can. Externally-imposed hard timelines do not speed this up. They do the opposite: they pull our limited time away from actually fixing issues and toward managing a clock, **at the expense of every other report (even ones that might be more serious)** in the queue and the project as a whole. A deadline attached to your report will not change when or how fast it is handled.
+**We do not accept reporter-imposed publishing deadlines.** We coordinate disclosure on our own schedule, and we will triage, fix, and publish as fast as we reasonably can. Externally imposed hard timelines do not change report priority, advisory timing, or release coordination. A deadline attached to your report will not change when or how fast it is handled.
 
 For findings we judge to have **broad or severe real-world impact**, regardless of CVSS score, we may hold off on publishing for a couple of days, up to roughly two weeks after the patched version is released, to give administrators time to update their instances.