[14:03:54] Meeting started by _ikke_ [14:04:03] Current subject: Roll Call, (set by _ikke_) [14:04:09] here [14:04:13] here [14:04:24] INFO: Present: SpaceToast danieli fcolista _ikke_ [14:04:53] <_ikke_> Anyone else? [14:05:47] <_ikke_> So just 4 of use it appears [14:05:54] it unfortunately looks like it [14:05:57] notably absent are ncopa and clandmeter, but that was mostly expected; less notably absent is ddevault, who was interested in discussing python-related business [14:06:25] what's the agenda [14:06:26] ? [14:06:28] still, with ncopa's recent comments on the ML, I think we can safely continue even with this low number, and try to get a decent draft to then start implementing (post-approval) [14:06:45] fcolista: https://brpaste.xyz/y4fTUg?asciidoc - organizing alpine based on "teams" (ala Gentoo projects) [14:07:00] thx SpaceToast [14:07:08] Current subject: Goal of the meeting, (set by _ikke_) [14:07:09] goal is to separate tasks (minimize context-switching, maximize effectiveness), make it easier to join the project, and take the load off the core team [14:07:26] yes I saw that topic in ML [14:07:36] <_ikke_> There are 2 draft proposals [14:07:41] so we're going to discuss various details as to the implementation (as it seems most are in favor of the general idea) [14:08:06] k [14:08:23] LINK: https://docs.google.com/document/d/1TIGk24yLdoAC-JAH7IQzCAkxzX_YocUiHVbeSt-WZsk [DRAFT - Alpine Linux SIGs - Google Docs] [14:08:30] LINK: https://p.toastin.space/F7MDfw?asciidoc [Burning Rubber Paste] [14:08:42] INFO: agenda: https://brpaste.xyz/y4fTUg?asciidoc [14:09:04] the 2 proposals are danieli's and mine; however after talking it over, we agreed that mine is fine as well, and mine is the one that ncopa seems to have based his recent suggestion (re: implementing asap) about [14:09:28] as such, I propose basing the further details on the concept of "teams", rather than special interest groups [14:09:33] is anyone opposed? [14:09:37] <_ikke_> My first concern is, do we expect defining teams will automatically help getting more work done? [14:10:08] <_ikke_> SpaceToast: Yes, I like teams better then SIGs, more inline with what Alpine already uses [14:10:13] agreed [14:10:15] no, if every defined team has the same members this will obviously not have any effect [14:10:28] I expect the following two things to happen in a correct implementation: [14:10:41] 1. people are not part of all teams - this lets them focus on tasks related to the team that they *are* in [14:10:54] for example, if ncopa is not in the infra team, he no longer needs to worry about the infrastructure [14:11:07] this means less context switching, which *does* demonstrably increase individual productivity [14:11:19] 2. teams are easier to join than the core team (current state of affairs) [14:11:24] <_ikke_> That kind-of already is the case, though, because he's the maintainer of the entire project, he is still concerned in it somewhot [14:11:26] <_ikke_> somewhat* [14:11:47] you need to be a known contributor, and get approval from the specific team leader, rather than the somewhat convoluted current process [14:11:58] more people with access = more people to manage the load (e.g number of patches) [14:12:12] <_ikke_> Right, imho that's the main concern here [14:12:23] +1 _ikke_ [14:12:29] 1 is quite important too - as per ncopa's ML listing, he wishes to be less of a bottleneck in "every process" [14:12:54] <_ikke_> Agreed, and I fill concerning infra for example that's already the case [14:13:00] <_ikke_> s/fill/feel/ [14:13:03] fair enough :) [14:13:23] <_ikke_> But that does not mean it does not need to happen for other things as well [14:13:30] yes. [14:13:34] so in order for our implementation to be a success, it must allow for easy separation of tasks, and flexibly joining the project [14:13:52] a clear organizational structure would most likely entice 'outsiders' (interested third parties) to contribute as well [14:13:54] <_ikke_> And as a correlation, making it easier to have 'partial' access [14:13:57] I believe that the team proposal makes that easier (e.g through separated governance) [14:14:03] danieli: +1 [14:14:07] _ikke_: +1 [14:14:17] can we abbreviate the above in .infos? [14:14:23] <_ikke_> Yes, hold on [14:15:36] INFO: Teams help with delegating work. This does require people to be available and get the necessary permissions to do their work [14:16:02] INFO: It's also easier for people to join specific subteams [14:16:36] good sum-up [14:16:44] and, as danieli said, it helps provide a specific structure that helps outsiders "understand" us :) [14:17:01] INFO: Teams give more transparency to how the work is divided [14:17:07] ++ [14:17:50] INFO: Question: how can we properly delegate access to specific systems? [14:18:08] <_ikke_> For example, take aports [14:18:17] software systems (applications) or hosts, in this case? [14:18:28] <_ikke_> The most practical granularity is is the repo folder [14:18:35] Aports right now isn't structured very well for this purpose, I agree [14:18:37] <_ikke_> main / community / testing [14:18:57] What I think may be done in the future is having more repositories (e.g add python, rust, dlang, and so on); but this isn't the subject of today [14:19:15] I suggest that, until further notice, ports-specific teams shall be supervised by the main aports team [14:19:29] <_ikke_> Right, the specific implementation is a separate matter, but it does have consequences of what we are able to do [14:20:22] I think giving subteams full access is fine - if they do something bad, it can be reverted by a supervisory team, and the misbehaving member removed from the access list (or given a warning, or whatever the supervisory team deems correct) [14:21:24] Current subject: Current team structure, (set by _ikke_) [14:21:45] ncopa already mentioned a few existing teams - infrastructure and documentation [14:21:54] he forgot about "core", which I think we should define as well [14:21:55] <_ikke_> Formally there are 3 teams [14:22:00] are there any other already existing teams? [14:22:22] loosely, we currently have the core developers, infrastructure team, an one-person documentation team of sorts, and a security team (?) I have very little insight into [14:22:29] <_ikke_> 1. Core, 2. Infrastructure, 3. Developers [14:22:41] <_ikke_> The rest is more ad-hoc [14:22:42] yeah, those are the ones we have listed on our internal wiki [14:22:54] there security team too, _ikke_ [14:22:58] what is the "Developers" team about? [14:23:04] INFO: Current documented teams: 1. Core, 2. Infrastructure, 3. Developers [14:23:09] perhaps we should delegate them to the aports team for simplicity? [14:23:11] there is a security team, but I'm not sure who's in it or how it functions at the moment [14:23:12] <_ikke_> SpaceToast: People with aports access [14:23:18] push access*? [14:23:19] <_ikke_> fcolista: right, that team is not really documented [14:23:22] ok, so we will call them the aports team, if anyone doesn't mind [14:23:33] packaging team? [14:23:39] packaging/packages [14:23:43] basically are ppl who takes care of CVE [14:23:47] there was also talk of a releng team by ncopa, but I'm not sure that went anywhere [14:23:58] <_ikke_> not a lot of response [14:24:06] releng ? [14:24:09] release engineering [14:24:10] <_ikke_> Release engineering [14:24:24] ah ok [14:24:43] <_ikke_> An example where creating a team is not automatically getting members [14:24:51] two questions: 1) which teams do we need to implement for now, and who will be the respective leaders? as far as I see, we *need* to implement Core Developers, Infrastructure, Documentation, Security, and Packaging (aports) from the get-go [14:25:02] ok, I propose we define the following teams to start with: core, infrastructure, aports, security, releng [14:25:10] <_ikke_> and documentation? [14:25:17] ah, yes, I forgot about myself :) sorry [14:25:18] documentation too [14:25:39] Cor, Infrastructure, Packaging / aports, Security, Release Engineering, Documentation [14:25:44] s/Cor/Core/ [14:25:48] ncopa will lead core, as well as security and releng (as those are unclear) - this means he can add any existing members in after the meeting concludes [14:25:48] INFO: Proposed teams: Core developers, infrastructure, documentation, security, packaging [14:26:04] ncopa wanted clandmeter to lead infrastructure, and I agree [14:26:09] +1 to that [14:26:14] no one but me is on documentation, so I suppose I will lead that [14:26:17] <_ikke_> SpaceToast: that's basically already the case [14:26:24] yes, that's the idea :) [14:26:24] <_ikke_> re infrastructure [14:26:26] I can spend more time on Alpine and lead Security, if it's necessary [14:26:33] +1 [14:26:35] I'm not sure who's in that right now, or how much time they have for it [14:26:45] we are left with packaging / aports - is there any idea as to who's in charge of that? [14:26:50] <_ikke_> I see security related bug reports on redmine [14:26:58] right _ikke_ [14:27:01] yes, it's a hidden project on redmine [14:27:01] <_ikke_> SpaceToast: currently core [14:27:15] (security is write-only) [14:27:28] we could assign ncopa, but the goal is to separate out tasks -- he should definitely be a member, but I would prefer if he didn't have to worry about managing it [14:27:55] team leads and members can always be reassigned earlier [14:28:35] team leads are a bit harder to reassign (since it requires a (quick) vote) per my proposal - we could .agree to not require votes for the first month (or something like that) [14:28:56] but in the long term I think it is essential to ensure continuous high quality of contribution [14:29:23] does an exception like that sound ok to those present, for the purposes of getting this implemented faster? [14:29:31] <_ikke_> I'm note sure what to do with packaging at the moment [14:29:51] if we pass the exception, we simply assign ncopa as the team lead, to be modified at a later (soon) date [14:29:52] <_ikke_> Of course there is a need for more contributors, but there is still also a need for 'QA' [14:30:04] should we perhaps have a dedicated QA team? [14:30:21] <_ikke_> SpaceToast: I would say no [14:30:26] we can wait with QA for now in my opinion, we don't have any infrastructure for it, or people dedicated to it [14:30:26] <_ikke_> SpaceToast: We are too small for that [14:30:29] me too would say no. [14:30:31] +1 [14:30:39] it may make sense to have it later, but now is a bit too soon, yeah :) [14:30:42] Too many teams for few ppl will make the thingsslower [14:30:46] <_ikke_> yes [14:30:51] can we .info a TODO to add it eventually? [14:31:01] (for future reference, purely) [14:31:18] INFO: For future, discuss QA team for aports [14:31:26] ok [14:31:31] AGREED: No QA team for now [14:32:01] I would propose (eventually) implementing community management, design, and promotion (social media etc.) [14:32:06] <_ikke_> imho that's the biggest bottleneck atm, you don't want to add people too quickly [14:32:14] +1 [14:32:24] <_ikke_> SpaceToast: to what? [14:32:28] people should be added at the discretion of the team leaders, but we need to solidify those first [14:32:33] both of you, actually :) [14:32:45] agreed [14:32:56] we need to implement the core necessities first [14:33:08] this leaves us with the two questions from before: [14:33:16] core, infra, docs, packaging, sec [14:33:20] <_ikke_> And don't forget there already is a structure atm, we don't start from scratch [14:33:44] 1. who do we assign to lead the packaging team; 2. do we forgoe the voting process for assigning/demoting team leaders temporarily (and if so, until when?) [14:33:57] yes, we want to build around the current structure, but also codify and improve it [14:34:16] the issue with the packaging team is that I'm not sure there is a real lead in it as-is now [14:34:16] <_ikke_> I don't see anyone else but ncopa lead the packaging team atm, but he might have a different idea about it [14:34:31] I propose ncopa as the lead for core and packaging for now, since that is where he is the most active as of now [14:34:45] I suggest assigning ncopa re: 1, and allowing 2 for the next month [14:34:47] it could be changed at a later date, but I believe ncopa is the best fit, at least for now [14:34:51] does that sound ok to everyone? [14:35:27] sounds ok to me [14:35:40] so team leads are as follows - core: ncopa, infra: clandmeter, documentation: spacetoast, security: ncopa, packaging: ncopa [14:35:42] <_ikke_> aports is the core of Alpine [14:36:02] yes [14:36:04] yes and no - people that have push access to aports should not necessarily have access to the signing keys, right? [14:36:20] INFO: Suggested team leads: core: ncopa, infra: clandmeter, documentation: spacetoast, security: ncopa, packaging: ncopa [14:36:41] <_ikke_> only ncopa has them at this moment [14:36:56] also fabled iirc [14:37:04] then that'd make him the only member of the core team, as defined by the proposal, at least [14:37:19] <_ikke_> SpaceToast: there are a lot more core members defined [14:37:36] <_ikke_> The current list counts 11 members [14:37:36] look up wiki.intra.a.o [14:37:39] .a.pw* [14:37:45] or was it infra.a.pw [14:37:46] <_ikke_> Yes, but not everyone has access to there [14:37:47] yes [14:37:57] yes, but it seems that the definition as is currently is mixed with the packaging team [14:38:17] <_ikke_> There is a seperate list of developers [14:38:17] I wish ncopa was present so we could discuss security [14:38:41] <_ikke_> Developers counts 8 members [14:39:04] in order to achieve goal 1, we need a clear separation of tasks [14:39:19] so perhaps we should move to defining specific team scopes, to figure out what the members should be (from the current structure) [14:39:29] <_ikke_> Well, because alpine is small, you don't get to separate everything [14:39:40] <_ikke_> You will have members that will have multiple tasks [14:40:04] of course, the "core" team is also a catch-all; the issue is that I'm pretty sure packaging can be separated out from core [14:40:13] (in fact, it straight up is) [14:40:24] <_ikke_> It already is, it is called 'developers' [14:40:43] context-switching will occur, it is a necessary evil given the project's small size. in my understanding, we wish to minimize it, not eliminate it [14:40:46] <_ikke_> But because packaging is such a core business of alpine, the core team has the lead [14:40:52] ^ [14:41:07] danieli: eliminating it is a distant goal, of course, just possibly not attainable right now [14:41:10] +1 [14:41:18] +1 for _ikke_ [14:41:51] <_ikke_> SpaceToast: I don't think in the near future as well [14:42:01] distant implies not-near :) [14:42:20] still, if we do have a packaging team, what is the difference between that and core? [14:42:30] the packaging team should certainly have access to aports [14:42:40] <_ikke_> In my opinion, one of the things that I'm atracted to in alpine is the relatively small community [14:42:50] Not all packaging team has access to main afaik [14:43:01] packagint team members* [14:43:17] <_ikke_> right, I just have access to community and testing for example [14:43:24] exactly [14:43:24] <_ikke_> which is fine [14:43:32] ok, so perhaps we define the packaging team as having access to non-main, while main remains in the responsibility of core? [14:43:45] I'm going into details because I'm going to have to write all this down (likely today) [14:43:45] so here you already have a difference [14:44:00] sounds good SpaceToast [14:44:06] <_ikke_> SpaceToast: I think that's at the discretion of ncopa ofcourse [14:44:15] of course, it can all be adjusted [14:44:30] so, let me try and summarize the current team definitions then [14:44:52] quick question: who is on the security team at the moment? [14:45:01] and who is the de-facto leader? [14:45:01] <_ikke_> fcolista: do you know ^? [14:45:04] all core members [14:45:11] I did not know that, interesting [14:45:28] I suspect not all of them are interested in dealing with CVEs, so they can be removed as needed later [14:45:51] right [14:45:55] if you go on redmine [14:45:59] I meant to ask who actually does the work of documenting vulnerabilities and dealing with reporters/researchers [14:46:05] in Alpine Security [14:46:11] you can see the members [14:46:12] Security Officer: Alex Dowad, Alexander Belous, Alfred Landrum, Alicha CH, Christian Kampka, Daniel Sabogal, Eivind Uggedal, Jill Hollis, Richard Mortier, Roberto Oliveira, Sergei Lukin [14:46:32] but several there are no longer around... [14:46:39] packaging: non-main aports repositories; security: handling CVEs and collaboration with security experts and other distributions; documentation: maintenance of the official alpine documentation and manual pages of alpine-specific projects; infrastructure: maintaining various alpine infrastructure hosts and software; core: supervisory team, also in control of the main repository [14:46:40] yeah, there are quite a few names I don't recognize [14:46:44] (which leads to anohter topic too) [14:46:46] does that sound correct? [14:46:52] <_ikke_> Alicha CH is the most active\ [14:46:55] <_ikke_> from what I see [14:46:57] (ideally we put each of those in a separate info, if possible, _ikke_) [14:47:01] _ikke_: what is their nick? [14:47:12] <_ikke_> I don't know, I just see them in redmine [14:47:37] <_ikke_> They might be not really affiliated with Alpine, just reporting things [14:47:47] Alicha CH takes care of finding CVEs [14:48:08] and create redmine bgs [14:48:11] bugs* [14:48:14] <_ikke_> yes [14:48:22] <_ikke_> SpaceToast: trying to find a good summary [14:48:44] I would write it in a format like this: .info The X team does Y; and repeat for each [14:48:48] up to you though [14:48:48] <_ikke_> yeah [14:50:01] INFO: Core team: Core members, have oversight over project and takes lead over packaging and security [14:50:49] INFO: Infra team: Takes care of the Alpine Linux infrastructure (maintaining servers and services) [14:50:53] good summary _ikke_ [14:51:44] I don't like the core definition (since it still overlaps with two other teams), but I'll accept it for now, knowing that we have provisions to change it later if needed :) [14:51:46] INFO: Packaging team: Members with (limited) access to aports, take care of packaging and accepting PRs / patches from the community [14:52:03] <_ikke_> SpaceToast: It's the reality, not the ideal situation [14:52:11] yeah, lots of work to get to that latter one [14:52:15] SpaceToast, right, but this is what we have now [14:52:18] codifying the current state is important too [14:52:19] Security team: Takes care of communication with vulnerability reporters, maintaining an Alpine security advisory program, and information sharing with other projects. [14:52:21] team/roles overlap [14:52:22] which is why I'm accepting it [14:52:42] danieli: +1 [14:52:47] INFO: Security team: Takes care of communication with vulnerability reporters, maintaining an Alpine security advisory program, and information sharing with other projects. [14:53:22] <_ikke_> Security team: Takes care of communication with vulnerability reporters, maintaining an Alpine security advisory program, and information sharing with other projects. [14:53:31] <_ikke_> Anyhthing to add there? [14:53:42] I think that about covers it [14:53:46] doc team? [14:53:47] I was worried the last part would be missing [14:54:01] s/doc/docs/ [14:54:07] Doc team maintains the official alpine documentation and manual pages for alpine-specific projects [14:54:15] long way off from that latter bit, but it will be happening [14:54:38] speaking of - does anyone present have access to gitolite settings? [14:54:42] <_ikke_> Documentation team: Create and maintain official documentation for Alpine Linux [14:54:53] <_ikke_> somehting like that? [14:54:55] missing manual pages, but you could infer those, I guess [14:55:15] I'd say 'official documentation' covers that [14:55:16] (after the meeting is over, I will be adding all of this to the newly created developer-handbook, and may need help getting it to show up on git.a.o) [14:55:24] yes, that's what I mean by "infer" [14:55:40] what do you mean by 'show up on git.a.o'? [14:55:54] INFO: Documentation team: Create and maintain official documentation for Alpine Linux [14:56:00] when I originally made the docs/ repositories, they weren't visible on git.a.o [14:56:09] clandmeter had to do some other stuff to make them show up in the web ui [14:56:18] <_ikke_> Yes, you have to 'export' the project [14:56:19] aah yes, probably hidden, like the infra/ namespace [14:56:23] yeah [14:56:38] I'm basically wondering if anyone present has access to do that :) [14:56:39] <_ikke_> Each project needs to be explicitly be exported for it to show up in cgit [14:56:54] <_ikke_> I technically have access, but not officially :-) [14:57:00] ooh~ ;) [14:57:32] I think we covered all the teams, or did we miss one? [14:57:44] <_ikke_> release engineering? [14:57:46] ah, yes! [14:57:56] let me try to find ncopa's ML entry [14:58:06] rel eng has been quite vague as of now, and afaik ncopa has dealt with that alone [14:58:37] https://lists.alpinelinux.org/alpine-devel/6360.html [14:58:43] we could define a team for it, but I suspect we'll have to keep him as the team lead there until further notice [14:58:54] so, if we define it... [14:59:06] <_ikke_> SpaceToast: thanks, was looking for a link to that one [14:59:12] LINK: https://lists.alpinelinux.org/alpine-devel/6360.html [alpine-devel: [alpine-devel] a release engineering team?] [14:59:29] the definition would be "decides on the timing of releases, and cherry-picks what to include in them" [14:59:40] or something along those lines [14:59:48] needs to be very close to aports team [14:59:49] INFO: Potential team: Release engineering. Need to find team members / people who want to contribute [14:59:58] I think we can hold off on defining that for now, since nothing much happened since the proposal [15:00:10] i agree [15:00:16] codifying current teams means we can add more in the future easily, so no need to rush it right now [15:01:07] Current subject: Documentation of teams, (set by _ikke_) [15:01:44] <_ikke_> Currently the documentation is only internal (mostly because it contains private information as well) [15:01:53] since we seem to be starting relatively small, we could keep all of the teams on one page, maybe even the same page that explains how teams work (more or less a reorganized copy of the proposal) [15:02:08] but I think it'd be better for scaling to give each team their own official page [15:02:09] <_ikke_> The current internal wiki page is a single page [15:02:23] <_ikke_> I think that can grow naturally [15:02:28] what type of private information is included? [15:02:39] it's a simple list of members of core/infra/packaging teams, plus their names/nicks/emails/pgp keys/ssh keys [15:03:06] it also seems to be outdated (as per above comments) [15:03:14] I'm not so sure there's a lot of private or personal information there, but I would want to ask for permission to publish what we deem necessary [15:03:23] <_ikke_> SpaceToast: how so outdated? [15:03:25] yes, but it's what we have, it could function as a starting point [15:03:31] _ikke_: people being inactive [15:03:39] _ikke_: for example, when we went over the security listing, most of the entries weren't recognized [15:03:39] but I believe the intra wiki page is fairly up to date? [15:03:41] <_ikke_> THat was mostly the redmine gorups [15:03:45] aha [15:03:52] I'll hop on the VPN and have a look [15:03:54] I think name / nick / email is enough [15:03:59] <_ikke_> Security is not documented on internal wiki [15:04:16] yes [15:04:22] ssh keys have no business being there, and pgp keys don't matter for everyone (e.g my pgp key is entirely irrelevant) [15:04:29] <_ikke_> Note that some people don't want to have their name exposed to the world [15:04:45] <_ikke_> SpaceToast: hence it's an internal wiki [15:04:50] ok, name is allowed to be censored, as long as the nick and email is present [15:04:59] and email may be absent as long as name and nick is present [15:05:01] is that ok? [15:05:08] <_ikke_> Fine with me [15:05:16] fcolista, danieli? [15:05:42] nick/username, optionally email address, and the team they're on [15:05:46] imo anyway [15:05:50] but let's omit emails for now [15:05:52] I'm planning to have a table per team [15:06:00] <_ikke_> yes, makes ense [15:06:01] <_ikke_> sense [15:06:04] emails are very important for the security team, at least, imo [15:06:35] <_ikke_> SpaceToast: there was once the idea of having some kind of PGP forwarder [15:06:37] I think I'll have all 3 columns, but either the name of the email may be missing [15:06:48] s/of/or/ [15:06:55] at the moment, our internal wiki lists name, nick, username, email, shs keys, pgp key [15:07:02] ssh* [15:07:12] is there a difference between nick and username? [15:08:07] INFO: Current documentation has a single page with one table per team. Initially this format can be copied, but later we might opt to have one page per team [15:08:09] in some cases, yes, I believe it's the nickname on IRC vs username on hosts and in applications [15:08:48] <_ikke_> One thing I wanted to mention (because it was in danieli's proposal) [15:09:17] I don't think username is necessarily needed - I think people will figure out that SpaceToast and toast are the same person, for example :) [15:09:42] <_ikke_> At least in the beginning when things are still small, I don't think we should have completely every 'channel' separated per team [15:09:52] I believe username is more important than nickname [15:10:18] I think the distinction is moot, since one might have different usernames on different services (e.g I'm 5paceToast on github) [15:10:37] so I would opt to just have a single generic "nick", that people will understand may have variations [15:10:43] <_ikke_> Yes, agreed [15:10:52] _ikke_: I agree, my proposal doesn't necessitate those, by the way [15:11:09] each team has freedom to operate how they wish internally - if they want a channel, they can ask (infra) for it, but they don't need to [15:11:10] <_ikke_> SpaceToast: Understood, just wanted that to be explicit [15:11:17] ok, feel free to .info it [15:11:32] <_ikke_> I think there is a benefit of cross-team communication [15:11:46] yes, and I think #alpine-devel will continue to serve that purpose, as it does now [15:11:52] <_ikke_> correct [15:12:01] and of course meetings are inter-team (even if only leads are given explicit votes) [15:13:20] INFO: cross-team communication should be stimulated. Therefore, we should opt to not have automatic separate communication channels per team. [15:13:24] <_ikke_> Something like that [15:13:34] fair enough [15:13:54] should team leads be mentioned at the top of each team's section [15:14:01] or should we have a cell denoting the status of each member? [15:14:12] I do believe each team should be able to request a category at wiki.a.o, a namespace at git.a.o, subdomains and hosting if necessary (managed by infra team) [15:14:22] the advantage of the former is it's fast to find out who is the lead, for both voting and outsider purposes [15:14:29] the advantage of the latter is we can document "known contributors" [15:14:43] danieli: sounds good to me [15:14:51] <_ikke_> danieli: Yes, my remark was mostly regarding communication [15:14:55] requests need not be automatically granted, but (especially the git.a.o part) is a good idea [15:15:06] <_ikke_> separate workspaces make sense [15:15:42] INFO: Teams can request separate workspaces (namespaces) for collaboration [15:15:51] <_ikke_> danieli: happy? [15:16:41] works for me, the intention is obvious [15:16:58] okay [15:16:58] <_ikke_> anything else? [15:17:07] just the marking of leads I mentioned above [15:17:08] <_ikke_> Next subject would be membership [15:17:18] I think I'm going to make leads bold, and call it at that for now [15:17:21] <_ikke_> I don't have a strong preference [15:17:22] any objections? [15:17:26] <_ikke_> +1 [15:17:47] <_ikke_> and probably mentioned as first I guess [15:17:53] team leads at the top of the list, perhaps in bold too? [15:17:55] by the way, can we have a .info to explicitly mention that each team may have MULTIPLE leads, to avoid confusion (as we start out with one per team) [15:18:14] if I do the bold thing, I would put them in alphabetical order [15:18:16] INFO: Each team may have multiple team leads [15:18:21] ty [15:18:36] I don't expect that to be the case for a while, but it's important to have it marked [15:18:45] Current subject: Team membership, (set by _ikke_) [15:18:57] ok, let's start with the easy ones [15:19:04] documentation has me, security has ncopa [15:19:30] we have packaging, core and infra to get a full listing of [15:19:38] <_ikke_> The idea is also to document how people can join teams (or be rejected from them) [15:19:39] if desirable, I can either be the team lead for or otherwise do work on the security team [15:19:48] rationale: ncopa has used me as an advisor in terms of security multiple times in the past (e.g. when requesting CVEs or assessing the severity of reported vulns), I am waist-deep in the infosec industry, and I already know members of other projects' security teams [15:19:51] _ikke_: that's part of the original proposal [15:19:55] <_ikke_> danieli: Let's have ncopa decide hat [15:19:58] agreed [15:20:07] just thought I'd mention it for the record [15:20:10] to become a member, you need only convince the team leader to add you (by contributing well) [15:20:13] <_ikke_> SpaceToast: Yes, my idea was to have that discuessed here as well [15:20:16] aha [15:20:36] to become a team lead, you must either start a new team (requires vote of all the team leads), or have all the team leads vote on your inclusion [15:20:44] anyway, I'm on the infrastructure team, that's about it [15:20:48] (and must already be a member of the team you wish to lead in the latter case) [15:20:58] <_ikke_> I feel people should be known to the project as well [15:21:20] I feel like that's very nebulous and full of uncertainty [15:21:25] <_ikke_> right [15:21:28] <_ikke_> it is [15:21:29] it could be a requirement for being a team lead [15:21:35] but it really shouldn't be for base team membership, imo [15:21:49] otherwise we're interfering with point 2 of the goal (making it easier to join and contribute) [15:21:56] +1 [15:21:56] <_ikke_> Yes, understood [15:21:57] sorry I was afk [15:21:58] just back [15:22:03] no worries fcolista :) [15:22:14] let's start with membership requirements: [15:22:30] to become a member, you must have already contributed to the team you are joining, and you need a team lead to appoint you as member [15:22:38] I think this one is simple enough, so any objections? [15:22:49] <_ikke_> Yes, I guess that's what I wanted to say [15:23:03] very similar to what AUR does [15:23:19] yes, it's a lot more "lax" than the gentoo approach, which I think works well for us [15:23:31] +1 [15:23:35] it's the primary difference my proposal has from gentoo's "project" system [15:23:46] <_ikke_> But contributing to AUR does not make you part of an Arch team [15:24:09] precisely, having contributed is just a requirement to even be considered [15:24:11] yes, i was thinking more to the engaging roles [15:24:36] so becoming a member is relatively simple - contribute often enough that a team lead thinks it makes sense to give you access [15:24:57] to become a team lead, you must already be a member of the team (or be forming a new team), at which point all of the team leads shall vote on whether or not to add you as a team lead [15:25:01] <_ikke_> yes, that feels right [15:25:07] yes..at least giving the idea that you will stay for a while... [15:25:16] (re: membership) [15:25:48] ok, while we discuss the team lead bit, can we .info the membership requirement? [15:26:44] INFO: Team membership requirement: The team lead can decide to add team members. It's expected that a new team member has already contributed to the team and has shown to stay with the project. [15:26:56] <_ikke_> Is that fair enough? [15:27:46] yes, though that implies there's only one team lead :) [15:27:55] <_ikke_> Right, team leads* [15:28:00] the earlier explicit mention that that's not necessarily true is enough, and I'll rewrite it later [15:28:27] <_ikke_> Ok, team leads [15:28:48] let me amend, actually, since it makes it sound like just anyone can form a new team [15:29:12] to become a team lead, you must be a member of that team (or any team, if you are forming a new team), at which point all of the team leads shall vote on whether or not to add you as a team lead [15:29:42] this implicitly means you must be well known in the community, since you should not vote in favor of someone you've never heard of becoming a team lead [15:30:07] INFO: Team leads are decided by existing team leads. A proposed team lead should be already part of the specific team or in case of a new team, be member of another team. [15:30:29] okay, we can codify the voting process later [15:30:38] <_ikke_> right] [15:30:41] (there was talk of making it nonexistent for bootstrapping anyway) [15:30:51] so all that's left is a list of *current* members [15:30:59] danieli: did you get any details on that? [15:31:12] details on what, exactly? [15:31:18] <_ikke_> list of current members [15:31:33] ideally trimmed to remove afks [15:31:55] morning [15:32:01] <_ikke_> ddevault: welcome [15:32:03] ... am I supposed to have details on that? [15:32:10] <_ikke_> danieli: internal wiki [15:32:12] ddevault: morning [15:32:13] you said you were going to look into it in the internal wiki [15:32:16] heya ddevault [15:32:26] oh, I just said I was going to have a quick look so I'd be less confused [15:32:30] ah [15:32:44] I do need to write all of them down, so if you could help me out with that it'd be quite nice ;) [15:32:58] <_ikke_> I have the list open [15:33:04] okay [15:33:15] I think we can omit going over it in the meeting though, I just need to write them down later [15:33:23] how about an .action re: you helping me get the full list in? [15:33:37] oh yeah, that's fine, it's easy enough to export / copy the relevant items [15:33:51] it's mostly about trimming afks and unneeded / private information [15:33:53] ACTION: provide a list of members to SpaceToast (documentation) [15:34:10] I think that's about it then? on to open floor? [15:35:14] Current subject: Open Floor, (set by _ikke_) [15:35:31] if anyone has any further comments / concerns, now would be the time :) [15:35:36] python? [15:36:04] not sure what ought to be discussed outside of what I posted on the list, but that's why I was invited to this meeting :) [15:36:06] anyone have thoughts? [15:36:18] it's a bit late at this point to be defining more teams, unfortunately :/ we kind of went over that about an hour ago [15:36:51] well, I wasn't even expecting a formal process anyway [15:36:52] <_ikke_> The idea is not to get too many new teams right now, especially because the people who would be in the teams would be doing the work now anyway [15:37:02] in my mind the team would form because it thinks it ought to exist [15:37:09] then just send request-pulls periodically [15:37:10] <_ikke_> yes, my idea exactly [15:37:28] _ikke_: ddevault is currently trying to get python3 in from python2, I suggested that perhaps he may be interested in making a language-specific team for python in general [15:37:42] I also want to normalize and clean up all python packages in aports [15:37:57] yeah, exactly what a language-specific team would normally be doing, thus my earlier suggestion [15:38:03] aye [15:38:03] <_ikke_> Right, but whether there is a team or not, the process would be the same at this moment [15:38:06] but at this point it may be better to do this formally later [15:38:23] once everything has settled from the reorganization [15:38:38] <_ikke_> For packages in main, we should ask a core member to apply it anyway [15:38:44] <_ikke_> (With push access to main) [15:38:56] makes sense [15:39:04] <_ikke_> ddevault: Once the meeting is over, you can see the meeting notes [15:39:08] ^ [15:39:08] ack [15:39:10] is there anything else? [15:39:26] <_ikke_> Nothing from my part [15:39:47] ddevault: you'll also be able to read the developer-handbook once I get that written (even if it won't be official until final approval from ncopa, which is hopefully tomorrow) [15:40:36] ok, I think we can close the meeting out at this point (given radio silence) [15:40:41] <_ikke_> If no one has anything, I'll close the meeting [15:40:46] Meeting ended by _ikke_, total meeting length 5812 seconds [15:40:47] I'll ask about the members listing in #alpine-docs once I get to that point