-
Notifications
You must be signed in to change notification settings - Fork 85
Risk Identification
Author's note: This is a follow up to the general intro on Risk Management.
I propose that we use a standard 1-9 system for for risk identification and calculation (1 being low, and 9 being high). With where everyone on the Grin council gets to vote on the following three things:
- How much they know about the scope of the risk?
- If unaddressed how likely is the risk to occur? (Risk Chance)
- If unaddressed how big is the impact of the risk?(Risk Impact)
For example, in a traditional organization, imagine that the risk of the firm's database suffers a catastrophic failure is being analysed. The CIO might answer 9, 2, 8 to the questions above, while the CFO might answer 2, 5, 3. The answers to questions 2 & 3 are therefore multiplied by the answer to question 1, to achieve a weighting based on each respondent's knowledge of the scope. In the above example, you would end up with the following results:
Risk of Database Failure | |||||
---|---|---|---|---|---|
Knowledge | Chance | Weighted chance | Threat | Weighted Threat | |
CIO | 9 | 2 | 18 | 8 | 72 |
CFO | 2 | 5 | 10 | 3 | 6 |
Total | 11 | 7 | 28 | 11 | 78 |
Weighted totals | Max risk | Weighted chance | Weighted Threat | ||
99 | 28% | 78% |
A system for assigning these knowledge weights would need to be determined. Typically they can be self assessed and should be defended if questioned. Whether this would work in an open source project where participant are not under the same pressures to behave professionally and answer truthfully, remains to be determined.
In addition to doing this in-house risk identification, I propose that a webpage is created where anyone in the community can submit a risk and vote on the Chance and Impact of it. In order to keep votes constant they should last a finite amount of time (such as 1 year). The portal could be used to identify new and unseen risks, and outsource a considerable amount of the brainstorming. If the core team's opinion on risk differs significantly from the community's then the core team should provide a written explanation of their reasoning.
TBD.
Basics
- Getting Started
- User Documentation
- MimbleWimble
- FAQ
- Planned releases (Roadmap)
- Code of Conduct
Contributing
- Contributing Guide
- Code Structure
- Code coverage and metrics
- Code Reviews and Audits
- Adding repos to /mimblewimble
Development
Mining
Infrastructure
Exchange integrations
R&D
Grin Community
Grin Governance
Risk Management
Grin Internals
- Block Header Data Structure
- Detailed validation logic
- P2P Protocol
Misc