[DOC] fixing some typos

Author: didier-durand

README.md

@@ -21,7 +21,7 @@ An e2e framework for creating, deploying and using isolated execution environmen
 
 OpenEnv provides a standard for interacting with agentic execution environments via simple Gymnasium style APIs - step(), reset(), state(). Users of agentic execution environments can interact with the environment during RL training loops using these simple APIs.
 
-In addition to making it easier for researchers and RL framework writers, we also provide tools for environment creators making it easier for them to create richer environments and make them available over familar protocols like HTTP and packaged using canonical technologies like docker. Environment creators can use the OpenEnv framework to create environments that are isolated, secure, and easy to deploy and use.
+In addition to making it easier for researchers and RL framework writers, we also provide tools for environment creators making it easier for them to create richer environments and make them available over familiar protocols like HTTP and packaged using canonical technologies like docker. Environment creators can use the OpenEnv framework to create environments that are isolated, secure, and easy to deploy and use.
 
 The OpenEnv CLI (`openenv`) provides commands to initialize new environments and deploy them to Hugging Face Spaces.
 

rfcs/000-project-phases.md

@@ -14,7 +14,7 @@ We recommend starting here to get a mental model of what's in here already, what
 This project aims at standardizing environments for both training and evaluation. In the training space, this means also standardizing reward pipelines, while in the eval space this means helping with reproducibility where a model can be shipped with a complete set of agentic evals that can be easily run by others.
 
 ### The problem with abstraction boundaries
-Ideally, we would draw a boundary between environments and everything else (orchestration, resource allocation, RPCs, etc). We will try to do this as much as possible, but we will have to create additional interfaces so that if folks want to cross this boundary, they can. This will likely be necessary for things like:
+Ideally, we would draw a boundary between environments and everything else (orchestration, resource allocation, RPCs, etc.). We will try to do this as much as possible, but we will have to create additional interfaces so that if folks want to cross this boundary, they can. This will likely be necessary for things like:
 - Reward pipelines that call reward models (which will very likely need to RPC to GPU machines)
 - Agentic evals like Tau where the eval itself involves two agents interacting with one another (and sending many RPCs)
 - Container provider interfaces to support different deployment targets (Docker, Kubernetes, cloud providers, etc.)

rfcs/001-abstractions.md

