03/03: doc: guix-days-2024: Add notes from the plenary and governance sessions.

[Ludovic Courtès]

civodul pushed a commit to branch master
in repository maintenance.

commit 12a5d469852a008c314c5f30d17ce60f5a954325
Author: Ludovic Courtès <ludo@gnu.org>
AuthorDate: Sun Feb 4 00:52:51 2024 +0100

    doc: guix-days-2024: Add notes from the plenary and governance sessions.
    
    * doc/guix-days-2024/governance.org,
    doc/guix-days-2024/plenary.org: New files.
---
 doc/guix-days-2024/governance.org | 144 ++++++++++++++++++++++++++++++++++++++
 doc/guix-days-2024/plenary.org    |  48 +++++++++++++
 2 files changed, 192 insertions(+)

diff --git a/doc/guix-days-2024/governance.org 
b/doc/guix-days-2024/governance.org
new file mode 100644
index 0000000..d9eda59
--- /dev/null
+++ b/doc/guix-days-2024/governance.org
@@ -0,0 +1,144 @@
+#+TITLE: Notes from the Guix Days session on governance
+#+DATE: Friday, Feb. 2nd, 2024
+
+  - what’s governance
+    - “unfun” stuff, “commit access”
+  - what does being a maintainer mean (Efraim answers)
+    - missions: “people stuff”
+    - keep everyone participating happy enough
+    - not losing contributors
+    - keeping infrastructure working well
+    - discussions among maintainers: Jitsi meetings a couple of times a
+      year (there used to be notes of those meeting in maintenance.git)
+    - code of conduct enforcement
+    - don’t worry about the money, work with Guix Foundation
+    - “this is reactive; what’s happening in proactive terms?”
+  - RFC process
+    - process to document the process
+    - “lack of structure is refreshing sometimes but it can help to have
+      nucleation sites”
+    - hard to contribute when there is no structure
+    - “as co-maintainer, it felt overwhelming to not have any structure
+      to direct people to”
+    - Debian is a good example
+      - DFSG
+    - [[https://issues.guix.gnu.org/66844][Simon’s RFC process proposal]] 
inspired by Haskell’s
+    - examples where it could help
+      - document the maintainer role and expectations (extension of the
+        
[[https://guix.gnu.org/blog/2019/gnu-guix-maintainer-collective-expands/][2019 
blog post]])
+      - document the release process, teams
+      - how we merge branches
+      - question: how could an RFC process help with these?
+      - important project-wide decisions may need to be discussed in a
+       way other than through patch review
+      - core changes to the API or CLI
+      - see “why wasn’t I consulted?” talk (Rust)
+      - more examples: how do decide which organizations to affiliate
+        with? do we run a fundraising campaign and what for? how do we
+        spend money? what infrastructure does the project want to run?
+        who gets on the spending committee?
+    - RFC process as a transparency record
+    - there could be a separate manual describing the organizational
+      structure of the project
+    - we should not concentrate power in the hands of maintainers and
+      spending committee; they may lack legitimization
+    - “has to be a democracy with an elected board”
+    - “we need to keep the consensus model at the heart, we don’t
+      necessarily need a voting process”
+    - question: “we as a community want to make decisions, but who is
+      /we/?”
+      - if there’s a “random person” that comes to the mailing list,
+        should we overrule that?
+      - non-code contributors should have a say
+    - *sociocracy*
+      - organize things as a “federation” in terms of “circles” (teams)
+        with a mission/mandate
+      - but no single circle “rules them all”
+      - the circles are all related
+      - decisions are made notion of consent (“I don’t have any
+        compelling objection to this”)
+      - goal: becoming aware of all the needs of all the circles, and
+        build a solution collectively
+      - this process can be run distributedly
+      - it is formalized and defined
+      - “Spritely for democracy”
+      - there’s explicit membership in circles, and it changes
+        dynamically
+      - dunno if used by other software projects
+      - representative democracy at the level of the circle network
+      - example circles:
+       - funding
+      - everyone who feels sufficiently represented is part of “we”
+      - example: HPC people have no group representing their interests,
+        they may not feel entitled to chime in
+      - someone is always part of two circles (the primary one and the
+        one it’s in)
+      - provisions against infiltration?
+       - no; basic assumption: we all mean well
+      - example from Extinction Rebellion
+       - roles in a circle rotate regularly
+       - vouching processes to avoid infiltration
+      - example: HPC people could “subvert” the project because they
+        don’t care about user freedom
+       - solution: the values of the HPC circle would conflict with
+          those of the other circles
+    - right now there *is* a structure, you just don’t know about it:
+      you have to find out who is on IRC, who has commit rights, someone
+      one doesn’t feel entitled to make their voice heard
+    - to go to sociocracy, we would need to make the connections between
+      circles—e.g., spending committee & sysadmin
+    - would be useful to learn from Debian
+      - capture the mission and shared values
+      - example of Ubuntu could happen to Guix: we should acknowledge
+        that things will be built upon it
+    - probably start with a constitution
+      - example: the [[https://gnu.tools/en/documents/social-contract/][GNU 
Assembly social contract]]
+    - how do we go from here?
+      - propose concrete circles (as opposed to ask “what should the
+        circles be?”)
+      - RFC process not related to circles?
+      - RFC process used to bootstrap other processes
+      - feedback from the Nix community
+       - legitimize processes by participation
+       - it could backfire if processes are only followed by key people
+          who have time and energy
+       - figure out and balance why people are joining a team
+       - how do you give people authority and responsibility?
+       - serious mistakes that were made
+         - people might explicitly not want more structure
+         - adding more structure may seem like you’re excluding people
+            who for ex. don’t want regular meetings
+         - make sure those people’s need are being meant
+       - early on in Nix, de facto but unwritten power structure
+         - people de facto in power tried to override the RFC process
+         - figure out beforehand what to do if people in a position of
+            power decide to dismiss/overrule the process being set up
+      - importance of communication not just with asynchronous on-line
+        media; experience from a standardization process
+       - regular voice/video calls, occasionally face-to-face meetings
+       - currently no effort to get regular meetings (“heartbeat”) in
+          Guix
+       - important to keep group cohesion
+       - write down what’s been discussed
+       - always someone taking notes, ideally rotating
+       - immediately publish it so there’s a record
+       - summarize resolutions, explicitly mark decisions that were made
+       - example: in W3C-based standards group is scribed, there’s a
+          queue so people get a chance to speak, there’s a meeting
+          facilitator and agenda, proposals and resolutions and clearly
+          marked, people vote with +1/0/-1/+0/-0
+      - we don’t need to drop any of the current communication
+        mechanisms—e.g., we’ll keep the chaotic patch tracker
+      - currently we’re “do-ocracy” where people with commit access can
+        do things, like in Debian
+       - run by people stepping up to do the work
+       - we are not going to be able to drop the doocracy nature of
+          this project
+       - Debian has both structure and doocracy
+       - do-ocracy automatically selects people who have time, which is
+          bad for diversity
+       - do-ocracy is built into the model of consensus
+       - regarding consensus: veto is not a solution
+       - be aware of power structures outside the organization so they
+          do not reproduce inside the organization
+
diff --git a/doc/guix-days-2024/plenary.org b/doc/guix-days-2024/plenary.org
new file mode 100644
index 0000000..3ff1513
--- /dev/null
+++ b/doc/guix-days-2024/plenary.org
@@ -0,0 +1,48 @@
+#+TITLE: Notes from the Guix Days plenary session
+#+DATE: Thursday, Feb. 1st, 2024
+
+* status update (Efraim)                                            :plenary:
+
+  - last release 1 year old
+  - installer
+    - working okay
+    - does not cater to the needs of power users (e.g., btrfs on encrypted)
+    - problems when choosing EXWM
+    - allow choosing the Hurd?
+  - substitute availability is good for x86_64
+    - currently 98% or so
+    - qa.guix gives a summary
+    - 32-bit support is in a poor state
+    - idea: estimate i686 substitute usage using server logs?
+    - is ARMv7 (32-bit, armhf-linux) used at all?
+  - onboarding
+    - "not a lot of projects are doing email patches"
+    - people maintain their own stack of patches they don't submit
+    - "we need to do something on our side"
+  - teams
+    - "nice but not perfect", "mostly working"
+    - what about patches with no associated teams?
+    - Rust team is just Efraim
+  - sysadmin
+    - small bus factor
+    - Chris in charge qa.guix, data.guix, etc.
+    - berlin was building slowly early January: needed to vacuum the
+      posgresql database
+  - we're moving faster
+    - #5 on Repology
+    - we should talk more about package availability
+  - time traps
+    - "virtual build machine" service to address that
+    - could be used for 2038 bug testing
+    - RISC-V builds broke with some kernel update
+  - SWH
+
+* Quality assurance, QA (Chris Baines)                              :plenary:
+
+  - architecture diagram
+  - entry points: https://qa.guix.gnu.org/patches,
+    https://qa.guix.gnu.org/reproducible-builds
+  - question about “slowness” of builds
+    - could use a different prioritirization method
+    - could add more hardware
+    - https://bordeaux.guix.gnu.org/activity -> it’s busy :-)