Stream: t-compiler/meetings

Topic: [design meeting] areas of the compiler compiler-team#288


nikomatsakis (Jun 26 2020 at 13:58, on Zulip):

Hi @T-compiler/meeting! Design meeting for compiler-team#288 is set to begin soon.

let's start out with some...

Announcements

nikomatsakis (Jun 26 2020 at 14:03, on Zulip):

Quiet today :)

pnkfelix (Jun 26 2020 at 14:05, on Zulip):

maybe its a sign that the Thursday meetings are going better

nikomatsakis (Jun 26 2020 at 14:05, on Zulip):

Heh, no last minute scrambling?

nikomatsakis (Jun 26 2020 at 14:05, on Zulip):

Well, I guess we can get started.

nikomatsakis (Jun 26 2020 at 14:06, on Zulip):

I guess to start I'd just say that the motivation here is to try to reflect some of the more "latent" structure of the code base in our organization, maybe a sort of "expert map 2.0",

nikomatsakis (Jun 26 2020 at 14:07, on Zulip):

but hopefully in a minimal way that doesn't imply a lot of extra work or overhead (although I think some variants can get more ambitious)

LeSeulArtichaut (Jun 26 2020 at 14:07, on Zulip):

I think it will also help the Prioritization WG cc the right people for high priority issues.

nikomatsakis (Jun 26 2020 at 14:07, on Zulip):

and I guess I would kind of want to raise up -- although it wasn't part of original proposal -- @Vadim Petrochenkov's fine-grained reviewing PR

nikomatsakis (Jun 26 2020 at 14:08, on Zulip):

as being in a similar vein

pnkfelix (Jun 26 2020 at 14:08, on Zulip):

Are areas ever meant to reflect cross cutting concerns? Or is that explicitly not a goal?

pnkfelix (Jun 26 2020 at 14:08, on Zulip):

I'm thinking specifically of something like parallel compilation

nikomatsakis (Jun 26 2020 at 14:08, on Zulip):

I would say that is not a goal

nikomatsakis (Jun 26 2020 at 14:08, on Zulip):

Well

nikomatsakis (Jun 26 2020 at 14:08, on Zulip):

I'm not sure :)

nikomatsakis (Jun 26 2020 at 14:08, on Zulip):

I guess let me say what we were thinking first

nikomatsakis (Jun 26 2020 at 14:08, on Zulip):

and then we can discuss that

pnkfelix (Jun 26 2020 at 14:08, on Zulip):

okay

nikomatsakis (Jun 26 2020 at 14:09, on Zulip):

