2024-04-29 – Lix Release Bootstrapping

Agenda

Prohibited items:

• Nix foundation politics, for everyone's safety

Core Agenda:

• Figure out an initial governance model we can use to bootstrap governance later
• Figure out how to do a soft release
• Figure out anything that needs to be done before this release

Other suggested agenda items:

• What to use for our contribution policy in the interim.
  • Raito going to come up with contributor doc, asking others for help.
• What to use for code-of-conduct community standard in the interim.
  • Jade going to either come up with community standards or make it happen otherwise.
• Contributor License Agreement T_T_T_T
  • None (thank goodness)

People

hexchen, Irenes, Irides, jade, ktemkin, puck, Osiria, Raito

Decisions made

• Bootstrap governance is made via:
  • Consensus first
  • 3/4 of bodies is quorum for non-governance decisions, otherwise it's the full set of bodies
  • 2/3 of the quorum number of bodies for a vote to succeed
  • Anyone can call for a vote at any time, including after a decision was made, except if a decision has been binding
  • Decisions can be binding or not, if they are not binding, they can be relitigated
  • Binding decisions are governance decisions
  • Focused on social governance but technical matters are a special case of social governance in the current model
  • Consult the governance before speaking on project's behalf for controversial topics
  • Delegation and on-the-spot decisions should be used carefully and consensus should be obtained back as soon as possible after such a thing is done

put here for edit history reasons https://gist.github.com/RaitoBezarius/e8509c1bdae2980031e9630de4b6d69e

• We should accept PRs, from day one of soft launch, regardless of tooling status
  • "We do accept them, we will make it work."
  • If it gets bad we'll yoink the Go tooling

Action Items

• Write trivial community standards.
  • Write CoC that says "everyone is expected to follow community standards"
  • See governance pad thing with the general ideas. Want to write down principles of what we expect in the community.
  • jade owns this and causes it to happen
• Do something about continuous open beta
  • jade owns this and will make sure it doesn't get forgotten

Notes

Meeting starts at roughly 20:10 UTC

Governance Model

• irenes: how to avoid power structures being created by most jurisdictions forcing power structures for creating an entity. We would need an entity for money reasons due to infrastructure and needing to give people money
  • need to have an agreement on what we stand for overall
  • this is more of a consideration for the future
• kate suggestion: interim hypothesis: simple majority (of the core team list)

  • jade: constituency: people like Gabriella who are there for historical reasons but are not significant contributors

  • hexchen: 2/3 majority?

    • kate: ranked choice, or consensensus, approval voting also possible

  • puck: 50/50 split can happen, which can be a problem for simple majority

  • hexchen: for day to day decisions, 50% is good enough, higher level of agreement required to mess with governance

  • irides: consensus with majority vote to break ties?

  • kate: what is a quorum?

  • kate: if we can reach consensus on decisions, we can avoid doing things that people don't want/avoid using the voting system

  • kate: day to day vs governance decisions: what is a day to day decision? or we can treat every decision as governance decision

    • jade: what is a decision?
      • kate: some decisions are binding, some are made ad hoc. cannot rely on vibes to know when there might be disagreement

  • hexchen: supports consensus for bootstrap but we do need a tiebreaker (2/3 reasonable)

  • jade: should probably revert first in cases where things should need more discussion?

    • kate: stuff like potential security issues mean that revert-first doesn't work necessarily always
    • qyriad: revert-first favours the status quo
    • jade: this is kind of what we are doing

  • hexchen: there is a difference between social and technical decisions, should focus to do social decisions in our governance model first. technical governance inflates the agenda for the meeting.

  • raito: re revert first, consider a compromise: suspend people from involving themselves in a thing, for a period of time if things get heated?

  • hexchen: re lazy consensus: make snap decisions, reëstablish consensus afterwards. we would prefer to not have to make such decisions, but if they are made, we should try to get consensus after they are made

  • kate: use common sense, especially re speaking for the project. don't go around loudly speaking on the project's behalf without some consensus

  • kate: what is the quorum? is the threshold of the quorum?

    • hexchen: possibility (remote for us) of excluding people maliciously and still forming quorum
    • kate: anyone outside the quorum can call revote?
      • jade: time bounds of revote?
    • puck: nixos foundation bylaws include some mechanisms to avoid quora being formed maliciously
      • some ways to deal with long term absentees

  • kate: we want to make governance decisions in terms of actually making a real governance with the entire group of people. the entire group should be involved in the final governance making. everyone on the core team list should sign the final thing or so.

    two stage vote thing: vote initially and then everyone can change to be unanimous at the end as an explicit approval

  • qyriad: concrete numbers: 2/3 is 7/10 bodies. 3/4 is 8/10.

    • kate: 3/4 for quorum, 2/3 for vote? everyone there -> binding decision, not relitigible
    • kate: something that is not relitigible is considered a governance decision, and thus requires a full quorum

