Update CONTRIBUTING.md

Co-authored-by: Owais Kazi <[email protected]>
Signed-off-by: Stephen Crawford <[email protected]>

CONTRIBUTING.md

@@ -172,7 +172,7 @@ We have a lot of mechanisms to help expedite towards an accepted PR. Here are so
 3. *Utilize feature flags*: Features that are safeguarded behind feature flags are more likely to be merged and backported, as they come with an additional layer of protection. Refer to this [example PR](https://github.com/opensearch-project/OpenSearch/pull/4959) for implementation details.
 4. *Use appropriate Java tags*:
     - `@opensearch.internal`: Marks internal classes subject to rapid changes.
-    - `@opensearch.api`: Marks public facing API classes that provide bwc guarantees.
+    - `@opensearch.api`: Marks public-facing API classes with backward compatibility guarantees.
     - `@opensearch.experimental`: Mark rapidly changing [experimental code](./DEVELOPER_GUIDE.md#experimental-development).
 5. *Use sandbox for big core changes*: Any new features or enhancements that make changes to core classes (e.g., search phases, codecs, or specialized lucene APIs) are more likely to. be merged if they are sandboxed. This can only be enabled on the java CLI (`-Dsandbox.enabled=true`).
 6. *Micro-benchmark critical path*: This is a lesser known mechanism, but if you have critical path changes you're afraid will impact performance (the changes touch the garbage collector, heap, direct memory, or CPU) then including a [microbenchmark](https://github.com/opensearch-project/OpenSearch/tree/main/benchmarks) with your PR (and jfr or flamegraph results in the description) is a *GREAT IDEA* and will help expedite the review process.