1 files changed, 5 insertions, 5 deletions

diff --git a/docs/Checkpoint.md b/docs/Checkpoint.md
index b77384a..d76b9dc 100644
--- a/docs/Checkpoint.md
+++ b/docs/Checkpoint.md
@@ -54,19 +54,19 @@ these libraries with Rust, the bindings must gurentee that it encapsulates all C
 shenanigans such that any safe use of the rust bindings do not result in a panic/segfault/undefined
 behavior. Sadly, `raylib-rs` seemd to miss this when it comes to deallocating its structures. The
 `RenderTexture2D` (pretty much just a Frame Buffer Object or FBO), is created by using the raylib
-handle, but is not lifetime bound to it. Thus its possible for the raylib handle to be dropped first,
+handle, but is not lifetime bound to it. Thus it's possible for the raylib handle to be dropped first,
 and then the render texture next. The issue is the raylib handle will deallocate all of raylib when
 dropped, and thus cause a double free when the render texture is attempted to be dropped. The solution?
 Re-order the fields on the `Window` struct. Very cool.
 
 ### Windows HATES Default Features
-Well maybe not? To optimize a rust binary, its normal to go through default features and disable
+Well maybe not? To optimize a rust binary, it's normal to go through default features and disable
 what is not used. For `raylib-rs`, there are a ton of default features, as all raylib modules
 are enabled by default, along with support for all file formats. Most of this is not needed
 and therefore can be disabled. Turns out, at least on windows, when these features are disabled,
-the program fails to link with raylib on windows only. It attempts to link to symbols like
-`LoadModelFromMesh`, even though its never called. Why, who knows? The word around was to enable
-default features for raylib on windows builds.
+the program fails to link. It attempts to link to symbols such as `LoadModelFromMesh`, even though
+these were never called. Why, who knows? The work around was to enable default features for raylib
+on windows builds.
 
 ## Structure