summary by qyriad: generally try for consensus. when things have to be put to a vote, 3/4 is quorum, 2/3 of participants for vote. for governance quorum is everyone that can be reached. votes are done, for example, for decisions that either are expected to need agreement, or after the decision if agreement was necessary; also things that are project direction.

• irides: things that are votable but are not necessarily controversial.
• hexchen: how too moderation? generally want to reëstablish consensus after such decisions are made.
  • first put it on wiki then talk about it. kate: this is just a social expectation, does not necessarily need to be codified
• kate: need to write coc; general framework is using judgement based on safety of the community.
• raito: how does ownership of topics work? avoid cases of people doing diverging snap decisions on things outside their region
  • hexchen: delegating topics is something we need to do but not worry about ownership for bootstrap governance. delegate discussion space for certain things: e.g. ensure that discussions about things are in set places so that people see it.
  • irenes: consider how delegation is a hierarchical thing and avoid doing it immediately

Moving on to the soft release

• hexchen: I would simply drop a link on social media and let the everything spread!

  • Kate: just telling people in social circles and social media (save for Irenes and Kate) is probably good for a soft release

• Kate: Oh right we need to do binary cache for substituting Lix

• hexchen: are we still going to be reaching out to the Nix/Tvix/Guix developers a few days beforehand?

  • Kate: Nix kind of already got their notice
  • Raito: Most of the Tvix members already know about Lix
  • Kate: the soft release also kind of is notice for the hard release
    • But we can also send the Guix devs an email or something
    • Irides: why are we doing this in the first place?
    • jade: for security reasons! Nix's security response stuff has historically been disasterious
    • Raito: we share componenets in our codebases with Guix, so it makes sense to communicate in general

• hexchen: should we be PRing Lix to Nixpkgs for soft release?

  • Kate: we probably shouldn't touch Nixpkgs until the Foundation stuff stops exploding

• hexchen: I would really like to avoid making Lixpkgs a thing

  • Osiria: gods we would really like this too

• we want to reach out to the guix project

  • raito: should we reach out to the guix lead
  • general agreement to just reach out to them politely to say that we exist

• jake hamilton: decided not to disclose to him

• puck: maybe we should just tell Guix at the same time as the soft release?

  • jade: doing it ahead of time is a show of good faith

• raito: re jake hamilton: their fork is a "we are trying to do this", don't think they have the relevant skills/insider stuff to really get far soon

  • jade: doesn't really see any advantage to disclosing early
  • kate: we're going to be out so soon anyway
  • kate: also doesn't really see a downside to disclosing to them ¯\_(ツ)_/¯

• hexchen: meow

  • maybe now is a good time to do a short couple-minute break

• reconvene at 21:25 UTC

• hexchen: how do we want to deal with expanding the core team?

  • should we continue the freeze?
  • Osiria: yes, we absolutely should continue the freeze
  • jade: the bootstrap model has loopholes that are exploitable. anyone to be onboarded would have to be deeply trusted
  • Kate: after we open up the "core team" distinction will likely break down as we do things more out in the open
  • jade: a lot of stuff lands in the core chat either because it's sensitive, or because Matrix is kind of bad, which actually really sucks
    • Having a less bad chat platform enables things more

Code of Conduct Community Standard

• Kate: stuff on the wiki will probably be what we adopt long-term
  • In the meantime we should adopt something in the interm
  • Irides: maybe we should adopt something that just expresses intent instead of a traditional code of conduct
  • Kate: that's kind of a code of conduct with more steps — if someone has the time/spoons to write something up feel free
  • Raito: the team composition also kind of signals some degree of intent implicitly
  • Kate: code of conduct or not we're kicking out nazis and that expresses intent too
  • jade: coc explicitly a bad term
  • Irenes: if someone actually tries to call us out for no CoC yet we just point out that we actually have a functioning governance model and we're taking the time needed to figure out CoC stuff
  • hexchen: should we just do contributor covenant?
  • Irides & jade: that document would actually be a detriment
  • Kate: re: CoC vs CS: we just put a code of conduct that says "follow the community standards"
