Update with proposed suggestions

Author: aepanchi

CONTRIBUTING.md

@@ -32,13 +32,12 @@ of `dpctl`
 
 ### C/C++ Code Style
 
-We use a [clang-format](https://clang.llvm.org/docs/ClangFormat.html) code formatter.
+We use [clang-format](https://clang.llvm.org/docs/ClangFormat.html) for C++ code formatting.
 
 To install, run:
 ```bash
 conda install clang-tools
 ```
-Revision: `10.0.1`
 
 See the default configuration used by dpctl in `.clang-format`.
 
@@ -54,19 +53,18 @@ clang-format -style=file -i         \
      libsyclinterface/helper/source/*.cpp
 ```
 
-> **NOTE:** It is easier to use `pre-commit` and the `clang-format` hook.
+> **:** It is easier to use `pre-commit` and the `clang-format` hook.
 
 ### Python Code Style
 
 We use the following Python code style tools:
 - [black](https://black.readthedocs.io/en/stable/) code formatter.
-    - Revision: `22.3.0`.
 - [flake8](https://flake8.pycqa.org/en/latest/) linter.
-    - Revision `4.0.1`.
 - [isort](https://pycqa.github.io/isort/) import sorter.
-    - Revision `5.10.1`.
 
-> **NOTE:** Refer `pyproject.toml` and `.flake8` config files for current configurations.
+> **NOTE:** Refer:
+>  * `pyproject.toml` and `.flake8` config files for current configurations
+> * `.pre-commit-config.yaml` file for the versions of the tools
 
 Run these three tools before each commit. 
 
@@ -116,13 +114,13 @@ The standard header looks like this:
 ```
 ---
 > **NOTE:**
-- The `-*- C++ -*-` string on the first line tells Emacs* that
+>- The `-*- C++ -*-` string on the first line tells Emacs* that
   it is a C++ file. The string is only needed for `*.h` headers and
   should be omitted for `*.cpp` files. Without the string, Emacs* assumes the
   file is a C header.
-- The copyright year must be updated every calendar year.
-- Each comment line should be a max of 80 chars.
-- A Doxygen `\file` tag describing the contents of the file must be provided.
+>- The copyright year must be updated every calendar year.
+>- Each comment line should be a max of 80 chars.
+>- A Doxygen `\file` tag describing the contents of the file must be provided.
   Note that the `\file` tag is inside a Doxygen comment block. It is
   defined by the `///` comment marker instead of the `//` comment marker used in the
   rest of the header.
@@ -166,7 +164,7 @@ To install, run:
 pip install bandit
 ```
 
-Revision: `1.7.0`
+Bandit revision used: `1.7.0`
 
 Before each commit, run:
 ```bash
@@ -211,8 +209,8 @@ To check the code coverage for your code, follow these steps:
     `setup.py`.
 
     The coverage results for the C and Python* sources are printed to the
-    terminal during the build (C API) and pytest execution (Python*).
-    The detailed coverage reports for the C API are saved to the
+    terminal during the build (`libsyclinterface`) and pytest execution (Python*).
+    The detailed coverage reports for the `libsyclinterface` library are saved to the
     `dpctl-c-api-coverage` directory. The Python* coverage reports are saved to
     the `htmlcov` directory.
 
@@ -234,7 +232,7 @@ To check the code coverage for your code, follow these steps:
 
 ## Error Reporting and Logging
 
-The SyclInterface library responds to the `DPCTL_VERBOSITY` environment variable that controls the severity level of errors printed to the console.
+The `libsyclinterface` library responds to the `DPCTL_VERBOSITY` environment variable that controls the severity level of errors printed to the console.
 Specify one of the following severity levels (in increasing order of severity): `warning` and `error` by running:
 
 ```bash
@@ -260,7 +258,7 @@ conda install glog
 python scripts/build_locally.py --oneapi --glog
 ```
 
-3. Use `dpctl._diagnostics.syclinterface_diagnostics(verbosity="warning", log_dir=None)` context manager to switch library diagnostics on for a block of a Python* code.
+3. Use the `dpctl._diagnostics.syclinterface_diagnostics(verbosity="warning", log_dir=None)` context manager to switch library diagnostics on for a block of a Python* code.
 Use `DPCTLService_InitLogger` and `DPCTLService_ShutdownLogger` library C functions during library development to initialize Google's logging library and de-initialize accordingly:
 
 ```python

README.md

@@ -21,8 +21,7 @@ The compute kernel can be a code:
 The `dpctl` library is built upon the [SYCL*
 standard](https://www.khronos.org/sycl/). It also implements Python
 bindings for a subset of the standard [runtime
-classes](https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html#_sycl_runtime_classes).
-Such classes allow users to:
+classes](https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html#_sycl_runtime_classes) that allow users to:
 * query platforms
 * discover and represent devices and sub-devices
 * construct contexts and queues 
@@ -98,7 +97,7 @@ setting up a development environment and building `dpctl` from the source.
 
 Find our examples [here](examples). 
 
-To build these examples, run:
+To run these examples, use:
 
 ```bash
 for script in `ls examples/python/`; 

docs/docfiles/user_guides/QuickStart.rst

@@ -48,7 +48,7 @@ On Windows* OS
 Install the Wheel Package from PyPi*
 ====================================
 
-To install Dpctl from PyPi*, run:
+To install dpctl from PyPi*, run:
 
 .. code-block:: bash
 
@@ -77,7 +77,7 @@ On Windows* OS
 Building from the Source
 ========================
 
-To build dpctl from the source, you need dpcpp and GPU drivers, optionally CPU
+To build dpctl from the source, you need dpcpp and GPU drivers, and optionally CPU
 OpenCL drivers. It is preferable to use the dpcpp compiler packaged as part of
 oneAPI. However, it is possible to use a custom build of dpcpp to build dpctl,
 especially if you want to enable CUDA* support.
@@ -86,7 +86,7 @@ Building using oneAPI dpcpp
 ---------------------------
 
 Install oneAPI and graphics drivers to the system prior
-to proceed further.
+to proceeding further.
 
 Activate oneAPI 
 ~~~~~~~~~~~~~~~
@@ -242,10 +242,10 @@ You can execute the dpctl Python* test suite as follow:
     pytest --pyargs dpctl
 
 
-Building the DPCTLSyclInterface Library
+Building the libsyclinterface Library
 =======================================
 
-The libDPCTLSyclInterface is a shared library used by the Python* package.
+The libsyclinterface is a shared library used by the Python* package.
 To build the library, you need: 
 
 *  ``DPC++`` toolchain

docs/docfiles/user_guides/manual/dpctl/basic_concepts.rst

@@ -37,13 +37,13 @@ This section introduces the basic concepts for XPU management used by `dpctl`.
 * **Queue**
    A queue is needed to schedule the execution of any computation or data
    copying on the device. Queue construction requires specifying a device
-   and contextual targeting that device as well as additional properties,
+   and a context targeting that device as well as additional properties,
    such as whether profiling information should be collected or submitted
    tasks are executed in the order in which they were submitted.
 
 * **Event**
    Holds information related to computation or data movement operation
-   scheduled for the execution on a queue. That can be its execution status or
+   scheduled for the execution on a queue. An event can store the execution status or
    profiling information if the queue, to which the task is submitted, is allowed
    for the collection of such information. Events can be used to specify task
    dependencies or to synchronize host and devices.

docs/docfiles/user_guides/manual/dpctl/device_selection.rst

@@ -144,7 +144,7 @@ of hardware properties that may be used for device selection.
 .. Note::
     A **root** device implies an unpartitioned device. A root device can be
     partitioned into two or more :ref:`sub-devices <sec-devices-sub-devices>`
-    based on various criteria. For example, a CPU device with multiple NUMA*
+    based on various criteria. For example, a CPU device with multiple NUMA
     domains may be partitioned into multiple sub-devices, each representing a
     sub-device.
 

docs/docfiles/user_guides/manual/dpctl/devices.rst

@@ -137,7 +137,7 @@ Several types of partitioning schemes are available:
     architectural hierarchy.
 
 The following example shows an affinity-based partitioning of a CPU device
-into sub-devices based on the available NUMA* domains:
+into sub-devices based on the available NUMA domains:
 
 .. _fig-partition-cpu:
 

docs/docfiles/user_guides/manual/dpctl/queues.rst

@@ -98,7 +98,7 @@ used is created with the ``enable_profiling`` property and only becomes availabl
 after the task execution is complete.
 
 The :class:`dpctl.SyclTimer` class implements a Python context manager. 
-You can use this manager to collect cumulative profiling information for all the tasks submitted
+You can use this context manager to collect cumulative profiling information for all the tasks submitted
 to the queue of interest by functions executed within the context:
 
 .. code-block:: python