Stream: t-compiler/wg-meta

Topic: compiler team officers


nikomatsakis (Dec 10 2020 at 13:42, on Zulip):

So I've been talking to @Wesley Wiser and @pnkfelix about this idea I had for how to reorganize the compiler team. I created a hackmd that contains the current iteration of the proposal (thanks to both of them for ideas). I'd love feedback on it!

The base idea is

nikomatsakis (Dec 10 2020 at 13:42, on Zulip):

cc @T-compiler/WG-meta

nikomatsakis (Dec 10 2020 at 13:43, on Zulip):

one thing I wanted to do is to review the notes from this old steering meeting on 2019-03-22 to see whether there are ideas for other officers in there

nikomatsakis (Dec 10 2020 at 13:43, on Zulip):

I'm not sure if the 'term of office' is right -- 1 year might be better than 2 years

nikomatsakis (Dec 10 2020 at 13:43, on Zulip):

but it would imply elections every 6 months

Santiago Pastorino (Dec 10 2020 at 13:44, on Zulip):

what you've said here sounds interesting, gonna read the hackmd after the meeting

Joshua Nelson (Dec 10 2020 at 13:44, on Zulip):

(this was my first question so just highlighting it: https://hackmd.io/S9xqmwJbSI-a9mFdK9yQBA#Motivation)

davidtwco (Dec 10 2020 at 14:00, on Zulip):

I really like the idea - two things that I think are worth discussing regarding technical leads:

In both of these cases, I trust the compiler team and contributors to rely on our experts and make efforts to consider dissenting opinions, so I'm not sure the extent to which that needs addressed explicitly in the proposal (if at all).

nikomatsakis (Dec 10 2020 at 14:17, on Zulip):

The first point is one that I was considering too

nikomatsakis (Dec 10 2020 at 14:17, on Zulip):

And to some extent the second one :)

nikomatsakis (Dec 10 2020 at 14:17, on Zulip):

I definitely think having a smaller set would mean that we ought to make sure that we actively seek input from the compiler team members

nikomatsakis (Dec 10 2020 at 14:18, on Zulip):

And I would think we should set some expectations that input or concerns from compiler team members are not lightly ignored

nikomatsakis (Dec 10 2020 at 14:18, on Zulip):

That said, I think it'd be useful -- particularly in more controversial cases -- to have a smaller set of designated deciders

nikomatsakis (Dec 10 2020 at 14:18, on Zulip):

Sometimes "somebody needs to make a call"

nikomatsakis (Dec 10 2020 at 14:18, on Zulip):

As for the ideas of people in particular areas, you may remember an earlier proposal I had for compiler areas

nikomatsakis (Dec 10 2020 at 14:18, on Zulip):

and I was wondering if it made sense to incorporate that into this one, or hold it separate, but it was definitely on my mind

nikomatsakis (Dec 10 2020 at 14:19, on Zulip):

I still like the idea of us creating areas with a bit more designated structure, effectively sort of subteams

nikomatsakis (Dec 10 2020 at 14:19, on Zulip):

(I remember @Wesley Wiser had some good thoughts on that too)

nikomatsakis (Dec 10 2020 at 14:19, on Zulip):

one option would be to separate this proposal -- maybe just create the elected officers

nikomatsakis (Dec 10 2020 at 14:19, on Zulip):

and decide about the merging of members/contributors and FCP later

nikomatsakis (Dec 10 2020 at 14:19, on Zulip):

(and/or have a smaller set of officers)

simulacrum (Dec 10 2020 at 14:29, on Zulip):

I am strongly in favor of 2-3 people being the "council" or whatever for decisions like the directory renaming etc, where input is great but consensus is hard

davidtwco (Dec 10 2020 at 14:35, on Zulip):

I agree with all of that (both nikomatsakis and simulacrum). Those officers as decision-makers for hard-to-reach-consensus issues makes a bunch of sense, and still implies to me that there's still autonomy within the team to make the majority of decisions where there isn't any disagreement.

One minor nit then: I think that the description is good as written, but that "technical lead" as a title might imply more responsibility than the description.

Wesley Wiser (Dec 10 2020 at 14:45, on Zulip):

One thing I do really like about the contributors "role" today is that it's a clear stepping stone from "random person who submits PRs" to compiler team.

Wesley Wiser (Dec 10 2020 at 14:46, on Zulip):

I think both in terms of on boarding new people to the compiler team as well as giving recognition to people who are consistently contributing it's important to have some kind of milestone there.

davidtwco (Dec 10 2020 at 14:53, on Zulip):

I think the compiler team itself would serve that purpose under this proposal. Unfortunately, that does mean that there wouldn't be any clear indicator of the experience/seniority that the current compiler team contributor/member distinction provides.

Joshua Nelson (Dec 10 2020 at 15:06, on Zulip):

