Docs/starter append

contracts/eosio.bios/include/eosio.bios/eosio.bios.hpp

@@ -38,25 +38,6 @@ namespace eosio {
    }
 }
 
-/**
- * EOSIO Contracts
- *
- * @details The design of the EOSIO blockchain calls for a number of smart contracts that are run at a
- * privileged permission level in order to support functions such as block producer registration and
- * voting, token staking for CPU and network bandwidth, RAM purchasing, multi-sig, etc. These smart
- * contracts are referred to as the system, token, msig and wrap (formerly known as sudo) contracts.
- *
- * This repository contains examples of these privileged contracts that are useful when deploying,
- * managing, and/or using an EOSIO blockchain. They are provided for reference purposes:
- * - eosio.bios
- * - eosio.system
- * - eosio.msig
- * - eosio.wrap
- *
- * The following unprivileged contract(s) are also part of the system.
- * - eosio.token
- */
-
 namespace eosio {
 
    using eosio::ignore;

contracts/eosio.msig/include/eosio.msig/eosio.msig.hpp

@@ -6,6 +6,7 @@
 #include <eosio/transaction.hpp>
 
 namespace eosio {
+
    /**
     * @defgroup eosiomsig eosio.msig
     * @ingroup eosiocontracts
@@ -27,8 +28,7 @@ namespace eosio {
           * authorized by the provided keys and permissions, and if the proposal name doesn’t
           * already exist; if all validations pass the `proposal_name` and `trx` trasanction are
           * saved in the proposals table and the `requested` permission levels to the
-          * approvals table (for the `proposer` context).
-          * Storage changes are billed to `proposer`.
+          * approvals table (for the `proposer` context). Storage changes are billed to `proposer`.
           *
           * @param proposer - The account proposing a transaction
           * @param proposal_name - The name of the proposal (should be unique for proposer)
@@ -46,8 +46,7 @@ namespace eosio {
           * proposed by `proposer`. If the proposal's requested approval list contains the `level`
           * permission then the `level` permission is moved from internal `requested_approvals` list to
           * internal `provided_approvals` list of the proposal, thus persisting the approval for
-          * the `proposal_name` proposal.
-          * Storage changes are billed to `proposer`.
+          * the `proposal_name` proposal. Storage changes are billed to `proposer`.
           *
           * @param proposer - The account proposing a transaction
           * @param proposal_name - The name of the proposal (should be unique for proposer)