(I think this question of terminology also interacts with some of the recent discussions in #wg-governance...)

nikomatsakis (Jun 26 2020 at 14:09, on Zulip):

but basically the ide is that we can create some defined areas of the compiler --

nikomatsakis (Jun 26 2020 at 14:09, on Zulip):

I think my go-to example wouldl be things like "type checking and trait solving", "parser and macro expansion, "borrow checking"

pnkfelix (Jun 26 2020 at 14:10, on Zulip):

nikomatsakis said:

(I think this question of terminology also interacts with some of the recent discussions in #wg-governance...)

i assume this is referring more specifically to #wg-governance > on working groups and teams

nikomatsakis (Jun 26 2020 at 14:10, on Zulip):

but I think that something like parallel compilation or query system, which is "sort of" cross-cutting, could be viable?

pnkfelix (Jun 26 2020 at 14:10, on Zulip):

oh yes, I suppose the "plumbing" area might be cross cutting

nikomatsakis (Jun 26 2020 at 14:10, on Zulip):

yeah, specifically I was proposing that we just reserve the "project group" terminology for things with a fxied task, and use "subteams" for indefinite things

nikomatsakis (Jun 26 2020 at 14:10, on Zulip):

so these would be more subteams

pnkfelix (Jun 26 2020 at 14:10, on Zulip):

some of the subareas within "plumbing" have their own dedicated crates, but still, the query system seems quite cross-cutting

nikomatsakis (Jun 26 2020 at 14:11, on Zulip):

in any case the idea would be that for each of these subteams, we have a zulip stream, and we do try to kind of track membership, but I think the amount of "activity and organization" in the subteam would vary

nikomatsakis (Jun 26 2020 at 14:11, on Zulip):

I think that we have some latent examples of this

nikomatsakis (Jun 26 2020 at 14:11, on Zulip):

I'm thinking of #t-compiler/wg-mir-opt and #t-compiler/wg-llvm

nikomatsakis (Jun 26 2020 at 14:11, on Zulip):

but also what #t-compiler/wg-nll is becoming

Santiago Pastorino (Jun 26 2020 at 14:12, on Zulip):

#t-compiler/wg-diagnostics too

nikomatsakis (Jun 26 2020 at 14:12, on Zulip):

I feel like mir-opt is a good example of the power of calling out an area, and perhaps what a "more organized" such area might look like

nikomatsakis (Jun 26 2020 at 14:13, on Zulip):

but I think it's also ok for it to be like llvm, just a place for people to hang out and answer questions, and maybe have an opinion when an opinion is needed :)

nikomatsakis (Jun 26 2020 at 14:13, on Zulip):

though I think also llvm group does pursue upgrades etc

nikomatsakis (Jun 26 2020 at 14:13, on Zulip):

perhaps more as individuals, but anyway

nikomatsakis (Jun 26 2020 at 14:13, on Zulip):

I guess one other thing is that I htink we have to try to keep the set of "areas" kind of manageable

nikomatsakis (Jun 26 2020 at 14:14, on Zulip):

it's tempting to create the perfect taxonomy but I think that's a rat's nest...

pnkfelix (Jun 26 2020 at 14:14, on Zulip):

the more that it can correspond to crate structure, the better

pnkfelix (Jun 26 2020 at 14:14, on Zulip):

I know we can't get that 100%

nikomatsakis (Jun 26 2020 at 14:14, on Zulip):

yes, in the fullness of time, I would love it if it corresponded actually very closely with crate structure

nikomatsakis (Jun 26 2020 at 14:16, on Zulip):

I would add @pnkfelix in terms of "cross-cutting", I think that it might make sense to include things like "windows" and "ARM" groups in this list eventually

pnkfelix (Jun 26 2020 at 14:17, on Zulip):

so what about the current "area" labels we have on github?

pnkfelix (Jun 26 2020 at 14:17, on Zulip):

will we keep those in sync with these areas?

nikomatsakis (Jun 26 2020 at 14:17, on Zulip):

yeah, a good question

nikomatsakis (Jun 26 2020 at 14:17, on Zulip):

I'm debating

Santiago Pastorino (Jun 26 2020 at 14:17, on Zulip):

yeah I think we should keep those in sync

pnkfelix (Jun 26 2020 at 14:17, on Zulip):

many of those are chosen based on language features

nikomatsakis (Jun 26 2020 at 14:17, on Zulip):

I would definitely say that each A-foo label should be the domain of one of these subteams

pnkfelix (Jun 26 2020 at 14:17, on Zulip):

not compiler structure

nikomatsakis (Jun 26 2020 at 14:18, on Zulip):

and maybe it's useful to not use the area terminology for both

nikomatsakis (Jun 26 2020 at 14:18, on Zulip):

i.e., maybe it's better to just think of them as "compiler subteams"

Santiago Pastorino (Jun 26 2020 at 14:18, on Zulip):

right

nikomatsakis (Jun 26 2020 at 14:18, on Zulip):

I guess I do think that the finer grained A-foo labels are useful and I'm not sure I'd want to like mass-remove that data in favor of something coarser-grained

pnkfelix (Jun 26 2020 at 14:18, on Zulip):

but we don't want to use the word "experts", like we did in past

pnkfelix (Jun 26 2020 at 14:18, on Zulip):

because that implies a barrier to entry

pnkfelix (Jun 26 2020 at 14:18, on Zulip):

into a "subteam"

pnkfelix (Jun 26 2020 at 14:18, on Zulip):

that we do not want

pnkfelix (Jun 26 2020 at 14:18, on Zulip):

right?

nikomatsakis (Jun 26 2020 at 14:18, on Zulip):

yeah, I don't love experts, I want it to be more lke "interested" :)

nikomatsakis (Jun 26 2020 at 14:19, on Zulip):

but I do think we could have leads/members imply some level of knowledge

pnkfelix (Jun 26 2020 at 14:19, on Zulip):

"enthusiasts"

Santiago Pastorino (Jun 26 2020 at 14:19, on Zulip):

yeah I sort of think like you want leaders, members and interested people

nikomatsakis (Jun 26 2020 at 14:20, on Zulip):

and I could imagine also connecting this to Vadim Petrochenkov's idea -- i.e., maybe we can categorize PRs within these subteams and drive reviewing from that? or at least ping the relevant folks? not sure. that's maybe a step worth discussing later, or maybe it's good to discuss at the same time.

pnkfelix (Jun 26 2020 at 14:20, on Zulip):

unfortunately "E-" is already taken as a prefix on github. But "Z-" is available; clearly the word should be "zealots" :joking:

nikomatsakis (Jun 26 2020 at 14:20, on Zulip):

what I wrote before about leads:

Leading an area should not be a large commitment. It mostly means that you are aware of what’s going on and can help figure out the right person to answer a question. At minimum, it means you should be generally monitoring the corresponding Zulip stream(s).

nikomatsakis (Jun 26 2020 at 14:21, on Zulip):

I guess @pnkfelix you're imagining some label for each of these subteams?

pnkfelix (Jun 26 2020 at 14:21, on Zulip):

yeah

pnkfelix (Jun 26 2020 at 14:21, on Zulip):

Z actually does work for "Zulip stream"

nikomatsakis (Jun 26 2020 at 14:21, on Zulip):

T-compiler-diagnostics ? :)

pnkfelix (Jun 26 2020 at 14:21, on Zulip):

I suppose that would be fine

nikomatsakis (Jun 26 2020 at 14:21, on Zulip):

I guess a bot could go and ensure that every T-compiler-diagnostics issue also has T-compiler etc

nikomatsakis (Jun 26 2020 at 14:22, on Zulip):

ideally, tagging with A-foo would put those labels on

Santiago Pastorino (Jun 26 2020 at 14:22, on Zulip):

Santiago Pastorino said:

yeah I sort of think like you want leaders, members and interested people

I guess the distinction between members and interested people may or may not be important, maybe we want members = possible mentors, interested people = mentored people or something like that

nikomatsakis (Jun 26 2020 at 14:22, on Zulip):

yeah I'm of two minds on it. I do think it seems useful but I worry about things being too dang complicated. But I think we should define what we want membership to mean.

nikomatsakis (Jun 26 2020 at 14:22, on Zulip):

It might start with "no members"

nikomatsakis (Jun 26 2020 at 14:22, on Zulip):

so that we can decide later what we think it means :)