I remember I was shocked to discover @Aaron Hill is only a contributor, they make so many PRs :laughing: and hard ones too

nikomatsakis (Dec 10 2020 at 15:28, on Zulip):

So, we could keep the two-step process

nikomatsakis (Dec 10 2020 at 15:28, on Zulip):

I think that if we had this officer setup

nikomatsakis (Dec 10 2020 at 15:28, on Zulip):

we might move faster to promote people to member

nikomatsakis (Dec 10 2020 at 15:28, on Zulip):

but yes my idea was that you would join the compiler team much faster

davidtwco (Dec 10 2020 at 15:32, on Zulip):

Alternatively, we could keep track of "years of service" next to a team member on the website (or something like that). It's admittedly small but still provides some recognition for people who've been contributing for a long time and who are compiler time members today as they'll typically have more years as members.

simulacrum (Dec 10 2020 at 15:32, on Zulip):

I actually think contributors should be kept and the compiler team should be smaller

simulacrum (Dec 10 2020 at 15:32, on Zulip):

i.e., the people with checkboxes might be a rotating set

simulacrum (Dec 10 2020 at 15:33, on Zulip):

but I would not add people to the RFC tickbox list just based on a length of service or w/e

simulacrum (Dec 10 2020 at 15:33, on Zulip):

I think there's .. other considerations, such as ability to roadmap plan, leadership/mentoring of contributors, etc

nikomatsakis (Dec 10 2020 at 15:35, on Zulip):

the RFC tickbox list in this proposal is an elected position

nikomatsakis (Dec 10 2020 at 15:35, on Zulip):

and not based on years of service

davidtwco (Dec 10 2020 at 15:35, on Zulip):

simulacrum said:

but I would not add people to the RFC tickbox list just based on a length of service or w/e

That's not what I meant - we'd still elect officers for things like that, as per Niko's proposal - and that would mean that membership to the compiler team would be a slightly lower bar (because it isn't adding a FCP checkbox any more). One way to address the concern that only having the compiler team (and not the separate contributors group) removes the distinction that the contributor/member groups today creates (that of seniority/expertise) would be to list "years of service" next to people's names on the site - which is small, but it's the type of thing that we could do.

simulacrum (Dec 10 2020 at 15:36, on Zulip):

ah, ok, then I have no objection :)

Santiago Pastorino (Dec 10 2020 at 15:44, on Zulip):

well, have just read all this and I pretty much like all ideas I'm reading :)

Santiago Pastorino (Dec 10 2020 at 15:44, on Zulip):

I'd also keep the members and contributors list

Santiago Pastorino (Dec 10 2020 at 15:45, on Zulip):

mainly because I think it would be nice if we can quickly promote more people to contributor list

Santiago Pastorino (Dec 10 2020 at 15:45, on Zulip):

and then if people keep working and doing good job move them to full members

simulacrum (Dec 10 2020 at 15:46, on Zulip):

what would the distinction be under this proposal?

davidtwco (Dec 10 2020 at 15:46, on Zulip):

Just to clarify, I don't feel particularly strongly about keeping the member/contributor split one way or another.

Santiago Pastorino (Dec 10 2020 at 15:51, on Zulip):

simulacrum said:

what would the distinction be under this proposal?

I guess it depends what do we exactly want but my guess is that if you only have one time you're not going to promote somebody to be full compiler member because they did 10 good PRs

Santiago Pastorino (Dec 10 2020 at 15:51, on Zulip):

and maybe that person could be given the compiler contributor membership status

simulacrum (Dec 10 2020 at 15:51, on Zulip):

I think 10 PRs is too low a bar for r+ rights personally

simulacrum (Dec 10 2020 at 15:51, on Zulip):

I don't know

simulacrum (Dec 10 2020 at 15:51, on Zulip):

we've been lax historically but it's complicated

Santiago Pastorino (Dec 10 2020 at 15:53, on Zulip):

well I don't know either :), was kind of loudly thinking but I don't have very strong opinions neither

Wesley Wiser (Dec 10 2020 at 16:07, on Zulip):

In my mind currently, "contributors" means we trust you to review code and use project resources like CI and perf responsibly while "compiler team" means we trust you with making decisions about the direction of the compiler project.

Wesley Wiser (Dec 10 2020 at 16:07, on Zulip):

Perhaps with the TSC that distinction matters less.

simulacrum (Dec 10 2020 at 16:53, on Zulip):

yeah

Léo Lanteri Thauvin (Dec 10 2020 at 19:03, on Zulip):

What are/would be the duties of the prioritization WG leads?

Santiago Pastorino (Dec 10 2020 at 20:18, on Zulip):

Wesley Wiser said:

In my mind currently, "contributors" means we trust you to review code and use project resources like CI and perf responsibly while "compiler team" means we trust you with making decisions about the direction of the compiler project.

I guess the difference, as stated today, would be the ability to vote?

Santiago Pastorino (Dec 10 2020 at 20:18, on Zulip):

Léo Lanteri Thauvin said:

  • The prioritization working group lead (2): Leads of the prioritization working group, which judges which issues are important and prepares the agenda

What are/would be the duties of the prioritization WG leads?

I imagine the same we currently have :)

DPC (Dec 10 2020 at 20:45, on Zulip):

I like the idea, though it is also worth considering the extra baggage the process adds (running elections, etc)

scottmcm (Dec 10 2020 at 21:11, on Zulip):

I'm just peanut gallery here, but since "lots of checkboxes" was mentioned above, I wonder if abstaining could be made a more first-class action for FCPs. Then more people could be on them, but for things outside the area of expertise there'd be a low-effort response option to leave it up to those more interested in the area.

simulacrum (Dec 10 2020 at 21:20, on Zulip):

I'll note that at least for some teams (maybe not T-compiler) abstaining is difficult because that may mean you end up with 1-2 people having knowledge and making many decisions, e.g. t-lang I could imagine easily running into this. I think it's worthwhile to try to identify why you have lack of knowledge in a large set of the team if that's the case and tackling that more directly. (Better explanation of the change, for example)

scottmcm (Dec 10 2020 at 21:35, on Zulip):

Agreed. The number of explicit "yes"s would need to be tuned appropriately. And FCPs do already have de-facto abstains, with the "can go into FCP without all the checkboxes", so that can already exist to some extent.

Your comment also makes me think that I'm also slightly mixing it with a sortof "delegation", in my head. Which I guess is similar to electing officers, in a way. But I'd been thinking of it also as the difference between "I've read over it and it seems well motivated and a solid solution, and I trust that the original-author/working-group/team-member to have considered the nuances well so it's good by me even if I don't feel strongly about it" and "yes, I really want this and I've personally dug into this deeply and tried it out and completely followed all the sequent calculus" or whatever.

nikomatsakis (Dec 11 2020 at 10:44, on Zulip):

Wesley Wiser said:

Perhaps with the TSC that distinction matters less.

This is what I am going for

nikomatsakis (Dec 11 2020 at 10:45, on Zulip):

scottmcm said:

But I'd been thinking of it also as the difference between "I've read over it and it seems well motivated and a solid solution, and I trust that the original-author/working-group/team-member to have considered the nuances well so it's good by me even if I don't feel strongly about it"

I definitely like the idea of making this distinction explicit

nikomatsakis (Dec 11 2020 at 10:45, on Zulip):

I think it'd be an interesting flag if all the boxes but 1 or 2 are checked this way

nikomatsakis (Dec 11 2020 at 10:46, on Zulip):

i.e., we could have a rule that it sort of requires some number of "explicit reviews" and some number of "delegations"

nikomatsakis (Dec 11 2020 at 10:46, on Zulip):

that said, I think this is more of a problem for lang than compiler? maybe not

nikomatsakis (Dec 11 2020 at 10:46, on Zulip):

I definitely delegate on both frequently enough

nikomatsakis (Dec 11 2020 at 10:47, on Zulip):

DPC said:

I like the idea, though it is also worth considering the extra baggage the process adds (running elections, etc)

So my hypothesis -- and I would like to know if others share it -- is that having elections and official titles will help to motivate people to get more involved. In other organizations I'm involved in, I can definitely say that knowing that "I am the treasurer" (or whatever) both helps me to define a kind of upper and low bar for how much work I have to do. i.e., if I do my treasurer duties, I am doing a good job. If I fail to do them, I'm slacking off. If I do other stuff, that's great, but not required.

nikomatsakis (Dec 11 2020 at 10:47, on Zulip):

I can definitely imagine somebody thinking hard, committing to serve as X lead, and then getting more engaged as a result than they would otherwise be.

Wesley Wiser (Dec 17 2020 at 14:30, on Zulip):

I'm wondering if we should have a role/officer position for triage. There's certainly some overlap with the prioritization position but I'm imaging this would perhaps be more focused on performing the actual backports or potentially even running the weekly triage meeting.

In terms of what the compiler team does week to week, triaging is one of the biggest recurring activities.

simulacrum (Dec 17 2020 at 14:38, on Zulip):

With regards to backports, I do not usually need much help - and the process is pretty well documented and straightforward - it would be great for us to explicitly e.g. bless the technical leads with individual approval power when we're in a rush. Today it ends up that mostly I try to ping and end up unilaterally approving sometimes which is not great.

Wesley Wiser (Dec 17 2020 at 15:23, on Zulip):

That's good feedback, thanks @simulacrum!

Last update: Jan 22 2021 at 12:30UTC