From 5f82dd0544fe38b36099fa4f3af2d42eac8bfd09 Mon Sep 17 00:00:00 2001 From: Ryan Macklin Date: Wed, 24 Aug 2022 22:47:32 +0000 Subject: [PATCH 1/8] Initial submission of RFC-012 --- .../RFC-012-internal-knowledge-base.md | 112 ++++++++++++++++++ 1 file changed, 112 insertions(+) create mode 100644 Accepted-RFCs/RFC-012-internal-knowledge-base.md diff --git a/Accepted-RFCs/RFC-012-internal-knowledge-base.md b/Accepted-RFCs/RFC-012-internal-knowledge-base.md new file mode 100644 index 0000000..5647a5f --- /dev/null +++ b/Accepted-RFCs/RFC-012-internal-knowledge-base.md @@ -0,0 +1,112 @@ +# RFC-012: Internal Knowledge Base +## Proposed by + +Ryan Macklin ([@macklin](https://thegooddocs.slack.com/team/U01DYRWG43X)) + +Initially submitted on 24 Aug 2022 + +## Current status + +- [x] Draft +- [x] Under discussion +- [ ] Final comment and voting (until YYYY-MM-DD) {{Add date after selecting this status.}} +- [ ] Accepted +- [ ] Rejected +- [ ] Implemented +- [ ] Deferred +- [ ] Withdrawn + +## Proposal overview + +We need a central knowledge repository for contributors that: +* Isn't fragmented across different platforms or accounts +* Is easy for new contributors to access +* Has a sense of hierarchy +* Allows contributors to dump critical or needed info in a place that keeps them from being a bus number +* Has some sense of discipline/oversight to keep it from becoming disorganized or discordant + +## Motivation + +We don't have a good way to share information to use contributors, or a common places where information can live and grow. This was mentioned by multiple people during our recent retrospectives. + +## Proposal + +We could use a GitLab wiki or repo as a place where contributors can post material or comment on said material with questions, corrections, etc. + +We'd have some guideline on structure, intent, etc. Each core initiative would have a space for their information, along with general information, community resources, etc. + +Ideally, our docs would make use of our templates—in fact, they would make for great use/test cases. However, we would allow for a "quickly written" status, in cases where information needs to be dumped from someone's mind, but the time/effort cost in polishing isn't currently possible. + +We'd have a mechanism for checking the freshness of content, though we can defer the details of that until later. + +### GitLab wiki: a.k.a. Do we already have this? +There's a wiki in GitLab, and [Aaron has release weight information there](https://gitlab.com/tgdp/governance/-/wikis/Guide-to-assigning-weight-scores-to-issues-and-epics-%28release-planning%29). Should we just go with that? Does that make sense for us as a group of groups? + +Is the wiki going to be oversaturated with other purposes? Would it be difficult to use search functionality when looking for KB articles, due to non-KB stuff in the wiki also populating the search results? + +## Consequences + +We'd have a central place for information. + +Said information though could become out of date without a contributor realizing it, due to the nature of knowledge bases and the bandwidth of contributors. + +We also need to decide on the access control. Having new contributors being able to edit can be great for finding holes in the content, but could also be an issue if contributors put misunderstandings into our KB without others noticing right away. + + +## Links and prior art + +{This section is optional if you want to [link](https://example.com) to other resources.} + + +## Open questions + +{This section is optional and is where you can list questions that won't be resolved by this RFC, including those raised in comments from community members.} + + +## Decisions deferred + +* Freshness mechanisms +* Access control (a.k.a. who can edit/update) + + +## Feedback + +{If you accept feedback from a community member, you will incorporate it into your RFC before it is accepted. +If you reject feedback, note that rejected feedback here before resolving the conversation.} + + +## Implementation checklist + +If this proposal is accepted, the following tasks must be completed: + +- [ ] Set the site/wiki/whatever up +- [ ] Draft the core info on how to use & contribute, so we're all on the same page about it +- [ ] Create the initial structure/document tree +- [ ] Ask group leads to dump critical or infrastructure knowledge from their brains or disparate notes into the KB + + +## Votes + +Votes as per our [decision process](https://thegooddocsproject.dev/decisions/): + +Project steering committee (listed alphabetically by first name): + +- Aaron Peters: +- Alyssa Rock: +- Ankita Tripathi: +- Bryan Klein: +- Cameron Shorter: +- Carrie Crowe: +- Erin McKean: +- Deanna Thompson: +- Felicity Brand: +- Gayathri Krishnaswamy: +- Morgan Craft: +- Nelson Guya: +- Ryan Macklin: +- Tina Lüdtke: + + +Community members who voted (non-binding): + +- {Your name}: {Your vote} \ No newline at end of file -- GitLab From 9f64e36581f5bf430de9719d498a2619a048417a Mon Sep 17 00:00:00 2001 From: Ryan Macklin Date: Thu, 25 Aug 2022 00:11:00 +0000 Subject: [PATCH 2/8] Added a thought on small procedures --- Accepted-RFCs/RFC-012-internal-knowledge-base.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Accepted-RFCs/RFC-012-internal-knowledge-base.md b/Accepted-RFCs/RFC-012-internal-knowledge-base.md index 5647a5f..d164fb9 100644 --- a/Accepted-RFCs/RFC-012-internal-knowledge-base.md +++ b/Accepted-RFCs/RFC-012-internal-knowledge-base.md @@ -52,6 +52,8 @@ Said information though could become out of date without a contributor realizing We also need to decide on the access control. Having new contributors being able to edit can be great for finding holes in the content, but could also be an issue if contributors put misunderstandings into our KB without others noticing right away. +This space would also be great for small procedural elements that should be documented, but don't need a full RFC for said documentation (such as the recent "break/restart" process the co-chairs initiated). That way such info isn't lost to the ether due to a lack of documentation procedure for such things. + ## Links and prior art -- GitLab From 2f246992d4501aa9609f36e6000ccc5f8a8d511c Mon Sep 17 00:00:00 2001 From: Ryan Macklin Date: Thu, 25 Aug 2022 00:14:30 +0000 Subject: [PATCH 3/8] Added clarification on internal facing --- Accepted-RFCs/RFC-012-internal-knowledge-base.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/Accepted-RFCs/RFC-012-internal-knowledge-base.md b/Accepted-RFCs/RFC-012-internal-knowledge-base.md index d164fb9..4b2efed 100644 --- a/Accepted-RFCs/RFC-012-internal-knowledge-base.md +++ b/Accepted-RFCs/RFC-012-internal-knowledge-base.md @@ -25,6 +25,8 @@ We need a central knowledge repository for contributors that: * Allows contributors to dump critical or needed info in a place that keeps them from being a bus number * Has some sense of discipline/oversight to keep it from becoming disorganized or discordant +This is internal-facing material, which is about the audience, and not about privacy. We should assume all information is publicly viewable, just intended to be viewed by those with working group context. Our template/product users wouldn't need to know this stuff, but there's no reason to hide it. + ## Motivation We don't have a good way to share information to use contributors, or a common places where information can live and grow. This was mentioned by multiple people during our recent retrospectives. @@ -77,6 +79,11 @@ This space would also be great for small procedural elements that should be docu If you reject feedback, note that rejected feedback here before resolving the conversation.} +## Organizational dependencies + +* The tech team would be involved in implementation +* Content strategy may have thoughts, even with this being internal-facing info + ## Implementation checklist If this proposal is accepted, the following tasks must be completed: -- GitLab From 686b20bd702b9fae549a82c1e8a7d2cb9d4ba951 Mon Sep 17 00:00:00 2001 From: Ryan Macklin Date: Wed, 21 Sep 2022 22:42:16 +0000 Subject: [PATCH 4/8] Incorporated feedback so far --- .../RFC-012-internal-knowledge-base.md | 37 ++++++++++++------- 1 file changed, 24 insertions(+), 13 deletions(-) diff --git a/Accepted-RFCs/RFC-012-internal-knowledge-base.md b/Accepted-RFCs/RFC-012-internal-knowledge-base.md index 4b2efed..30a61d5 100644 --- a/Accepted-RFCs/RFC-012-internal-knowledge-base.md +++ b/Accepted-RFCs/RFC-012-internal-knowledge-base.md @@ -22,10 +22,10 @@ We need a central knowledge repository for contributors that: * Isn't fragmented across different platforms or accounts * Is easy for new contributors to access * Has a sense of hierarchy -* Allows contributors to dump critical or needed info in a place that keeps them from being a bus number +* Allows contributors to dump critical or needed info in a place that prevents them from becoming a bottleneck * Has some sense of discipline/oversight to keep it from becoming disorganized or discordant -This is internal-facing material, which is about the audience, and not about privacy. We should assume all information is publicly viewable, just intended to be viewed by those with working group context. Our template/product users wouldn't need to know this stuff, but there's no reason to hide it. +This is internal-facing material, meant to be consumed by members of the Good Docs project. Our template/product users don't need to know this stuff, but there's no reason to hide it. Therefore, we keep all information viewable to the public. ## Motivation @@ -37,14 +37,18 @@ We could use a GitLab wiki or repo as a place where contributors can post materi We'd have some guideline on structure, intent, etc. Each core initiative would have a space for their information, along with general information, community resources, etc. +The KB should be easily visible and searchable for new contributors, especially those who are new to GitLab. We want to avoid situtions where viewing the KB is cumbersome, such as Tina's concerns: "For example, I experienced that many of my Chronologue group members are pretty new to Github (let alone Gitlab), and switching/finding things in different places than their 'home' repo is pretty hard for them." + Ideally, our docs would make use of our templates—in fact, they would make for great use/test cases. However, we would allow for a "quickly written" status, in cases where information needs to be dumped from someone's mind, but the time/effort cost in polishing isn't currently possible. -We'd have a mechanism for checking the freshness of content, though we can defer the details of that until later. +We'd have a mechanism for checking the freshness of content, though we can defer the details of that until later. That may inculde owners or reviewers listed on individual articles or sections. ### GitLab wiki: a.k.a. Do we already have this? There's a wiki in GitLab, and [Aaron has release weight information there](https://gitlab.com/tgdp/governance/-/wikis/Guide-to-assigning-weight-scores-to-issues-and-epics-%28release-planning%29). Should we just go with that? Does that make sense for us as a group of groups? -Is the wiki going to be oversaturated with other purposes? Would it be difficult to use search functionality when looking for KB articles, due to non-KB stuff in the wiki also populating the search results? +Comment from Aaron: "In my mind the (a) wiki is the place for this type of information, as it's basically what they were designed for. The tricky part will be where it resides, and slightly related, if there's one for everything or one for each WG (as each repo has its own wiki I believe). I usually favor the "source of truth" approach, which implies we have one wiki to rule them all. Of course, at this point the IA and content strategy becomes super important..." + +If we use a wiki, can we keep that wiki to being only for KB material? Ideally, we shouldn't have a wiki oversaturated with multiple purposes? Would it be difficult to use search functionality when looking for KB articles, due to non-KB stuff in the wiki also populating the search results? ## Consequences @@ -54,8 +58,9 @@ Said information though could become out of date without a contributor realizing We also need to decide on the access control. Having new contributors being able to edit can be great for finding holes in the content, but could also be an issue if contributors put misunderstandings into our KB without others noticing right away. -This space would also be great for small procedural elements that should be documented, but don't need a full RFC for said documentation (such as the recent "break/restart" process the co-chairs initiated). That way such info isn't lost to the ether due to a lack of documentation procedure for such things. +Comment from Tina: "I see this as a blessing and curse as well. Having a stricter format that needs a PR before contributing would prevent these things, I guess." +This space would also be great for small procedural elements that should be documented, but don't need a full RFC for said documentation (such as the recent "break/restart" process the co-chairs initiated). That way such info isn't lost to the ether due to a lack of documentation procedure for such things. ## Links and prior art @@ -69,16 +74,13 @@ This space would also be great for small procedural elements that should be docu ## Decisions deferred -* Freshness mechanisms -* Access control (a.k.a. who can edit/update) - +None listed ## Feedback {If you accept feedback from a community member, you will incorporate it into your RFC before it is accepted. If you reject feedback, note that rejected feedback here before resolving the conversation.} - ## Organizational dependencies * The tech team would be involved in implementation @@ -88,10 +90,19 @@ If you reject feedback, note that rejected feedback here before resolving the co If this proposal is accepted, the following tasks must be completed: -- [ ] Set the site/wiki/whatever up -- [ ] Draft the core info on how to use & contribute, so we're all on the same page about it -- [ ] Create the initial structure/document tree -- [ ] Ask group leads to dump critical or infrastructure knowledge from their brains or disparate notes into the KB +- [ ] Governance list + - [ ] Create issues + - [ ] Sketch timeline +- [ ] Organization list + - [ ] Draft the core info on how to use & contribute, so we're all on the same page about it + - [ ] Ask group leads to dump critical or infrastructure knowledge from their brains or disparate notes into the KB + - [ ] Scrape the existing GitHub repos and wikis for any project and process information that is relevant to capture in the KB + - [ ] Comb existing Google drives per working group for relevant info to move into the KB + - [ ] Draft initial intents/goals behind long-term elements (such as freshness goals & mechanisms) +- [ ] Technical list + - [ ] Set the site/wiki/whatever up + - [ ] Create the initial structure/document tree + - [ ] Access control (a.k.a. who can edit/update) ## Votes -- GitLab From a168f1be7680ad7ab34851675d36740da7de0eeb Mon Sep 17 00:00:00 2001 From: Ryan Macklin Date: Tue, 13 Dec 2022 22:26:51 +0000 Subject: [PATCH 5/8] Added notes about working groups, need for rollback --- Accepted-RFCs/RFC-012-internal-knowledge-base.md | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/Accepted-RFCs/RFC-012-internal-knowledge-base.md b/Accepted-RFCs/RFC-012-internal-knowledge-base.md index 30a61d5..65858fb 100644 --- a/Accepted-RFCs/RFC-012-internal-knowledge-base.md +++ b/Accepted-RFCs/RFC-012-internal-knowledge-base.md @@ -43,6 +43,15 @@ Ideally, our docs would make use of our templates—in fact, they would make for We'd have a mechanism for checking the freshness of content, though we can defer the details of that until later. That may inculde owners or reviewers listed on individual articles or sections. +### Existing working groups + +This is a community-led sub-project, and doesn't require making a new working group. The various responsibilities would lie in: +* Tech team for technical implementation & maintainance (with RFC author working alongside for implementation) +* Community managers for thorny issues their team tackles in any medium: when there's some abuse, conflict, or other issues +* Individual working groups would maintain their own sections +* Any community member could contribute to help resolve any outdated info, reorganize as needed, etc. + * That also covers "global" documents, as anyone has passion or interest to contribute + ### GitLab wiki: a.k.a. Do we already have this? There's a wiki in GitLab, and [Aaron has release weight information there](https://gitlab.com/tgdp/governance/-/wikis/Guide-to-assigning-weight-scores-to-issues-and-epics-%28release-planning%29). Should we just go with that? Does that make sense for us as a group of groups? @@ -58,6 +67,8 @@ Said information though could become out of date without a contributor realizing We also need to decide on the access control. Having new contributors being able to edit can be great for finding holes in the content, but could also be an issue if contributors put misunderstandings into our KB without others noticing right away. +Related, we need ways to roll back individual pages, to quickly resolve any potential abuse issues or just a passionate but ill-informed community member putting poor information in the KB. + Comment from Tina: "I see this as a blessing and curse as well. Having a stricter format that needs a PR before contributing would prevent these things, I guess." This space would also be great for small procedural elements that should be documented, but don't need a full RFC for said documentation (such as the recent "break/restart" process the co-chairs initiated). That way such info isn't lost to the ether due to a lack of documentation procedure for such things. @@ -129,4 +140,4 @@ Project steering committee (listed alphabetically by first name): Community members who voted (non-binding): -- {Your name}: {Your vote} \ No newline at end of file +- {Your name}: {Your vote} -- GitLab From f8615b981b7f4d386dc07c0ea80d243a12f305af Mon Sep 17 00:00:00 2001 From: Ryan Macklin Date: Tue, 13 Dec 2022 23:16:57 +0000 Subject: [PATCH 6/8] Added "last updated" date in header --- Accepted-RFCs/RFC-012-internal-knowledge-base.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Accepted-RFCs/RFC-012-internal-knowledge-base.md b/Accepted-RFCs/RFC-012-internal-knowledge-base.md index 65858fb..a9adf3a 100644 --- a/Accepted-RFCs/RFC-012-internal-knowledge-base.md +++ b/Accepted-RFCs/RFC-012-internal-knowledge-base.md @@ -3,7 +3,9 @@ Ryan Macklin ([@macklin](https://thegooddocs.slack.com/team/U01DYRWG43X)) -Initially submitted on 24 Aug 2022 +Initially submitted: 24 Aug 2022 + +Last updated: 13 Dec 2022 ## Current status -- GitLab From eec3d6ed4424e58aa0780af54e15f78d5555262e Mon Sep 17 00:00:00 2001 From: Ryan Macklin Date: Wed, 14 Dec 2022 00:00:17 +0000 Subject: [PATCH 7/8] Added RACI chart --- .../RFC-012-internal-knowledge-base.md | 87 ++++++++++++------- 1 file changed, 54 insertions(+), 33 deletions(-) diff --git a/Accepted-RFCs/RFC-012-internal-knowledge-base.md b/Accepted-RFCs/RFC-012-internal-knowledge-base.md index a9adf3a..0626d39 100644 --- a/Accepted-RFCs/RFC-012-internal-knowledge-base.md +++ b/Accepted-RFCs/RFC-012-internal-knowledge-base.md @@ -45,7 +45,19 @@ Ideally, our docs would make use of our templates—in fact, they would make for We'd have a mechanism for checking the freshness of content, though we can defer the details of that until later. That may inculde owners or reviewers listed on individual articles or sections. -### Existing working groups +### Ideal time for release + +We have events for new community members in late January. It'd be rad if we could have something stood up with basic info in place before then, so we can point it out as "it exists and is new" rather than "it's going to exist soon, sorry." + +We don't need a lot to effectively launch this for new community members, just some foundation. + +### Fail fast, fail forward + +We can try a platform, see if it works, and if it doesn't we figure out a new solution (without needing a full RFC) and migrate info over. This is preferrable to debating the merits of various systems without diving into one. + +Since this is a purely internal tool, we aren't creating difficulties with our wider userbase. And any difficulties we create within our org end up being typical growing pains and come with the notion that trying something different is to resolve existing pain points. (Just like how "have a solid, reliable place for info" addresses the current pain point.) + +### Roles, responsibilities & existing working groups This is a community-led sub-project, and doesn't require making a new working group. The various responsibilities would lie in: * Tech team for technical implementation & maintainance (with RFC author working alongside for implementation) @@ -54,6 +66,28 @@ This is a community-led sub-project, and doesn't require making a new working gr * Any community member could contribute to help resolve any outdated info, reorganize as needed, etc. * That also covers "global" documents, as anyone has passion or interest to contribute +Using a [RACI framework](https://www.teamgantt.com/blog/raci-chart-definition-tips-and-example) to draft an initial understanding of roles & responsibilities: +* RACI stands for **R**esponsible, **A**ccountable, **C**onsulted, **I**nformed (using "-" for none), with each letter representing the level of task responsibility on a project + + + + + + + + + + +
Role→
Task↓		RFC authorTech teamCommunity managersWorking groupsGeneral members
Tech1—creationARII-
Tech1—maintenance-RCC-
Access controlCRIII3
Initial info populationRC4C4R2I3
Meta-information
(how to use the KB)		RCCI3I3
Long-term info management
(population, maintenance, deprecation...)		-C5-RC4
Conflict resolution
(abuse, conflicts)		-I6RI6I6
+ +Nuance: +* 1Using "tech" to mean wiki, Hugo sub-site, whatever we go with to start and as time goes on. +* 2Responsible to a lesser extent, as relevant and able +* 3"Informed" here meaning "they'll inherently see the information on the KB itself, with no extra effort to inform necessary" +* 4"Consulted" here meaning "anticipated to contribute to the KB itself" +* 5Only informed or consulted in the case where tech changes or migrations are foreseen or requested +* 6"Informed" here meaning "expect messages in Slack" + ### GitLab wiki: a.k.a. Do we already have this? There's a wiki in GitLab, and [Aaron has release weight information there](https://gitlab.com/tgdp/governance/-/wikis/Guide-to-assigning-weight-scores-to-issues-and-epics-%28release-planning%29). Should we just go with that? Does that make sense for us as a group of groups? @@ -61,6 +95,12 @@ Comment from Aaron: "In my mind the (a) wiki is the place for this type of infor If we use a wiki, can we keep that wiki to being only for KB material? Ideally, we shouldn't have a wiki oversaturated with multiple purposes? Would it be difficult to use search functionality when looking for KB articles, due to non-KB stuff in the wiki also populating the search results? +### What about non-doc/external resources? + +We'll have other resources for the project, such as a Google Slides template for making new presentations (on Ryan's winter to-do list) or future videos for learning git. We'll figure out the best way to handle such situations, but as far as how those situations would fit here, simple: there'd be external links as needed. + +We don't want to external link everything, but where it's key, we do and that's okay. Those links should be clearly marked as external though. + ## Consequences We'd have a central place for information. @@ -101,45 +141,26 @@ If you reject feedback, note that rejected feedback here before resolving the co ## Implementation checklist -If this proposal is accepted, the following tasks must be completed: +If this proposal is accepted, the following tasks must be completed (though not necessarily all completed before initial launch): - [ ] Governance list - - [ ] Create issues - - [ ] Sketch timeline + - [ ] Create issues for all these in GitLab + - [ ] Sketch initial few posts necessary for contributors - [ ] Organization list - - [ ] Draft the core info on how to use & contribute, so we're all on the same page about it - - [ ] Ask group leads to dump critical or infrastructure knowledge from their brains or disparate notes into the KB - - [ ] Scrape the existing GitHub repos and wikis for any project and process information that is relevant to capture in the KB - - [ ] Comb existing Google drives per working group for relevant info to move into the KB - - [ ] Draft initial intents/goals behind long-term elements (such as freshness goals & mechanisms) + - [ ] Draft the core info on how to use & contribute, so we're all on the same page about it* + - [ ] Ask working group leads to dump critical or infrastructure knowledge from their brains or disparate notes into the KB* + - [ ] Scrape the existing GitHub repos and wikis for any project and process information that is relevant to capture in the KB* + - [ ] Comb existing Google drives per working group for relevant info to move into the KB* + - [ ] Draft initial intents/goals behind long-term elements (such as freshness goals & mechanisms)* - [ ] Technical list - [ ] Set the site/wiki/whatever up - - [ ] Create the initial structure/document tree + - [ ] Create the initial structure/document tree+ - [ ] Access control (a.k.a. who can edit/update) +Any marked with an asterisk (*) don't necessarily need to be completed before initial launch. Be great if they were, but in the vein of being nimble, they aren't requirements. -## Votes - -Votes as per our [decision process](https://thegooddocsproject.dev/decisions/): - -Project steering committee (listed alphabetically by first name): - -- Aaron Peters: -- Alyssa Rock: -- Ankita Tripathi: -- Bryan Klein: -- Cameron Shorter: -- Carrie Crowe: -- Erin McKean: -- Deanna Thompson: -- Felicity Brand: -- Gayathri Krishnaswamy: -- Morgan Craft: -- Nelson Guya: -- Ryan Macklin: -- Tina Lüdtke: +Any marked with a plus (+) are explicitly called out as "we'll do our best guess, and adjust over time," to make it clear we aren't trying to get it perfect right away. +## Votes -Community members who voted (non-binding): - -- {Your name}: {Your vote} +Note: Votes are now recorded in the merge request itself. -- GitLab From d9020931124b2022235e9ffa8852e5277bc81c05 Mon Sep 17 00:00:00 2001 From: Ryan Macklin Date: Wed, 14 Dec 2022 00:01:42 +0000 Subject: [PATCH 8/8] Note in decisions deferred --- Accepted-RFCs/RFC-012-internal-knowledge-base.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Accepted-RFCs/RFC-012-internal-knowledge-base.md b/Accepted-RFCs/RFC-012-internal-knowledge-base.md index 0626d39..0879a8b 100644 --- a/Accepted-RFCs/RFC-012-internal-knowledge-base.md +++ b/Accepted-RFCs/RFC-012-internal-knowledge-base.md @@ -127,7 +127,7 @@ This space would also be great for small procedural elements that should be docu ## Decisions deferred -None listed +None listed, but we expect some tasks and decisions to be implemented post-initial launch, and that's okay! ## Feedback -- GitLab