misp-training/a.d-community-and-cerebrate/test.txt

46 lines
1.8 KiB
Plaintext
Raw Permalink Normal View History

Model of governance
- Dictatorship instead of democracy
- Gathering ideas, issues, use-cases, code from the community is key, listen to them but reserve the right to veto
- Prevents malevolent community members from blocking the process / imposing tunnel-visioned ideas
- Don't wait for the perfect implementation, start small extend it later
- If the idea doesn't seem suitable for the above, shelf it as soon as possible
Development process based on failures
- Any idea needs real-world validation
- Be willing to throw away features that "sure seemed like a good idea at the time"
- Failures can often be used to pinpoint better alternatives
- Format follows the implementation (code is law)
PMF model
On the flip-side, the dangers of sticking to theoretical format development for too long
- The same mistakes will be made anyway
- Piling mistakes on shaky foundation will be more difficult to undo later
- technical reasons
- sunk cost fallacy
Designing a standard with sharing in mind (how not to do it)
- Originally the sharing aspects were quite limited (private flag)
- If I want to keep it within my organisation, simply set the flag
- If not set any organisation can see it on the instance
- Utterly simplistic, only worked on communities using a hosted MISP
Designing a standard with sharing in mind (how to be a minimalist)
- Needed to be extended once communities started self-hosting MISP to be able to control the distance of the data-flow
- Distirbution levels
- Organisation only (private)
- Community
- Connected community
- All
Designing a standard with sharing in mind (going all out)
- Still not covering all use cases, certain types of users wanting more granularity
- Sharing groups (distribution lists)
- Complex system for persistent and special ad-hoc use-cases
- Next step: Multiple sharing groups/nested sharing groups