From 9afcc57f655eedbcdb46b4aaca9b667ef3c0bbde Mon Sep 17 00:00:00 2001 From: Talita Yada Date: Wed, 6 Sep 2023 01:23:56 -0300 Subject: [PATCH] fix text --- CODING_GUIDELINES.md | 3 +-- CONTRIBUTING.md | 9 ++++----- 2 files changed, 5 insertions(+), 7 deletions(-) diff --git a/CODING_GUIDELINES.md b/CODING_GUIDELINES.md index fdd1068a..a8140d10 100644 --- a/CODING_GUIDELINES.md +++ b/CODING_GUIDELINES.md @@ -64,8 +64,7 @@ In particular, you should always comment any decision that: * Takes a significant amount of time to produce. A good rule of thumb here is that if you spent more than 1 hour thinking on how to produce a fragment of code that took 2 minutes of wrist time to write you should document your thinking to aid reader and allow for validation. -* Need to preserve properties of the implementation. This is the case of performance sensitive portions of the codebase, - goroutines synchronization, implementations of security primitives, congestion control algorithms, etc. +* Need to preserve properties of the implementation. This is the case of performance sensitive portions of the codebase, implementations of security primitives, congestion control algorithms, etc. As a general rule of what not to comment you should avoid: diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 77ee77e2..2ebc96ed 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -30,7 +30,7 @@ guidelines will be disregarded and told to make the required modifications to do ## Request For Change / Feature Request Generally speaking an RFC is needed when you want to add a new feature or change an existing one in an incompatible way -that might result in a major version bump to the toolkit. +that might result in a major version bump to the SDK. Though it seems a little bureaucratic, the process is in place in order to avoid frustration of a potential contributor by making the discussions take place before any code is written. Once the design and direction is fully agreed then the @@ -68,13 +68,12 @@ push changes to their personal fork and create pull requests to bring those chan Your basic steps to get going: -* Fork the corresponding toolkit repository and create a branch from master for the issue you are working on. +* Fork the corresponding SDK repository and create a branch from master for the issue you are working on. * Commit as you go following our git conventions. -* Include tests that cover all non-trivial code. The existing tests should provide a template on how to test the toolkit - correctly. +* Include tests that cover all non-trivial code. The existing tests should provide a template on how to test the SDK correctly. * Make sure all test passes. * All code changes are expected to comply with the formatting style. -* Push your commits to GitHub and create a pull request against the corresponding toolkit component master branch. +* Push your commits to GitHub and create a pull request against the corresponding SDK component master branch. If taking too much time to deliver code, **always** [rebase](https://git-scm.com/docs/git-rebase) towards `master` before asking for a review, and avoid reverse merge commits.