LeSeulArtichaut (Jun 26 2020 at 14:23, on Zulip):

nikomatsakis said:

I guess a bot could go and ensure that every T-compiler-diagnostics issue also has T-compiler etc

Triagebot can do that as of today, but there is no idiomatic way of doing it, it would mean that you have to include a configuration for every subteam. What I could do is throw an implementation PR to allow the use of glob patterns so that every issues that gets a T-compiler-* label also gets T-compiler. Doesn't seem too complicated to me.

nikomatsakis (Jun 26 2020 at 14:23, on Zulip):

i.e., let's just rebrand some of our existing structure as subteams, create some more to fill things out, and make labels for them.

Santiago Pastorino (Jun 26 2020 at 14:23, on Zulip):

yeah if we would go with a light scheme, something to improve later maybe we should go with the very minimum and keep improving

nikomatsakis (Jun 26 2020 at 14:23, on Zulip):

and we would say that these subteams don't have members, people join compiler/contributors as a whole.

pnkfelix (Jun 26 2020 at 14:24, on Zulip):

do we expect these subteams to go through e.g. rfcbot merge processes?

pnkfelix (Jun 26 2020 at 14:24, on Zulip):

I ask because I'm wondering whether we even need to distinguish mentors vs interested people

nikomatsakis (Jun 26 2020 at 14:24, on Zulip):

I think I do not. I've debated about it. I think it would be plausible at some point.

pnkfelix (Jun 26 2020 at 14:24, on Zulip):

but I guess the idea is to document whom to ask

nikomatsakis (Jun 26 2020 at 14:24, on Zulip):

I'm imagining a project like chalk

nikomatsakis (Jun 26 2020 at 14:25, on Zulip):

if sufficiently well developed with a strong API boundary

nikomatsakis (Jun 26 2020 at 14:25, on Zulip):

I guess I feel like it could at some point have its own sort of decision making --

nikomatsakis (Jun 26 2020 at 14:25, on Zulip):

but I don't know, RFCs hardly make sense in the compiler after all

nikomatsakis (Jun 26 2020 at 14:25, on Zulip):

(though I guess you were asking about FCP, not RFC)

pnkfelix (Jun 26 2020 at 14:25, on Zulip):

right, I meant more for PR's

pnkfelix (Jun 26 2020 at 14:25, on Zulip):

yes, I forgot the "fcp" part

nikomatsakis (Jun 26 2020 at 14:26, on Zulip):

yeah. I'm not sure! :shrug:

nikomatsakis (Jun 26 2020 at 14:27, on Zulip):

btw I would probably rebrand #t-compiler/wg-prioritization as a subteam too

nikomatsakis (Jun 26 2020 at 14:27, on Zulip):

which is another reason to move away from "area" terminology

pnkfelix (Jun 26 2020 at 14:27, on Zulip):

ah

nikomatsakis (Jun 26 2020 at 14:27, on Zulip):

though that is one where members do make sense

pnkfelix (Jun 26 2020 at 14:28, on Zulip):

indeed, at some point it seems like we'll probably want to go through all wg's and decide "is this a subteam, or a project"

nikomatsakis (Jun 26 2020 at 14:28, on Zulip):

yeah. I feel like I did that at some point

pnkfelix (Jun 26 2020 at 14:28, on Zulip):

Now that I think about it

nikomatsakis (Jun 26 2020 at 14:28, on Zulip):

but I guess I didn't write it in the hackmd

