Fix typos and apply suggestions

Author: AlexeySachkov

sycl/ReleaseNotes.md

@@ -2,7 +2,7 @@
 
 ## New Features
 
-- Added suport for ... intel/llvm#pr
+- Added support for ... intel/llvm#pr
 
 ## Improvements
 

sycl/doc/developer/ContributeToDPCPP.md

@@ -39,7 +39,7 @@ to signify the component changed, e.g.: `[UR]`, `[CUDA]`, `[Doc]`.
 
 ## Release notes
 
-You are encouraged (but it is not required) to record your change into
+You are encouraged to record your change into
 [release notes](../../ReleaseNotes.md) under "Release notes for an upcoming
 release" section.
 
@@ -53,12 +53,12 @@ A change should be noted there when:
 
 A change should **not** be noted there when:
 
-- It has no functional and performance impact
+- It has no functional or performance impact
 - It is about our CI infrastructure, testing infrastructure, or tests
 
 There are no strict guidelines on how to structure release notes, but for
-consistency it is better to follow the existing structure without disrupting it
-much. The structure we have been using so far is split by change type (i.e. new
+consistency it is better to follow the existing structure minimal changes. The
+structure we have been using so far is split by change type (i.e. new
 features and bug fixes) and then sub-split by component (i.e. compiler,
 runtime). Please use past tense when describing your change.
 

sycl/doc/developer/WorkingOnAReleaseBranch.md

@@ -1,23 +1,25 @@
 # Working on a release branch
 
-Release branch is defined as a branch whose name starts with `sycl-rel-` prefix.
+A "release branch" is defined as a branch whose name starts with `sycl-rel-`
+prefix.
 
 Those branches are intended to indicate stable snapshots of our product so that
-our users don't need to guess which nightly build is good enough for our needs.
+our users don't need to guess which nightly build is good enough for their
+needs.
 
 Therefore, those branches have higher quality requirements and as such have
 different contribution rules intended to preserve their stability.
 
-If you are not familiar with [general contribution guidelines][contributing] or
-[DPC++ specific contribution guidelines][contributing-to-dpcpp], please
+If you are not familiar with the [general contribution guidelines][contributing]
+or the [DPC++ specific contribution guidelines][contributing-to-dpcpp], please
 familiarize yourself with those documents first because they also apply to
 release branches.
 
 ## Extra rules for release branches
 
 ### Only cherry-picks are allowed
 
-It is assumed, that everything you do on a release branch, should also be
+It is assumed that everything you do on a release branch should also be
 repeated on the default `sycl` branch to ensure that it is automatically
 included into future releases.
 
@@ -31,7 +33,7 @@ and then backport it to a release branch.
 
 ### No new features are allowed
 
-Features are generally more complicated then bug fixes and may require further
+Features are generally more complicated than bug fixes and may require further
 bug fixes as well. Considering that release branches are intended to be stable,
 no new features are allowed to be added there.