add minutes from Nov 4 SC meeting

Author: avivace

website/.vuepress/config.js

@@ -98,6 +98,7 @@ module.exports = {
         children: [
           { link: "/chat", text: "Chat channels" },
           { link: "/contribute", text: "Contribute" },
+          { link: "/meetings", text: "Meetings minutes" },
         ],
       },
       {

website/meetings.md

@@ -0,0 +1,7 @@
+---
+sidebar: false
+---
+
+# Meetings minutes
+
+- [November 4th, 2023](./meetings/2023-11-04-sc.html)

website/meetings/2023-11-04-sc.md

@@ -0,0 +1,97 @@
+---
+sidebar: false
+---
+
+# Steering Committee - November 2023
+
+Written by avivace.
+
+**November 4th, 2023**. 4:00 PM - 6:30 PM CEST. Discord VC.
+
+##### Invited
+
+Moderators, Staff, Experts, Outreach, RGBDS maintainers.
+
+##### Partecipants
+
+PinoBatch, avivace, ISSO, Calindro, Duo, nitro2k01, QuangDX, superdisk, kva64, Sylvie, Sanqui
+
+
+##### About those meetings
+
+Partecipants are asked to fill in discussion points beforehand. The results of these discussions (decisions, suggestions, comments, ..) are reported as the sub items.
+
+Discussion points marked \* were not brought up due to lack of time.
+
+Anyone can reach out in `#meta` on the Discord server to comment/discuss on any of the points reported here.
+
+##### Minutes
+
+-   avivace:
+
+    -   Q to ISSO: RGBDS Rust port plans?
+        -   Scope: Full port from the old codebase, can’t be 1to1
+        -   Architecture design in progress
+        -   Motivation: C not attractive anymore for potential contributors. Showing its age. Technicalities (std::vector). Rust is fancier, more active community.
+        -   (Personal) De-risking/Viability study
+        -   Question from Pino: will this affect availability of binaries?
+    -   Homebrew Hub: developments and expanding to NES \*
+    -   Gbcompo23: [...] \*
+    -   Funding: how to? \*
+    -   Creating the steering committee: Roles? \*
+    -   Q to Sanqui: how to run these meetings? Minutes \*
+
+-   ISSOtm:
+
+    -   Difficulties finding contributors
+        -   Pan Docs, RGBDS, ASM Tutorial are lacking
+        -   AV: Homebrew Hub is OK
+        -   Quality barrier too high? Is our PR review process too much?
+            -   Possible (partial) solution = avoid nitpicking
+            -   Interesting actionable by DUO: give reviews in “steps”, avoid attacking a PR with everything all at once.
+            -   If making follow-up changes separately, be upfront about that in the initial PR to avoid the contributor feeling “the rug pulled under their feet”
+            -   Put a hard cap on the PR’s “TTL” before being merged (e.g. 3 weeks), and avoid minor changes as the deadline looms closer
+        -   How to handle contributors going silent?
+        -   “Better merge something incomplete to beg correction work, rather than drop everything done thus far”
+        -   Promoting a “Bug Day”?
+    -   Moving projects to SourceHut? \*
+
+-   Sanqui:
+
+    -   Overview of Wikidata and the possibility of contributing Homebrew Hub information to Wikidata
+        -   Add Ext ID in the game metadata schema and point it to Wikidata entry. Possibly populate others.
+        -   HHub - cartridges/published games/publishers
+
+-   DUO:
+
+    -   Remarks and compliments on the great state of gbdev.
+    -   Promote PRs that need to be worked on, but also promote work that _has_ been done “for cred” - Start using #feedback again.
+
+-   nitro2k01:
+
+    -   Potentially add long a term solution for the IRC bridge as a point/ responsibility.
+        -   Someone other than @avivace needs to volunteer (=> @nitro2k01) and get SSH access and/or a webhook token to delegate the responsibility of handling the bridge
+    -   Future of the forums \*
+
+-   Kva64:
+
+    -   social media handling — general outline and feedback request
+        -   Not only game releases/showcase content can be shared, but projects themselves may have cool milestones to share
+        -   Allow developers, maintainers… to raise up things that can be promoted, so people helping with social media don’t have to “chase” those. Should those go in #showcase? Should #showcase be split?
+        -   Encourage (PSA?) developers to post in #showcase
+            Move all showcase channels to a separate category, and rename “showcase” to “wip-showcase”?
+            Split #releases into e.g. #releases-games and #releases-tooling
+        -   To discuss in #meta: opt-in/opt-out status of showcase channels. A suggestion: make sharing opt-out in #releases-\*, and opt-in in #wip-showcase
+    -   policy on sharing and promoting commercial projects?
+        -   DUO : do not shy away from promoting them because it’s a motivation to some; however, restrictions should be put to avoid being taken advantage of
+        -   Should the cooldown (if any) should apply per project, per user, ..?
+    -   need for using any newly emerging social media platforms (e.g threads and bluesky)?
+        -   Threads and Bluesky currently have very little reach, so maybe not
+        -   Other platforms (e.g. Instagram): maybe, but this may require more people to handle them
+        -   Creating a channel to coordinate them
+
+-   Sylvie:
+    -   Q to ISSO: Continue improving existing C++ while Rust progresses?
+        -   C to C++ in parallel
+        -   Talk separately (and later) about whether we want to upstream the port, and if yes, the roadmap (responsibility & task distribution, etc.)
+