pnkfelix (Jun 26 2020 at 14:28, on Zulip):

things could have option of starting as a WG

pnkfelix (Jun 26 2020 at 14:28, on Zulip):

where part of WG's goal

nikomatsakis (Jun 26 2020 at 14:28, on Zulip):

I think that the incremental compilation thing we've been talking about is more a subteam

pnkfelix (Jun 26 2020 at 14:28, on Zulip):

is to determine "are we a subteam, or a project?"

nikomatsakis (Jun 26 2020 at 14:29, on Zulip):

my thought is more this

nikomatsakis (Jun 26 2020 at 14:29, on Zulip):

say you have a new idea -- like polonius

nikomatsakis (Jun 26 2020 at 14:29, on Zulip):

(or chalk)

Santiago Pastorino (Jun 26 2020 at 14:29, on Zulip):

one thing I guess may be important in the members vs interested discussion is ... do we want to do something like highfive and assign issues to members of an area?

nikomatsakis (Jun 26 2020 at 14:29, on Zulip):

you create a project group with the goal of "bootstrapping and proving it out"

Santiago Pastorino (Jun 26 2020 at 14:29, on Zulip):

like I'm trying to think about very specific needs

nikomatsakis (Jun 26 2020 at 14:29, on Zulip):

if it's a success, it becomes a part of some subteam (or a new one)

nikomatsakis (Jun 26 2020 at 14:29, on Zulip):

Santiago Pastorino said:

like I'm trying to think about very specific needs

yes, thank you

Santiago Pastorino (Jun 26 2020 at 14:29, on Zulip):

maybe you want to assign issues to members and ping interested people

nikomatsakis (Jun 26 2020 at 14:29, on Zulip):

I was going to say: I'd like to summarize and then drill into what concrete benefits we expect

pnkfelix (Jun 26 2020 at 14:30, on Zulip):

interesting. so under your scheme, everything would start as a project group

nikomatsakis (Jun 26 2020 at 14:30, on Zulip):

(more or less, but I think incremental kind of already did its project phase)

nikomatsakis (Jun 26 2020 at 14:30, on Zulip):

(we just didn't call it that)

pnkfelix (Jun 26 2020 at 14:30, on Zulip):

(unless it is immediately obvious that it should be a subteam, for whatever reason, such as that of incremental.)

nikomatsakis (Jun 26 2020 at 14:30, on Zulip):

not to say we couldn't have a project group with a more targeted agenda -- e.g., end-to-end, or something like that

pnkfelix (Jun 26 2020 at 14:30, on Zulip):

okay

nikomatsakis (Jun 26 2020 at 14:31, on Zulip):

@Santiago Pastorino maybe it'd be useful to list out the kinds of things we might want to do with these subteams, and I was going to ask @LeSeulArtichaut if they wanted to articulate why they thought it could be useful for prioritization

Santiago Pastorino (Jun 26 2020 at 14:31, on Zulip):

so project groups would be, thinks that definitely behave like projects and have an end and things that behave like an area but are just starting as an experiment that we may or may not want to hold in the future

Santiago Pastorino (Jun 26 2020 at 14:32, on Zulip):

nikomatsakis said:

Santiago Pastorino maybe it'd be useful to list out the kinds of things we might want to do with these subteams, and I was going to ask LeSeulArtichaut if they wanted to articulate why they thought it could be useful for prioritization

we could assing or ping github groups looking for people that want/can tackle issues related to the area they belong

LeSeulArtichaut (Jun 26 2020 at 14:32, on Zulip):

nikomatsakis said:

Santiago Pastorino maybe it'd be useful to list out the kinds of things we might want to do with these subteams, and I was going to ask LeSeulArtichaut if they wanted to articulate why they thought it could be useful for prioritization

Currently in the Prioritization procedure, we want to assign people to high priority issues, like P-critical and P-high regressions. This means that the WG should be able to find the right assignee for a given problem, and this "areas of the compilers" seems like a good way to achieve this.

LeSeulArtichaut (Jun 26 2020 at 14:33, on Zulip):

But I think @Santiago Pastorino is most likely to know what we need exactly for the Prioritization WG, as the leader of the group :D

Santiago Pastorino (Jun 26 2020 at 14:33, on Zulip):

same could happen on Zulip, like we saying hey do someone from @some-area knows about this problem

Santiago Pastorino (Jun 26 2020 at 14:34, on Zulip):

LeSeulArtichaut said:

But I think Santiago Pastorino is most likely to know what we need exactly for the Prioritization WG, as the leader of the group :D

nah you know too and are probably able to explain better than me ;)

nikomatsakis (Jun 26 2020 at 14:34, on Zulip):

Yeah. So if we had some notion of membership, ideally sync'd with zulip user groups... that woudl help.

