WIP: Create a Secure Glossary of Terms
NOTE Conversations from #86 (closed) have been migrated to this MR.
Problem to solve
The intention of the Secure Glossary of Terms is to help the Secure Group gain a shared agreement and understanding of terms commonly used in Secure products.
This could have the following benefits:
- Promote a ubiquitous language that can be used everywhere - with customers, on issues, in Slack, in code.
- Increase the signal when communicating on issues between Secure team members.
- Remove (some) opportunities for communication to be interpreted the wrong way.
- New team members, and community contributors, can get up to speed faster, reducing the time till productivity.
This issue serves as a place to start the conversation about what terms are worth including, and what their definition might be.
Completion of this issue relies on two outcomes:
- Suggestions have been made, and conversations had to define terms for the Glossary
- Terms have been documented in the GitLab Handbook
For the latter, it has been noted that use of Glossaries is discouraged in GitLab. Advice has been sought from Technical Writers about a suggested approach. In the meantime, there is nothing preventing us getting on with the first outcome.
Rules of engagement
- If you want to add a new term, please start a new conversation. Make the term the heading.
- You can add a term without defining it, but it's preferable if you give it a go. Is there someone you can ask who might know the answer?
- Even if you think your definition is terrible, write it down! We have to start somewhere.
- When adding a new term, please add it to the terms section in this description. Link to the conversation you started in point 1. Please keep the terms list in alphabetical order.
- If you think a definition is misleading or incorrect, please voice your concerns in the conversation for the related term.
- Once we have settled on a term, we will either define it in the description of this MR or add it to the MR code.