• Kate and jade both offered to do writing stuff
• How about jade takes ownership of the thing, and go ahead and probably write it, but if she doesn't/can't/etc then she can poke Kate who will write it
• hexchen: should we subscribe to NixOS's Matrix banlist?
  • Kate: pulling it in, sure, subscribing, probably not
  • jade: we can follow first and review after, or review first and follow after
  • Kate: we can also just follow their moderation decision repo
  • hexchen: draupnir can send a message when the banlist updates. or we can just have someone in the banlist room and action it

Contributing Policy

• Kate: this should be liftable from somewhere?
  • jade + Irides: what is a contributing policy?
  • Kate: it's the set of expectations we have for contributors
• We already have some stuff on the wiki
  • jade: Should do some crosslinking between CONTRIBUTING.md and the wiki
  • jade: Maybe find a user to experiment on
• Irides: a lot of contributor documentation is not very good
  • Raito: nixpkgs mood
  • We should have good onboarding process documentation
  • puck: we may be conflating "how to use our tooling" and "what kind of contributions are we accepting"
    • External contributors should probably be aware that we're not generally making large changes right now
    • Irides: the wiki already has a document on that
    • jade: ideally before you write a single line of code you should know this information
    • Osiria & jade: a clone/devShell/pre-commit hook that informs the user of our freeze-state
    • Raito & Irides: this is largely a social problem
    • jade: can we put the contributing channel in the devshell hook or something?
      • osiria & irenes: explicitly say "we want to talk to you", link to the channel
      • puck: put CL push webhook into a room maybe? not necessarily now. generates sense of activity
      • kate: specific dedicated channel for "prospective contributors/feedback"
      • puck: concerned about discussion fragmentation with many channels
      • jade: maybe like… a threadbot? that makes temporary channels because Matrix threads suck?
      • puck: more projects we need =P
      • Kate: I would simply make Zulip have a good UI
  • jade: how do we MAKE people read the "freeze policy" or so
  • jade: should there be synchronization between contributing document and the wiki (probably with repo as source of truth)?
  • Osiria: noting: what should the wiki/forgejo/gerrit permissions be for new logged-in-with-github users?
• jade: if the contribution document just links to the wiki, you force people to go the wiki
  • if it has a bunch of links to the wiki, no one will read the links
  • maybe should just be a summary
  • kate: "ask first, we will help you, here is where to ask"
• jade: noting: do something about the github pr bot thing, or set up a manual process in the interim
• jade: what should we do about github PRs?
  • Thinks we should accept PRs, from day one of soft launch, regardless of tooling status
    • "We do accept them, we will make it work."
    • If it gets bad we'll yoink the Go tooling
• Kate: if we're going to do governance stuff on git, there we should probably sign our commits
  • jade: aggressively sighs and concurs
• Osiria: permissions for soft launch?
  • Kate: for soft launch, signin w/ Github is disabled for the public
    • jade: we really really want to have the majority of accounts especially from people we don't trust be from github due to being harder to make socks on it
  • Kate: or we could do local accounts
  • jade + Osiria: that breaks bans and is SSO-messy
  • Kate: deferred, put it on the soft release board
• Kate: CLAs suck and we're stuck with LGPL forever?
  • Irides: throw MIT license and Apache license in there, and future contributions are licensed under all three licenses, allowing us to eventually migrate
  • Kate: that doesn't really work since there's all the existing licensed code
  • Irides: MIT and Apache are LGPL-compatible
    • Really would not like to be confinded to LGPL forever
    • We already have in-tree mixed licensing
  • Kate: we can't do that for anything that touches LGPL code
  • Osiria: defer to asynchronous
• Decision: no CLA
• Raito: why a permissive license anyway?
  • Irides: deferred to asynchronous
• Irides: we cannot possibly do worse than Nix at this point.
  • jade: that fact that we're doing any of this is already a major improvement

• Raito: how do we transition from beta to soft release? what do we do with the beta rooms?

  • we just leave them
  • jade: these are people we generally trust, and who are politically all on the same page. we must continue to have this space exist, and also not grow it
  • Raito: we need to address the fact that people want to add people
  • jade: not opposed to growing them, just opposed to growing them to people who don't meet the same demographics as the ones who are in there
  • Kate: try not to stray too far into politicking for now

• jade: all the people in the beta are running main, and that's good actually, and if we could get more people to run main that would be awesome

  • great for feedback
  • maybe even have a channel for "I'm running main", and have a permanent open beta
  • Kate: sounds good! make an issue :)

• irides: how should we do linking to scratch?

  • kate: can put sso on it possibly
  • jade: the link can be shared to more people

Bootstrap meeting complete! Well done everyone ♡

Roughly 22:25 UTC, meeting end