bazel-contrib · bazel-docs-pull-requestor · Jul 10, 2026
diff --git a/contribute/codebase.mdx b/contribute/codebase.mdx
@@ -1377,7 +1377,7 @@ are provided:
 *   `bazel aquery` is used to investigate the action graph
 
 Each of these is implemented by subclassing `AbstractBlazeQueryEnvironment`.
-Additional query functions can be done by subclassing `QueryFunction`
+Additional additional query functions can be done by subclassing `QueryFunction`
 . In order to allow streaming query results, instead of collecting them to some
 data structure, a `query2.engine.Callback` is passed to `QueryFunction`, which
 calls it for results it wants to return.

diff --git a/contribute/docs.mdx b/contribute/docs.mdx
@@ -2,19 +2,42 @@
 title: 'Contribute to Bazel documentation'
 ---
 
-Thank you for contributing to Bazel's documentation!
 
-## How docs work
 
-Bazel documentation lives in two repositories:
+Thank you for contributing to Bazel's documentation! There are a few ways to
+help create better docs for our community.
 
-- [`bazelbuild/bazel`](https://github.com/bazelbuild/bazel) — all doc content in the `docs/` folder. This is where you make changes.
-- [`bazel-contrib/bazel-docs`](https://github.com/bazel-contrib/bazel-docs) — the hosting and navigation layer (Mintlify config, sidebar, PR previews).
+## Documentation types
 
-Content changes always go to `bazelbuild/bazel`. Navigation changes go to `bazel-contrib/bazel-docs`.
+This site includes a few types of content.
 
-## Contributing
+ - *Narrative documentation*, which is written by technical writers and
+   engineers. Most of this site is narrative documentation that covers
+   conceptual and task-based guides.
+ - *Reference documentation*, which is generated documentation from code comments.
+   You can't make changes to the reference doc pages directly, but instead need
+   to change their source.
 
-- **Make a change or add a page** — see [Docs contribution workflow](/contribute/docs-contribution-workflow) for step-by-step instructions, from a quick typo fix to adding a new page.
-- **Update the sidebar navigation** — see [Update the docs navigation](/contribute/docs-navigation) for instructions on adding your new page to the left-hand nav in `bazel-contrib/bazel-docs`.
+## Documentation infrastructure
 
+Bazel documentation is served from Google and the source files are mirrored in
+Bazel's GitHub repository. You can make changes to the source files in GitHub.
+If approved, you can merge the changes and a Bazel maintainer will update the
+website source to publish your updates.
+
+
+## Small changes
+
+You can approach small changes, such as fixing errors or typos, in a couple of
+ways.
+
+ - **Pull request**. You can create a pull request in GitHub with the
+   [web-based editor](https://docs.github.com/repositories/working-with-files/managing-files/editing-files) or on a branch.
+ - **Bug**. You can file a bug with details and suggested changes and the Bazel
+   documentation owners will make the update.
+
+## Large changes
+
+If you want to make substantial changes to existing documentation or propose
+new documentation, you can either create a pull request or start with a Google
+doc and contact the Bazel Owners to collaborate.
diff --git a/contribute/statemachine-guide.mdx b/contribute/statemachine-guide.mdx
@@ -781,7 +781,7 @@ There's a couple of examples of error handling already in [`Tasks.lookUp` callba
 callbacks as values. Such callbacks often have exclusive-or semantics, with
 exactly one of a value or error being passed.
 
-The next section describes a subtle, but important interaction with Skyframe
+The next section describes a a subtle, but important interaction with Skyframe
 error handling.
 
 #### Error bubbling (--nokeep\_going) {#error-bubbling}

diff --git a/docs/sandboxing.mdx b/docs/sandboxing.mdx
@@ -54,12 +54,7 @@ You can choose which kind of sandboxing to use, if any, with the
 strategy makes Bazel pick one of the sandbox implementations listed below,
 preferring an OS-specific sandbox to the less hermetic generic one.
 [Persistent workers](/remote/persistent) run in a generic sandbox if you pass
-the `--worker_sandboxing` flag. In addition to the plain boolean form, the flag
-can be scoped to a specific worker-key mnemonic with
-`--worker_sandboxing=<mnemonic>=<boolean>` (for example
-`--worker_sandboxing --worker_sandboxing=Javac=no` to sandbox all singleplex
-workers except `Javac`; a later plain boolean value applies to all mnemonics
-again).
+the `--worker_sandboxing` flag.
 
 The `local` (a.k.a. `standalone`) strategy does not do any kind of sandboxing.
 It simply executes the action's command line with the working directory set to

diff --git a/docs/user-manual.mdx b/docs/user-manual.mdx
@@ -1603,10 +1603,10 @@ be formatted to stay within 80 characters when possible.
 
 #### `--test_tmpdir=<var>path</var>` {#test-tmpdir}
 
-Specifies temporary directory for tests. Each test will be executed in a
-separate subdirectory inside this directory. The directory will be cleaned at
-the beginning of each `bazel test` command.
-By default, Bazel will place this directory under the Bazel output base directory.
+Specifies temporary directory for tests executed locally. Each test will be
+executed in a separate subdirectory inside this directory. The directory will
+be cleaned at the beginning of the each `bazel test` command.
+By default, bazel will place this directory under Bazel output base directory.
 
 Note: This is a directory for running tests, not storing test results
 (those are always stored under the `bazel-out` directory).

diff --git a/extending/rules.mdx b/extending/rules.mdx
@@ -820,7 +820,7 @@ Tools that are executed as part of the build (such as compilers or code generato
 should be built for an exec configuration. In this case, specify `cfg = "exec"` in
 the attribute.
 
-Otherwise, executables that are used at runtime (e.g. as part of a test) should
+Otherwise, executables that are used at runtime (such as as part of a test) should
 be built for the target configuration. In this case, specify `cfg = "target"` in
 the attribute.
 

diff --git a/migrate/xcode.mdx b/migrate/xcode.mdx
@@ -115,7 +115,7 @@ In the target, specify the following at the minimum:
     binary.
 
 *   `provisioning_profile` - provisioning profile from your Apple Developer
-    account (if building for an iOS device).
+    account (if building for an iOS device device).
 
 *   `families` (iOS only) - whether to build the application for iPhone, iPad,
     or both.

diff --git a/reference/be/protocol-buffer.mdx b/reference/be/protocol-buffer.mdx
@@ -14,7 +14,7 @@ title: 'Protocol Buffer Rules'
 
 ## cc_proto_library
 
-[View rule sourceopen_in_new](https://github.com/protocolbuffers/protobuf/tree/v29.0-rc2/bazel/private/bazel_cc_proto_library.bzl)
+[View rule sourceopen_in_new](https://github.com/protocolbuffers/protobuf/tree/v29.0-rc2/bazel/private/oss/cc_proto_library.bzl)
 
 ```
 cc_proto_library(name, deps, aspect_hints, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -88,7 +88,7 @@ proto_library(
 
 ## java_proto_library
 
-[View rule sourceopen_in_new](https://github.com/protocolbuffers/protobuf/tree/v29.0-rc2/bazel/private/bazel_java_proto_library_rule.bzl)
+[View rule sourceopen_in_new](https://github.com/protocolbuffers/protobuf/tree/v29.0-rc2/bazel/private/java_proto_library.bzl)
 
 ```
 java_proto_library(name, deps, aspect_hints, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, licenses, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -171,7 +171,7 @@ Recommended code organization:
 
 ## py_proto_library
 
-[View rule sourceopen_in_new](https://github.com/protocolbuffers/protobuf/tree/v29.0-rc2/bazel/py_proto_library.bzl)
+[View rule sourceopen_in_new](https://github.com/protocolbuffers/protobuf/tree/v29.0-rc2/bazel/private/oss/py_proto_library.bzl)
 
 ```
 py_proto_library(name, deps, aspect_hints, compatible_with, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, package_metadata, restricted_to, tags, target_compatible_with, testonly, toolchains, visibility)
@@ -212,8 +212,6 @@ srcs = ["foo.proto"],
 proto_lang_toolchain(name, allowlist_different_package, aspect_hints, blacklisted_protos, command_line, compatible_with, denylisted_protos, deprecation, exec_compatible_with, exec_group_compatible_with, exec_properties, features, mnemonic, output_files, package_metadata, plugin, plugin_format_flag, progress_message, protoc_minimal_do_not_use, restricted_to, runtime, tags, target_compatible_with, testonly, toolchain_type, toolchains, visibility)
 ```
 
-If using Bazel, please load the rule from https://github.com/bazelbuild/rules_proto.
-
 Specifies how a LANG_proto_library rule (e.g., `java_proto_library`) should invoke the
 proto-compiler.
 Some LANG_proto_library rules allow specifying which toolchain to use using command-line flags;