Merge branch 'master' into wip-v1.0

docs/docs/contributing/how_to/documentation/style_guide.mdx

@@ -79,7 +79,7 @@ Here are some high-level tips on writing a good how-to guide:
 
 ### Conceptual guide
 
-LangChain's conceptual guide falls under the **Explanation** quadrant of Diataxis. These guides should cover LangChain terms and concepts
+LangChain's conceptual guides fall under the **Explanation** quadrant of Diataxis. These guides should cover LangChain terms and concepts
 in a more abstract way than how-to guides or tutorials, targeting curious users interested in
 gaining a deeper understanding and insights of the framework. Try to avoid excessively large code examples as the primary goal is to
 provide perspective to the user rather than to finish a practical project. These guides should cover **why** things work the way they do.
@@ -105,7 +105,7 @@ Here are some high-level tips on writing a good conceptual guide:
 ### References
 
 References contain detailed, low-level information that describes exactly what functionality exists and how to use it.
-In LangChain, this is mainly our API reference pages, which are populated from docstrings within code.
+In LangChain, these are mainly our API reference pages, which are populated from docstrings within code.
 References pages are generally not read end-to-end, but are consulted as necessary when a user needs to know
 how to use something specific.
 
@@ -119,7 +119,7 @@ but here are some high-level tips on writing a good docstring:
 - Be concise
 - Discuss special cases and deviations from a user's expectations
 - Go into detail on required inputs and outputs
-- Light details on when one might use the feature are fine, but in-depth details belong in other sections.
+- Light details on when one might use the feature are fine, but in-depth details belong in other sections
 
 Each category serves a distinct purpose and requires a specific approach to writing and structuring the content.
 
@@ -127,17 +127,17 @@ Each category serves a distinct purpose and requires a specific approach to writ
 
 Here are some other guidelines you should think about when writing and organizing documentation.
 
-We generally do not merge new tutorials from outside contributors without an actue need.
+We generally do not merge new tutorials from outside contributors without an acute need.
 We welcome updates as well as new integration docs, how-tos, and references.
 
 ### Avoid duplication
 
 Multiple pages that cover the same material in depth are difficult to maintain and cause confusion. There should
-be only one (very rarely two), canonical pages for a given concept or feature. Instead, you should link to other guides.
+be only one (very rarely two) canonical pages for a given concept or feature. Instead, you should link to other guides.
 
 ### Link to other sections
 
-Because sections of the docs do not exist in a vacuum, it is important to link to other sections frequently,
+Because sections of the docs do not exist in a vacuum, it is important to link to other sections frequently
 to allow a developer to learn more about an unfamiliar topic within the flow of reading.
 
 This includes linking to the API references and conceptual sections!

docs/docs/contributing/tutorials/docs.mdx

@@ -33,7 +33,7 @@ Sometimes you want to make a small change, like fixing a typo, and the easiest w
    - Click the "Commit changes..." button at the top-right corner of the page.
    - Give your commit a title like "Fix typo in X section."
    - Optionally, write an extended commit description.
-   - Click "Propose changes"
+   - Click "Propose changes".
 
 5. **Submit a pull request (PR):**
    - GitHub will redirect you to a page where you can create a pull request.