Docs and Code Improvements for OpenZeppelin Contracts

CODE_OF_CONDUCT.md

@@ -55,8 +55,11 @@ further defined and clarified by project maintainers.
 ## Enforcement
 
 Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by contacting the project team at contact@openzeppelin.com. All
-complaints will be reviewed and investigated and will result in a response that
+reported by contacting the project team at:
+
+**Email: contact@openzeppelin.com**
+
+All complaints will be reviewed and investigated and will result in a response that
 is deemed necessary and appropriate to the circumstances. The project team is
 obligated to maintain confidentiality with regard to the reporter of an incident.
 Further details of specific enforcement policies may be posted separately.

GUIDELINES.md

@@ -84,7 +84,7 @@ In addition to the official Solidity Style Guide we have a number of other conve
 
   Changes to state should be accompanied by events, and in some cases it is not correct to arbitrarily set state. Encapsulating variables as private and only allowing modification via setters enables us to ensure that events and other rules are followed reliably and prevents this kind of user error.
 
-* Internal or private state variables or functions should have an underscore prefix.
+* Internal or private state variables and functions should have an underscore prefix.
 
   ```solidity
   contract TestContract {

RELEASING.md

@@ -1,6 +1,6 @@
 # Releasing
 
-OpenZeppelin Contracts uses a fully automated release process that takes care of compiling, packaging, and publishing the library, all of which is carried out in a clean CI environment (GitHub Actions), implemented in the ([`release-cycle`](.github/workflows/release-cycle.yml)) workflow. This helps to reduce the potential for human error and inconsistencies, and ensures that the release process is ongoing and reliable.
+OpenZeppelin Contracts uses a fully automated release process that takes care of compiling, packaging, and publishing the library, all of which is carried out in a clean CI environment (GitHub Actions), implemented in the [`release-cycle`](.github/workflows/release-cycle.yml) workflow. This helps to reduce the potential for human error and inconsistencies, and ensures that the release process is ongoing and reliable.
 
 ## Changesets
 

contracts/mocks/Stateless.sol

@@ -2,7 +2,7 @@
 
 pragma solidity ^0.8.24;
 
-// We keep these imports and a dummy contract just to we can run the test suite after transpilation.
+// We keep these imports and a dummy contract just so we can run the test suite after transpilation.
 
 import {Address} from "../utils/Address.sol";
 import {Arrays} from "../utils/Arrays.sol";

contracts/mocks/StorageSlotMock.sol

@@ -49,7 +49,7 @@ contract StorageSlotMock is Multicall {
         return slot.getInt256Slot().value;
     }
 
-    mapping(uint256 key => string) public stringMap;
+    mapping(uint256 => string) public stringMap;
 
     function setStringSlot(bytes32 slot, string calldata value) public {
         slot.getStringSlot().value = value;

contracts/mocks/VotesExtendedMock.sol

@@ -25,7 +25,7 @@ abstract contract VotesExtendedMock is VotesExtended {
     }
 
     function _burn(address account, uint256 votes) internal {
-        _votingUnits[account] += votes;
+        _votingUnits[account] -= votes;
         _transferVotingUnits(account, address(0), votes);
     }
 }

contracts/mocks/VotesMock.sol

@@ -25,7 +25,7 @@ abstract contract VotesMock is Votes {
     }
 
     function _burn(address account, uint256 votes) internal {
-        _votingUnits[account] += votes;
+        _votingUnits[account] -= votes;
         _transferVotingUnits(account, address(0), votes);
     }
 }