nikomatsakis (Jun 26 2020 at 14:34, on Zulip):

ps I started taking notes at the end of the hackmd

Santiago Pastorino (Jun 26 2020 at 14:35, on Zulip):

also what we are saying per se, I don't think is a reason to split

Santiago Pastorino (Jun 26 2020 at 14:35, on Zulip):

because we may totally ping or ask the whole universe of members + interested people

nikomatsakis (Jun 26 2020 at 14:35, on Zulip):

we have traditionally been reluctant to let people add themselves as members until they've done some work

nikomatsakis (Jun 26 2020 at 14:35, on Zulip):

which is what led to the notification groups concept

Santiago Pastorino (Jun 26 2020 at 14:35, on Zulip):

I guess another aspect is r+ access or some github permissions

Santiago Pastorino (Jun 26 2020 at 14:36, on Zulip):

that may be a reason to split

Santiago Pastorino (Jun 26 2020 at 14:36, on Zulip):

I guess that depends if this kind of access are granted based on being compiler team contributor or maybe we want to give some based on area membership

Santiago Pastorino (Jun 26 2020 at 14:37, on Zulip):

like a member of traits area has commit access on chalk or stuff like that

nikomatsakis (Jun 26 2020 at 14:37, on Zulip):

right so currently e.g. for project groups I do tend to align write access to repos with membership

pnkfelix (Jun 26 2020 at 14:37, on Zulip):

that's a good reason

pnkfelix (Jun 26 2020 at 14:38, on Zulip):

though is part of goal

pnkfelix (Jun 26 2020 at 14:38, on Zulip):

that each subteam will have authority to grant write privileges?

pnkfelix (Jun 26 2020 at 14:38, on Zulip):

vs having to get membership approved at higher level?

pnkfelix (Jun 26 2020 at 14:38, on Zulip):

It may make some sense to at least get sign-off from a T-compiler lead...

pnkfelix (Jun 26 2020 at 14:39, on Zulip):

(as much as I hate to add layers of bureaucracy...)

Santiago Pastorino (Jun 26 2020 at 14:39, on Zulip):

well I guess it depends

nikomatsakis (Jun 26 2020 at 14:39, on Zulip):

I'm having some second thoughts about the framing of "subteams", unless we are shooting for more independent operation.

nikomatsakis (Jun 26 2020 at 14:39, on Zulip):

which I think maybe I was :)

Santiago Pastorino (Jun 26 2020 at 14:39, on Zulip):

pnkfelix said:

It may make some sense to at least get sign-off from a T-compiler lead...

maybe a member of an area knows way better about a specific crate of that area than a compiler member

nikomatsakis (Jun 26 2020 at 14:39, on Zulip):

I feel fairly comfortable with the idea of

nikomatsakis (Jun 26 2020 at 14:40, on Zulip):

e.g. @Wesley Wiser approving folks to review mir optimization PRs

pnkfelix (Jun 26 2020 at 14:40, on Zulip):

and we'll just trust that the write privileges are not otherwise abused, yes?

nikomatsakis (Jun 26 2020 at 14:40, on Zulip):

our current r+ privileges are always very broad, so far that's never been an issue

pnkfelix (Jun 26 2020 at 14:40, on Zulip):

true

nikomatsakis (Jun 26 2020 at 14:40, on Zulip):

I guess that having some notion of subteams like this could eventually give us a way to tweak that

nikomatsakis (Jun 26 2020 at 14:40, on Zulip):

but I'm not too worried about it tbh

nikomatsakis (Jun 26 2020 at 14:41, on Zulip):

I'd be worried more about people being confused

nikomatsakis (Jun 26 2020 at 14:41, on Zulip):

but given that we have a known problem of limited review bandwidth

nikomatsakis (Jun 26 2020 at 14:42, on Zulip):

while we don't just want to chuck reviews etc, it seems like finding ways to engage more people in reviewing is probalby a good thing overall?

nikomatsakis (Jun 26 2020 at 14:42, on Zulip):

something else I'm pondering is:

nikomatsakis (Jun 26 2020 at 14:42, on Zulip):

maybe I was wrong to say that areas should sometimes be dormant?

Wesley Wiser (Jun 26 2020 at 14:42, on Zulip):

It feels like there's a lot of similar concepts "teams" vs "working groups" vs "areas" vs "ping groups/notification groups".

pnkfelix (Jun 26 2020 at 14:43, on Zulip):

nikomatsakis said:

maybe I was wrong to say that areas should sometimes be dormant?

as in, we should schedule regular, if infrequent, checkins with all areas?

Wesley Wiser (Jun 26 2020 at 14:43, on Zulip):

Is the area group going to replace any of these other organizational things or is it just in addition to those?

pnkfelix (Jun 26 2020 at 14:43, on Zulip):

@Wesley Wiser I think part of idea is that WG's will go away

pnkfelix (Jun 26 2020 at 14:43, on Zulip):

eventually

nikomatsakis (Jun 26 2020 at 14:43, on Zulip):

I would say immediately

pnkfelix (Jun 26 2020 at 14:43, on Zulip):

because they are too ambiguous in purpose

nikomatsakis (Jun 26 2020 at 14:43, on Zulip):

like, if we adopt this, we'd just rebrand

nikomatsakis (Jun 26 2020 at 14:43, on Zulip):

and/or eliminate the dormant ones

pnkfelix (Jun 26 2020 at 14:44, on Zulip):

okay, I wasn't sure if we knew the mapping of WG -> { area/subteam, project } for all WG's

Wesley Wiser (Jun 26 2020 at 14:44, on Zulip):

Ok, that's helpful. Thanks!

Santiago Pastorino (Jun 26 2020 at 14:44, on Zulip):

reminder: ~ 15 minutes left

nikomatsakis (Jun 26 2020 at 14:44, on Zulip):

it kind of leaves us with

I think groups/teams have clear overlap :)

nikomatsakis (Jun 26 2020 at 14:45, on Zulip):

Though I'm not 1000% sold on this as the right dividing line. The old line was "team == decision maker", "working group == lightweight thing we create", and I see some logic in that too, but it seems like it has led to confusion.

nikomatsakis (Jun 26 2020 at 14:46, on Zulip):

I think that project groups are valuable to distinguish in that it's a great way to get people involved, it's kind of a bootstrapping thing, but the same is true of active subteams like mir-opt or prioritization.

nikomatsakis (Jun 26 2020 at 14:46, on Zulip):

so.. yeah. :)

pnkfelix (Jun 26 2020 at 14:48, on Zulip):

so I don't think anyone present has objected to the shift

nikomatsakis (Jun 26 2020 at 14:48, on Zulip):

anyway, I guess the terminology is one thing, but the other is the idea of formalizing a bit the idea of teams/groups around areas of the compiler and trying to integrate them usefully into our processes.

nikomatsakis (Jun 26 2020 at 14:48, on Zulip):

Yeah, we're just kind of left with some questions about membership and integration that I don't feel we have 100% decision on

nikomatsakis (Jun 26 2020 at 14:48, on Zulip):
nikomatsakis (Jun 26 2020 at 14:48, on Zulip):

those are my notes from the hackmd

Wesley Wiser (Jun 26 2020 at 14:48, on Zulip):

I feel like there's a bit of a hierarchy there:

with enough activity, notification groups can become a

which could eventually become a top level

Wesley Wiser (Jun 26 2020 at 14:48, on Zulip):

I don't know if that's helpful...

pnkfelix (Jun 26 2020 at 14:49, on Zulip):

except that that leaves out some groups

pnkfelix (Jun 26 2020 at 14:49, on Zulip):

that we are not sure about "regular meetings"

pnkfelix (Jun 26 2020 at 14:50, on Zulip):

like the LLVM-area/subteam

pnkfelix (Jun 26 2020 at 14:50, on Zulip):

Or perhaps you are saying that should instead be a notification group?

Wesley Wiser (Jun 26 2020 at 14:50, on Zulip):

Perhaps yeah

pnkfelix (Jun 26 2020 at 14:51, on Zulip):

@nikomatsakis what are your thoughts on that?

LeSeulArtichaut (Jun 26 2020 at 14:51, on Zulip):

Maybe also different groups have different needs. A way out of the questions about membership is to define "concepts" like "member" or "enthusiast" and groups pick from these concepts. That's probably kind of a naive thought :confused:

nikomatsakis (Jun 26 2020 at 14:51, on Zulip):

I'm pondering it. I'm wondering what teams we might see now -- perhaps none?

pnkfelix (Jun 26 2020 at 14:51, on Zulip):

I suppose if a group is not meeting regularly, then it may make sense to deem them notification groups

Wesley Wiser (Jun 26 2020 at 14:51, on Zulip):

I was just thinking about it more in terms of "activity" or "engagement". If we have a lot of stuff happening in a notification group, maybe that should become a project group?

nikomatsakis (Jun 26 2020 at 14:51, on Zulip):

I think notification groups really don't have "direction"

pnkfelix (Jun 26 2020 at 14:51, on Zulip):

right, its more just self-selected experts

pnkfelix (Jun 26 2020 at 14:52, on Zulip):

which I do think corresponds to the current LLVM subteam, right?

nikomatsakis (Jun 26 2020 at 14:52, on Zulip):

I agree with that

nikomatsakis (Jun 26 2020 at 14:52, on Zulip):

and indeed we have an LLVM notification group

nikomatsakis (Jun 26 2020 at 14:52, on Zulip):

they were even the first :)

pnkfelix (Jun 26 2020 at 14:52, on Zulip):