@@ -62,7 +62,7 @@ Our proposal takes elements from both and can easily convert into either.
 #### Proposed Abstractions
 This is the contract that we are proposing. We feel it strikes a good balance between supporting single-turn environments for LLM post-training (such as the GSM8K) while also extending to the more complex agentic tasks, such as [Tau-Bench](https://arxiv.org/abs/2406.12045). We are aiming for flexibility, so we know we may not get this right the first time. We encourage strong feedback to this RFC so that we can improve on it!
 
-These are the key abstractions that we expect. Note that in this project we only implement the "Environment" abstraction under the our meaning. You can map to other "agents" or "environment" abstractions by writing adapters to and from OpenEnvs.
+These are the key abstractions that we expect. Note that in this project we only implement the "Environment" abstraction under our meaning. You can map to other "agents" or "environment" abstractions by writing adapters to and from OpenEnvs.
 
 Key assumptions:
 1. We separate tasks from environments. While it is a good idea to package up a dataset with an environment and evals, we expect this wrapping to be done *outside* the env box. This allows for the reuse of environments across tasks.
@@ -442,7 +442,7 @@ for batch_of_tasks in dataloader:
 
 2. **Reward vs Eval**: Rewards are computed per-step by the environment (data-independent). Evals are computed per-episode by evaluation logic that has access to the dataset (data-dependent, aggregated). The specific abstractions for rewards and evals will be defined in separate RFCs.
 
-3. **PyTorch DataLoader compatibility**: `TaskDataset` follows the PyTorch `IterableDataset` interface (implements `__iter__`), making it seamlessly compatible with PyTorch's `DataLoader` for streaming data, multi-process loading, etc. This is ideal for sequential data access and large datasets.
+3. **PyTorch DataLoader compatibility**: `TaskDataset` follows the PyTorch `IterableDataset` interface (implements `__iter__`), making it seamlessly compatible with PyTorch's `DataLoader` for streaming data, multiprocess loading, etc. This is ideal for sequential data access and large datasets.
 
 4. **Flexibility**: Environments can support both traditional tool calling (where each tool call is a separate action) and CodeAct (where an action contains code that may call multiple tools). See RFC 004 for details on unified action interface and RFC 003 for MCP integration.
 

src/core/README.md

@@ -2,7 +2,7 @@
 
 An e2e framework for creating, deploying and using isolated execution environments for agentic RL training, built using Gymnasium style simple APIs. OpenEnv provides a standard for interacting with agentic execution environments via simple Gymnasium style APIs - step(), reset(), state(). Users of agentic execution environments can interact with the environment during RL training loops using these simple APIs.
 
-In addition to making it easier for researchers and RL framework writers, we also provide tools for environment creators making it easier for them to create richer environments and make them available over familar protocols like HTTP and packaged using canonical technologies like docker. Environment creators can use the OpenEnv framework to create environments that are isolated, secure, and easy to deploy and use.
+In addition to making it easier for researchers and RL framework writers, we also provide tools for environment creators making it easier for them to create richer environments and make them available over familiar protocols like HTTP and packaged using canonical technologies like docker. Environment creators can use the OpenEnv framework to create environments that are isolated, secure, and easy to deploy and use.
 
 
 ## Overview

src/core/tools/git_server_client.py

@@ -185,7 +185,7 @@ def clone_to_workspace(
         Args:
             repo_name: Name of repository to clone
             target_dir: Target directory name (defaults to repo_name)
-            commit: Commit hash or branch to checkout
+            commit: Commit hash or branch to check out
 
         Returns:
             Path to cloned repository

src/envs/browsergym_env/README.md

@@ -11,7 +11,7 @@ BrowserGym provides a complete pipeline for developing web agents: train on simp
 
 - **MiniWoB++ (Training)**: 100+ synthetic web tasks like "click this button", "fill out this form", "select from dropdown". Each task is a simple webpage with a clear objective. Fast resets, randomized variations, dense rewards. Perfect for learning basic web navigation skills. **No external setup needed** - tasks run in isolated browser sessions.
 
-- **WebArena (Evaluation)**: 812 tasks on real websites (e-commerce, forums, GitLab, Wikipedia). Tasks like "find the cheapest laptop and add to cart" or "create a merge request for bug #123". Multi-step, requires reasoning, sparse rewards. Tests if your agent can handle actual websites. **Requires running 7 backend services** (shopping site, GitLab instance, etc).
+- **WebArena (Evaluation)**: 812 tasks on real websites (e-commerce, forums, GitLab, Wikipedia). Tasks like "find the cheapest laptop and add to cart" or "create a merge request for bug #123". Multistep, requires reasoning, sparse rewards. Tests if your agent can handle actual websites. **Requires running 7 backend services** (shopping site, GitLab instance, etc.).
 
 - **VisualWebArena**: Similar to WebArena but requires visual understanding - agents need to interpret images, identify UI elements visually, handle multimodal content.
 

src/envs/openspiel_env/server/openspiel_environment.py

@@ -111,7 +111,7 @@ def reset(self) -> Observation:
         """
         Reset the environment and return initial observation.
 
-        For multi-player games, this will auto-play opponent turns until
+        For multi-player games, this will autoplay opponent turns until
         it's the agent's turn (or terminal state).
 
         Returns:
@@ -125,7 +125,7 @@ def reset(self) -> Observation:
         self._state.step_count = 0
         self._last_opponent_action = None
 
-        # Auto-play opponent turns until agent's turn
+        # Autoplay opponent turns until agent's turn
         time_step = self._auto_play_opponents(time_step)
 
         # Convert to OpenEnv observation
@@ -137,7 +137,7 @@ def step(self, action: Action) -> Observation:
 
         For multi-player games, this will:
         1. Apply the agent's action
-        2. Auto-play opponent turns until it's the agent's turn again
+        2. Autoplay opponent turns until it's the agent's turn again
         3. Return the observation from the agent's perspective
 
         Args:
@@ -178,7 +178,7 @@ def step(self, action: Action) -> Observation:
 
         self._state.step_count += 1
 
-        # Auto-play opponent turns (for turn-based games)
+        # Autoplay opponent turns (for turn-based games)
         if self.is_turn_based:
             time_step = self._auto_play_opponents(time_step)
 
@@ -192,7 +192,7 @@ def state(self) -> OpenSpielState:
 
     def _auto_play_opponents(self, time_step) -> Any:
         """
-        Auto-play opponent turns until it's the agent's turn or game is terminal.
+        Autoplay opponent turns until it's the agent's turn or game is terminal.
 
         Args:
             time_step: Current TimeStep from OpenSpiel environment.