Attendees
| Team | Name/handle |
|---|---|
| Foundation board | @thufschmitt @ron |
| Security | |
| Infra | @delroth @Julienmalka |
| NixOS release | |
| NixCon | @Janik |
| RFC steering committee | |
| Marketing | @garbas |
| Moderation | |
| Nix team | @thufschmitt |
| Documentation | @fricklerhandwerk |
| Nixpkgs architecture | |
| Nixpkgs | @raitobezarius (15 mn late) |
| Geospatial |
Agenda
- Proposal for project maturity levels (@fricklerhandwerk)
- Hydra: propose the repo to be not user-facing (@raitobezarius)
- Follow-up on the teams transparency (@thufschmitt)
- Making this group more official? (@thufschmitt)
Proposal for project maturity levels
- Problem: Beginners have a hard time to evaluate what they can rely on in the Nix ecosystem, while stability and maturity is one of the major reasons to choose Nix.
- Goal: Significantly reduce the cognitive overhead for new and existing users when choosing Nix-related tools
- Prior art:
- Proposal:
- Make something like Thoughtworks’ technology radar
- Proposed degrees of maturity and relevance:
-
- Ecosystem
- Maturity:
- Can be run or set up with one command using Nix
- Project is alive
- Relevance:
- Supports a well-known use case
- Community
- Maturity:
- Has at least one active maintainer
- Contributions are accepted regularly
- Can be used without reading the source code
- Relevance:
- Supports a common use case
- Official
- Maturity:
- Is maintained by a community team
- Relevance:
- Supports an essential use case
- Notes:
- Higher degrees include lower degrees
- Criteria deliberately leave room to interpretation and refinement
- Community team leads should set up a decision-making scheme (e.g. majority vote) and regularly revise the list (e.g. every 6 months)
Discussion
-
@thufschmitt: agree on the big picture; decisionmaking is the crucial point
- @fricklerhandwerk: this team could decide things; from experience all that’s needed is someone to drive the process, make proposals, implement change requests
- @garbas: add to that that anyone should be able to make proposals, e.g. in an issue
-
@garbas: what we should add to the metrics is what we’d expect from maintainers. or should there even be obligations?
- @fricklerhandwerk: the criteria already give an idea of that, and supposedly we should start evaluating based on that and refine as we go
- @delroth: yes, if the same group of people makes the decisions, they should converge on something consistent. don’t need to be exact up front
-
@garbas: should still be clear what it entails to have an official project, what to expect. is it more work, more visibility?
-
@delroth: and what do you get out of it?
-
@garbas: one thing could be eligibility for funding, etc.
- also mention on the website or other visible places
- @thufschmitt: having a project under the NixOS GitHub org should already signal higher trustworthyness than random other things
-
@garbas: one thing could be eligibility for funding, etc.
-
@delroth: and what do you get out of it?
- @thufschmitt: linking back to the NixOps4 discussion with @roberth as an example, a community-blessed project can be expected not to operate like an individual’s project, where there will be some sharing of responsibilities. it’s improtant to set expectations in that regard
-
@delroth: taking a step back, having official projects also matters because official projects “block” development of alternatives that address the same use cases
- @fricklerhandwerk: saying that particular problem areas have no canonical solution would also help, because currently much of that is simply up in the air
- @garbas: would expect consolidation of alternatives given the proposed curation happens
-
@delroth: expect that setting up a bunch of criteria may produce no official projects in the end
-
@fricklerhandwerk: that’s unlikely but would be fine; the purpose is to be honest about the situation
- at least we’d know what to fix first
-
@fricklerhandwerk: that’s unlikely but would be fine; the purpose is to be honest about the situation
- @fricklerhandwerk: probably missing from the proposal is allocating a fixed amount of resources. if we do it in this group, we’d need to say how much time we spend regularly to achieve some measurable goal in a pre-determined amount of time
-
@raitobezarius: agreed on having nix-community as a staging area
- question on moderation issues: there was a recent PR to awesome-nix by a banned user that was reverted
- should nix-community align with moderation decisions? since we’re tying nix-community to the “official” brand
- asked @zimbatm about it, but no answer yet
- it’s important because nix-community is quite big and semi-official already
-
@thufschmitt: would be ideal if we can get alignment
- @raitobezarius: ideally we’d be able to tell people to go to nix-community first and then graduate to official as their work matures
- @fricklerhandwerk: no owners here today, should discuss this together
-
@delroth: there will probably be more action items for full alignment
- e.g. nix-community has their own funding and infra
- @fricklerhandwerk: the problem is not that they’re independent entities, but whether we clearly say that it’s supposed to be that way or not
- question on moderation issues: there was a recent PR to awesome-nix by a banned user that was reverted
-
@janik: this team should probably not make the decisions because it will take too much time from the group
- it’s also somewhat unrelated to what we’re trying to do here
- teams can be asked for advice, but not run that process
- anyone should be able to make proposals though
- can run a call for action to have someone drive it
- @fricklerhandwerk: and then this group can delegate the responsibility and back that person up
-
@raitobezarius: we could invite leads of projects that have potential to become official
- People affected by the change should drive this
- Home Manager comes to mind
- Could have proposals that will be accepted after a timeout when there are no objections
- @thufschmitt: it will be easy for promoting, but hard from demoting
- decision:
- we agree on the spirit of the proposal, but need to talk to nix-community owners
- @thufschmitt will talk with @zimbatm
- @fricklerhandwerk will post a call to action to find candidates to take the responsibility
- we agree on the spirit of the proposal, but need to talk to nix-community owners
Hydra: propose the repo to be not user-facing
-
@raitobezarius: the infra team has needs towards the repo that are hard to implement
- there is no maintenance going on
- maybe we should have internal fork that will serve hydra.nixos.org?
-
@delroth: @zimbatm gave the infra team full access to the repo now
- we can deal with our needs, but we don’t have visibility into external use cases
-
@raitobezarius: if we demote Hydra, how do we advertise to users that it’s dead?
- @thufschmitt: Hydra has a slightly bigger problem as opposed to NixOps, because more big-time users likely depend on it
-
@raitobezarius: if there are big internal deployments by companies that did not give back, arguably we don’t have to care about continued support
- such orgs are free to form a consortium to support Hydra development, but we currently don’t see them participating in the community
- decision:
-
@raitobezarius will provide communication on the
READMEand on Discourse about the state of maintenance- make recommendations for alternatives
- @delroth will merge the PRs
- let the infra team do what they need on some other branch
-
@raitobezarius will provide communication on the
Follow-up on the teams transparency
- Teams handbook - HedgeDoc
-
@thufschmitt will open a PR to nixos.org on the teams overview page
- will discuss async there
Making this group more official?
-
@thufschmitt: should document what we’re doing in a more structured fashion so people know. ideas?
- @fricklerhandwerk: just follow the proposed team handbook maybe?
- @delroth: this doesn’t feel team-shaped but rather assembly-shaped
- @garbas: this is a meta team; having a team would imply being part of this higher-kinded team
- no conclusion; ran out of time