docs: design: fix some fixes

docs/design/part-buffer.txt

@@ -12,7 +12,7 @@ Requirements
  - It must be fast
     * allocation, free, low fragmentation
  - Must be able to attach multiple memory blocks to the buffer
- - Must be able to attach artbitrary metadata to buffers
+ - Must be able to attach arbitrary metadata to buffers
  - efficient handling of subbuffer, copy, span, trim
 
 Lifecycle
@@ -125,7 +125,7 @@ Use cases
 Generating RTP packets from h264 video
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-We receive a GstBuffer as input with an encoded h264 image and we need to
+We receive as input a GstBuffer with an encoded h264 image and we need to
 create RTP packets containing this h264 data as the payload. We typically need
 to fragment the h264 data into multiple packets, each with their own RTP and
 payload specific header.

docs/design/part-caps.txt

@@ -29,8 +29,8 @@ For fixating caps only the first structure is kept as the order of
 structures is meant to express the preferences for the different
 structures. Afterwards, each unfixed field of this structure is set
 to the value that makes most sense for the media format by the element
-or pad implementation and then every remaining unfixed fields are set to
-an arbitrary value that is a subset of the unfixed field possible values.
+or pad implementation and then every remaining unfixed field is set to
+an arbitrary value that is a subset of the unfixed field's values.
 
 EMPTY caps are fixed caps and ANY caps are not. Caps with ANY caps features
 are not fixed.
@@ -123,7 +123,7 @@ for a specific structure, and only structures with the same name _and_
 equal caps features are considered compatible.
 Caps features can be used to require a specific memory representation
 or a specific meta to be set on buffers, for example a pad could require
-for a specific structure that includes EGLImage memory or buffers with
+for a specific structure that it is passed EGLImage memory or buffers with
 the video meta.
 If no caps features are provided for a structure, it is assumed that
 system memory is required unless later negotiation steps (e.g. the
@@ -142,7 +142,6 @@ not enough. Instead the fixed caps must be at least a subset of the
 pad's caps but pads can introduce additional constraints which would be
 checked in the ACCEPT_CAPS query handler.
 
-Data flow can only happen after pads have decided on a common and fixed
-set of caps. These caps are then distributed to both pads with the CAPS
-event.
+Data flow can only happen after pads have decided on common fixed caps.
+These caps are distributed to both pads with the CAPS event.
 

docs/design/part-context.txt

@@ -62,4 +62,4 @@ to the element (or to the complete pipeline).
 
 Whenever an element creates a context internally it will post a
 GST_MESSAGE_HAVE_CONTEXT message on the bus. Bins will cache these
-contexts and pass them to any future elements that requests them.
+contexts and pass them to any future element that requests them.

docs/design/part-messages.txt

@@ -18,9 +18,9 @@ Message types
 
 GST_MESSAGE_EOS:
 
-  Posted by sink elements. This message is posted when all the sinks in a
-  pipeline have posted an EOS message. When performing a flushing seek, the
-  EOS state of the pipeline (and hence, its sinks) is resetted.
+  Posted by sink elements. This message is posted to the application when all
+  the sinks in a pipeline have posted an EOS message. When performing a
+  flushing seek, the EOS state of the pipeline and sinks is reset.
 
 GST_MESSAGE_ERROR:
 
@@ -81,7 +81,7 @@ GST_MESSAGE_NEW_CLOCK:
 GST_MESSAGE_STRUCTURE_CHANGE:
 
   The pipeline changed its structure, This means elements were added or removed or
-  pads were linked or unlinked. This messages is not yet used.
+  pads were linked or unlinked. This message is not yet used.
 
 GST_MESSAGE_STREAM_STATUS: