diff --git a/collections/_article/rendering-priorities-july-2023.md b/collections/_article/rendering-priorities-july-2023.md
index 877404c268..3819c28b42 100644
--- a/collections/_article/rendering-priorities-july-2023.md
+++ b/collections/_article/rendering-priorities-july-2023.md
@@ -21,7 +21,9 @@ If you'd like to support the project financially and help us secure our future h
 
 I want to address what I consider to be a failure of communication in the last rendering priorities post. The previous post was not clear about whether it was a roadmap for 4.1, or if it was a list of things that were important to the rendering team. While the content of the post said not to expect everything to be done for 4.1, the title made it sound like everything on the list was planned to be finished for 4.1. My intention in writing the post was not to promise anything for 4.1, but rather to highlight things that the rendering team is currently working on (and it just so happened that 4.1 would be the next release). Going forward, I hope to be more clear that the list of priorities is not tied into any specific release.
 
-Below I list some of the top priorities identified by the [rendering team](https://godotengine.org/teams/#rendering) along with a brief description. These are presented in no particular order and are grouped based on whether they relate to performance improvements, stability, or usability. Many of these items are carried forward from the last post. We hope some of these will make it into 4.2, but we can't promise anything.
+Similarly, as a reminder that even when we have a feature ready or nearly ready before a release window, the feature still may be delayed to a subsequent release if more testing is needed, or if contributors identify issues with the feature before it is merged. That is to say, even if we say we will have a feature ready before a particular release, it only means that the Pull Request will be made before the release, we can't promise that any change will make it into the next release until that change is actually merged into the engine. 
+
+Below I list some of the top priorities identified by the [rendering team](https://godotengine.org/teams/#rendering) along with a brief description. These are presented in no particular order and are grouped based on whether they relate to performance improvements, stability, usability, or a new topic, customization. Many of these items are carried forward from the last post. We hope some of these will make it into 4.2, but we can't promise anything.
 
 #### Performance
 
@@ -45,7 +47,7 @@ Below I list some of the top priorities identified by the [rendering team](https
 
 #### Stability
 
-**1. Bugs**
+**1. Fixing Bugs**
 
     Please continue to help reduce the number of bugs in the engine by contributing bug fixes, and contributing issue reports with clear, reproducible test projects. We made huge strides on fixing bugs in 4.1 and we hope that following releases maintain the same increase in quality.
 
@@ -69,9 +71,9 @@ Below I list some of the top priorities identified by the [rendering team](https
 
 We also have plans to expose more RenderingDevice features to the scripting API. This is work that was originally planned for 4.0 that did not make the cut in time. Then we delayed it as we wanted the team to focus on bugs. Now we are finally taking the time to expose the things that need exposing so that advanced users can really take advantage of the customized rendering possibilities offered by the RenderingDevice.
 
-The first addition will be the TextureRD resource family, which will be versions of Textures that are formed from an internal RD resource. This will allow users to share custom RD-created textures with the main Godot rendering pipeline. In particular, users can implement custom rendering to a surface, then display that surface using a regular GDShader.
+The first addition is the TextureRD resource family, which are versions of Textures that are formed from an internal RD resource. This will allow users to share custom RD-created textures with the main Godot rendering pipeline. In particular, users can implement custom rendering to a surface, then display that surface using a regular GDShader.
 
-We are also investigating exposing mesh surface data in the same way, as well as providing access to internal buffers, like the MultMesh buffer, the skeleton buffer, etc.
+We are also investigating exposing mesh surface data in the same way, as well as providing access to internal buffers, like the MultiMesh buffer, the Skeleton buffer, etc.
 
 ## Conclusion