Agenda:
- Decide the rough scope of the team
- Decide how we want to organize the team
- Plan for an official announcement (draft here, but it’s clearly worth improving)
Attendees: @thufschmitt @roberth @fricklerhandwerk
-
@fricklerhandwerk what do we do today if @edolstra does not show up?
(note: it later turned out @edolstra was on vacation and we simply didn’t know)-
@thufschmitt we can still discuss a few things
- he read the proposal and agreed on principle about having the team
- foundation board also approved
- does @roberth have commit access?
- @roberth no, but interested. maybe I’m not the right person.
-
@thufschmitt people who are morally entitled to commit are a different set to those who technically can
- @fricklerhandwerk should be one of the first points on the agenda to align these sets
- we need an actual mandate to eventually merge things autonomously, otherwise none of this makes sense
-
@thufschmitt this is what the proposal is about, @edolstra would have to sign it off so we can get to work
- would have been better for him to be here of course
-
@thufschmitt this is what the proposal is about, @edolstra would have to sign it off so we can get to work
-
@thufschmitt we can still discuss a few things
- @thufschmitt the legitimacy of the team depends on it being official, otherwise it will have no authority to pull through with decisions
- (@tomberek joins)
-
@thufschmitt did you want to join the team @roberth?
- @roberth cannot commit too much time to it though, but very interested in making it successful
Announcement review
- Role of the team
- @fricklerhandwerk: Just “be responsible” is too vague. The role of the team is to enable things to be done, not to do everything
-
@tom “responsible” means both the accountability and the empowerement
- We should have both (see also What are the values that you see being expressed in the NixOS project? - #8 by tomberek)
- don’t want to reinvent the wheel. is there an existing framework we could follow?
-
Linux kernel organization
-
Supported: Someone is actually paid to look after this.
Maintained: Someone actually looks after it.
Odd Fixes: It has a maintainer but they don’t have time to do much other than throw the odd patch in. See below…
Orphan: No current maintainer [but maybe you could take the role as you write your new code].
Obsolete: Old code. Something tagged obsolete generally means it has been replaced by a better system and you should be using that. -
3. Debian Developer's Duties — developers-reference 13.4 documentation.
-
something else we want to model this on?
-
@thufschmitt this is relevant. @ron and me were pushing the foundation board to organize the teams according to some established standards
- this team could be a testbed for that
- not sure Linux is the right thing, interviews with Linux foundation have shown they may be too different for our needs
- Haskell, Rust, Plone were mentioned
- for all of them there is a broad framework outlining what teams can and should do, otherwise they are self-organized
-
-
@thufschmitt another thing that came up in the board discussions is ownership
- owners have the power over something do things with it, and at the same time are accountable
-
@fricklerhandwerk possible homework: go through Debian developer duties page
- @thufschmitt this kind of document we should create once the team is established