(not even experts, necessarily; just interested folks. Enthusiasts, etc)

pnkfelix (Jun 26 2020 at 14:52, on Zulip):

Right, its just labelled t-compiler/wg-llvm here on zulip

pnkfelix (Jun 26 2020 at 14:52, on Zulip):

and probably elsewhere

nikomatsakis (Jun 26 2020 at 14:52, on Zulip):

I guess I'm pondering whether we'd ever have multiple teams. Maybe the answer is "not yet but it might be something we work towards"

pnkfelix (Jun 26 2020 at 14:53, on Zulip):

maybe a prereq for multiple teams

pnkfelix (Jun 26 2020 at 14:53, on Zulip):

is distinct repos

pnkfelix (Jun 26 2020 at 14:53, on Zulip):

to better enable decoupling of work

pnkfelix (Jun 26 2020 at 14:53, on Zulip):

you know?

nikomatsakis (Jun 26 2020 at 14:53, on Zulip):

(I think e.g. the chalk effort could become like that, eventually)

nikomatsakis (Jun 26 2020 at 14:53, on Zulip):

here's another question:

pnkfelix (Jun 26 2020 at 14:53, on Zulip):

because when you share repos, you are forced to share protocols with respect to labels, issue handling, etc

nikomatsakis (Jun 26 2020 at 14:54, on Zulip):

I made this "starting list" of things that seemed like active areas to me

nikomatsakis (Jun 26 2020 at 14:54, on Zulip):
group lead(s) areas subsumes
diagnostics estebank diagnostic formatting code wg-diagnostics
mir oli-obk building MIR, optimizations, generator transform wg-mir-opt
codegen eddyb partitioning, debuginfo, type layout (this is new)
llvm nagisa LLVM-specific problems, ThinLTO, PGO wg-llvm
constant_evaluation oli-obk const_eval, miri t-compiler/
nikomatsakis (Jun 26 2020 at 14:54, on Zulip):

well, not "active" areas necessarily

nikomatsakis (Jun 26 2020 at 14:55, on Zulip):

but I think a question is -- how much do we shoot for comprehensiveness? or is it more about "we don't expect all areas to have a group, just those where there's somebody willing/able to do the work"?

nikomatsakis (Jun 26 2020 at 14:55, on Zulip):

(which I think might be a good principle, I'm worried we sometimes get overambitious)

nikomatsakis (Jun 26 2020 at 14:55, on Zulip):

in which case I would e.g. think we would drop codegen/llvm from the list (and yes maybe that is more of a notification group concept, and perhaps those are something we try to be a bit more comprehensive with somehow)

Wesley Wiser (Jun 26 2020 at 14:55, on Zulip):

"we don't expect all areas to have a group, just those where there's somebody willing/able to do the work"?

I think this is what I was trying to get at when I said "engagement".

davidtwco (Jun 26 2020 at 14:56, on Zulip):

(by the time I finished writing this, the conversation has moved on a bit :face_palm:: )

I think it might make sense to separate the granting of permissions from the groups.

You could keep the compiler team contributors (just r+) and compiler team (r+ and fcps, effectively) (or some equivalent to these):

And then the project/notification/subarea groups have some people that happen to be in the compiler team contributors/compiler team (perhaps through their work in the project/notification/subarea group) and have permissions. But there's no concept of being "a member of" one of those groups (in that you are granted some permissions as a result) but only in the sense that you contribute to that group regularly. Folks who contribute to those groups regularly can be added to compiler team contributors as is done now when it's felt that they should be granted permissions.

Wesley Wiser (Jun 26 2020 at 14:56, on Zulip):

If we have people consistently showing up to do stuff in a particular area, maybe it's worth trying to turn that into something more formal than just a ping group.

nikomatsakis (Jun 26 2020 at 14:57, on Zulip):

right and when I wrote this:

nikomatsakis said:

maybe I was wrong to say that areas should sometimes be dormant?

I was kind of thinking in a similar direction I thnk

nikomatsakis (Jun 26 2020 at 14:57, on Zulip):

specifically that I worry about having a variety of teams where some are dormant and some are not

nikomatsakis (Jun 26 2020 at 14:58, on Zulip):

and I think that one goal should be helping people to know what's going on and get involved

nikomatsakis (Jun 26 2020 at 14:58, on Zulip):

and that those efforts are impeded by not indexing on "activity and engagement"

nikomatsakis (Jun 26 2020 at 14:58, on Zulip):

so yeah I'm liking @Wesley Wiser's variant :)

nikomatsakis (Jun 26 2020 at 14:58, on Zulip):

(now I have to read the essay that @davidtwco wrote ;)

nikomatsakis (Jun 26 2020 at 14:59, on Zulip):

