Correct some grammatical and expression errors in the CONTRIBUTING.md (pytorch#167926)

Correct some grammatical and expression errors in the CONTRIBUTING.md file.
Fixes #ISSUE_NUMBER

Pull Request resolved: pytorch#167926
Approved by: https://github.com/mikaylagawarecki

Author: wenlinchong17-web

CONTRIBUTING.md

@@ -789,15 +789,15 @@ with `pip install ninja`.  If PyTorch was already built, you will need
 to run `python setup.py clean` once after installing ninja for builds to
 succeed.
 
-Note: Make sure to use a machine with a larger number of CPU cores, this will significantly reduce your build times.
+Note: Make sure to use a machine with a larger number of CPU cores;this will significantly reduce your build times.
 
 #### Use CCache
 
 Even when dependencies are tracked with file modification, there are many
 situations where files get rebuilt when a previous compilation was exactly the
 same. Using ccache in a situation like this is a real time-saver.
 
-Before building pytorch, install ccache from your package manager of choice:
+Before building PyTorch, install ccache from your package manager of choice:
 
 ```bash
 sudo apt install ccache
@@ -816,7 +816,7 @@ ccache -M 25Gi  # -M 0 for unlimited
 ccache -F 0
 ```
 
-To check this is working, do two clean builds of pytorch in a row. The second
+To check this is working, do two clean builds of PyTorch in a row. The second
 build should be substantially and noticeably faster than the first build. If
 this doesn't seem to be the case, check the `CMAKE_<LANG>_COMPILER_LAUNCHER`
 rules in `build/CMakeCache.txt`, where `<LANG>` is `C`, `CXX` and `CUDA`.
@@ -865,8 +865,8 @@ This adds a build step where the compiler takes `<ATen/ATen.h>` and essentially
 dumps its internal AST to a file so the compiler can avoid repeating itself for
 every `.cpp` file.
 
-One caveat is that when enabled, this header gets included in every file by default.
-Which may change what code is legal, for example:
+One caveat is that when enabled, this header gets included in every file by default,
+which may change what code is legal, for example:
 - internal functions can never alias existing names in `<ATen/ATen.h>`
 - names in `<ATen/ATen.h>` will work even if you don't explicitly include it.
 
@@ -886,11 +886,11 @@ python -m pip install --no-build-isolation -v -e .
 
 ### Rebuild few files with debug information
 
-While debugging a problem one often had to maintain a debug build in a separate folder.
-But often only a few files needs to be rebuild with debug info to get a symbolicated backtrace or enable source debugging
+While debugging a problem, one often has to maintain a debug build in a separate folder.
+But often only a few files need to be rebuilt with debug info to get a symbolicated backtrace or enable source debugging.
 One can easily solve this with the help of `tools/build_with_debinfo.py`
 
-For example, suppose one wants to debug what is going on while tensor index is selected, which can be achieved by setting a breakpoint at `applySelect` function:
+For example, suppose one wants to debug what is going on while a tensor index is selected, which can be achieved by setting a breakpoint at `applySelect` function:
 ```
 % lldb -o "b applySelect" -o "process launch" -- python3 -c "import torch;print(torch.rand(5)[3])"
 (lldb) target create "python"
@@ -912,7 +912,7 @@ libtorch_python.dylib`at::indexing::impl::applySelect:
 Target 0: (python) stopped.
 Process 87729 launched: '/usr/bin/python' (arm64)
 ```
-Which is not very informative, but can be easily remedied by rebuilding `python_variable_indexing.cpp` with debug information
+This is not very informative, but can be easily remedied by rebuilding `python_variable_indexing.cpp` with debug information.
 ```
 % ./tools/build_with_debinfo.py torch/csrc/autograd/python_variable_indexing.cpp
 [1 / 2] Building caffe2/torch/CMakeFiles/torch_python.dir/csrc/autograd/python_variable_indexing.cpp.o
@@ -942,7 +942,7 @@ Process 87741 stopped
 Target 0: (python) stopped.
 Process 87741 launched: '/usr/bin/python3' (arm64)
 ```
-Which is much more useful, isn't it?
+This is much more useful, isn't it?
 
 ### C++ frontend development tips
 
@@ -956,10 +956,10 @@ Please follow the lead of the other tests to see how to write a new test case.
 
 ### GDB integration
 
-If you are debugging pytorch inside GDB, you might be interested in
+If you are debugging PyTorch inside GDB, you might be interested in
 [pytorch-gdb](tools/gdb/pytorch-gdb.py). This script introduces some
-pytorch-specific commands which you can use from the GDB prompt. In
-particular, `torch-tensor-repr` prints a human-readable repr of an at::Tensor
+PyTorch-specific commands which you can use from the GDB prompt. In
+particular, `torch-tensor-repr` prints a human-readable representation of an at::Tensor
 object. Example of usage:
 
 ```
@@ -993,7 +993,7 @@ tensor([1., 2., 3., 4.], dtype=torch.float64)
 ```
 
 GDB tries to automatically load `pytorch-gdb` thanks to the
-[.gdbinit](.gdbinit) at the root of the pytorch repo. However, auto-loadings is disabled by default, because of security reasons:
+[.gdbinit](.gdbinit) at the root of the PyTorch repository. However, auto-loading is disabled by default, because of security reasons:
 
 ```bash
 $ gdb
@@ -1034,7 +1034,7 @@ If you are working on the CUDA code, here are some useful CUDA debugging tips:
    `std::tuple` etc. in device code. Many of such features are possible because of the
    [--expt-relaxed-constexpr](https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#constexpr-functions)
    nvcc flag. There is a known [issue](https://github.com/ROCm/hip/issues/374)
-   that ROCm errors out on device code, which uses such stl functions.
+   that ROCm errors out on device code, which uses such STL functions.
 4. A good performance metric for a CUDA kernel is the
    [Effective Memory Bandwidth](https://devblogs.nvidia.com/how-implement-performance-metrics-cuda-cc/).
    It is useful for you to measure this metric whenever you are writing/optimizing a CUDA
@@ -1289,7 +1289,7 @@ More information can be found
 
 We need `LD_PRELOAD` because there is a cmake check that ensures that a
 simple program builds and runs. If we are building with ASAN as a shared
-library, we need to `LD_PRELOAD` the runtime library, otherwise there will
+library, we need to use `LD_PRELOAD` to load the runtime library, otherwise there will be
 dynamic linker errors and the check will fail.
 
 We don’t actually need either of these if we fix the cmake checks.
@@ -1361,7 +1361,7 @@ There are two possible choices for which commit to use:
 For all practical purposes, most people can think of the commit being used as
 commit `B` (choice **1**).
 
-However, if workflow files (which govern CI behavior) were modified (either by your PR or since dev branch were created ) there's
+However, if workflow files (which govern CI behavior) were modified (either by your PR or since dev branch was created) there's
 a nuance to know about:
 The workflow files themselves get taken from checkpoint `C`, the merger of your
 PR and the `main` branch. But only the workflow files get taken from that merged