Side note: one thing I'm wondering about is how to make maintaing these lists relatively painless. And I also still do like the idea of e.g. mir-opt having members that can be approved to review PRs for that area. I remember wanting this pretty clearly for NLL.

nikomatsakis (Jun 26 2020 at 15:00, on Zulip):

Which I guess is somewhat in contrast to what @davidtwco wrote

nikomatsakis (Jun 26 2020 at 15:01, on Zulip):

one other thing: I used to think we should not track working group "membership", but I've changed my mind, in part because it's useful to be able to give privileges, ping groups of folks, etc but also because I think it's important to recognize and reward participation

LeSeulArtichaut (Jun 26 2020 at 15:01, on Zulip):

nikomatsakis said:

Side note: one thing I'm wondering about is how to make maintaing these lists relatively painless. And I also still do like the idea of e.g. mir-opt having members that can be approved to review PRs for that area. I remember wanting this pretty clearly for NLL.

I guess there's one caveat, about what to do with PRs that affect multiple areas? Or maybe I'm misunderstanding here.

Wesley Wiser (Jun 26 2020 at 15:01, on Zulip):

I think maybe another positive to incorporating the "activity and engagement" idea is that it lends to a natural way to spin down groups. As activity slows, they would naturally move down the "hierarchy" of groups. IE a dormant project group would eventually just become a ping group.

That wouldn't be a "failure" or whatever of the group or its leaders, just a natural part of the lifecycle of the project. If interest picks up later, it can be turned back into a group.

nikomatsakis (Jun 26 2020 at 15:01, on Zulip):

at the same time, it is a bit of extra reponsibility and sometimes a bit hard to decide who to add -- how many PRs is enough, etc.

nikomatsakis (Jun 26 2020 at 15:02, on Zulip):

LeSeulArtichaut said:

I guess there's one caveat, about what to do with PRs that affect multiple areas? Or maybe I'm misunderstanding here.

I think you would just try to also get a review from people who know the other areas, or maybe just a review. I mean we sort of have that same problem today, we just don't acknowledge it very much. :)

nikomatsakis (Jun 26 2020 at 15:02, on Zulip):

Wesley Wiser that works for some cases I think but not e.g. polonius or other efforts, but that's ok.

LeSeulArtichaut (Jun 26 2020 at 15:03, on Zulip):

nikomatsakis said:

LeSeulArtichaut said:

I guess there's one caveat, about what to do with PRs that affect multiple areas? Or maybe I'm misunderstanding here.

I think you would just try to also get a review from people who know the other areas, or maybe just a review. I mean we sort of have that same problem today, we just don't acknowledge it very much. :slight_smile:

Hmm, that was kind of what I was expecting. I was wondering if you were talking about responsibilities or explicit permissions e.g. for only a particular directory.

nikomatsakis (Jun 26 2020 at 15:03, on Zulip):

ok, I have to run, this was a productive and thought-provoking meeting though

nikomatsakis (Jun 26 2020 at 15:04, on Zulip):

one parting thought never mind

Wesley Wiser (Jun 26 2020 at 15:05, on Zulip):

/me the suspense :scared:

Santiago Pastorino (Jun 26 2020 at 15:06, on Zulip):

the parting thought I'm sure was going to be mind blowing and you @Wesley Wiser would never know what it was :smiling_devil:

nikomatsakis (Jun 26 2020 at 15:07, on Zulip):

well geez I'm definitely not sharing it NOW

nikomatsakis (Jun 26 2020 at 15:07, on Zulip):

I wrote up some final notes in the hackmd fyi maybe check 'em out ;)

nikomatsakis (Jun 26 2020 at 15:08, on Zulip):

I do have to go but what I was going to say was that maybe this fits with the idea of all teams having (potentially)

and the idea is then that we kind of "layer on top" progressively more things

nikomatsakis (Jun 26 2020 at 15:08, on Zulip):

i.e., notification groups are just the first, full members/leads come with project group status, and the final thing would be "team" status

nikomatsakis (Jun 26 2020 at 15:08, on Zulip):

(I'm thinking of the team repo)

davidtwco (Jun 26 2020 at 15:11, on Zulip):

One thing I'm unclear of - how would this change the "compiler team {, contributors}" teams?

pnkfelix (Jun 26 2020 at 15:12, on Zulip):

my guess is that contributors would become notification members?

pnkfelix (Jun 26 2020 at 15:12, on Zulip):

but maybe that doesn't carry same weight

pnkfelix (Jun 26 2020 at 15:12, on Zulip):

maybe we would just keep contributors as its own thing

pnkfelix (Jun 26 2020 at 15:13, on Zulip):

just to serve as a good "stepping stone" towards full team membership

simulacrum (Jun 26 2020 at 15:44, on Zulip):

I think there's an intermediate "r+ but no FCP" state that's useful

Last update: Nov 25 2020 at 03:00UTC