Google Drive
Gist
Clipboard
Niko notes:
Also, might be good to better define the exact roles of the leads. There may be other roles to split those responsibilities (e.g. Project Manager)
Compiler team has the senior/junior model, which has worked fairly well. Niko proposes this.
Jack: Could have one lead be more organizational, one lead be more technically oriented.
NM: I like the ops team model. The leads manage the technical side. But the ops model spreads around more of the other work.
NM: I view leads as more project managerial anyway, though there is a bit of "if things go wrong, helping to sort it out".
Jack: I try to always prepare the doc for the planning meetings. For a while we were trying to get meeting minutes into the github.
NM:
Specific tasks outlined in the RFC:
Other tasks:
Team membership:
Digression about compiler team and how decision making is hard, especially because of the broad range of the team areas. Not always a great way to handle cases where a subset of the team is an expert on some particular thing. Given a complicated issue – can we allow some sort of explicit +0 delegation?
What about as types team grows? Will we come up with something similar. Jack: it would be nice if e.g. contributors team could raise objections, like the lang-team advisors.
Becomes more relevant as the team grows, and you get people who are deeply.
Niko: I propose tabling but maybe this should be a topic for future, do we want subgroups etc?
jack: ok, so leads, if it is a project manager thing, and we are talking about project manager.
errs: let's not look for volunteers without the full membership. But we can ask in the abstract.
nikomatsakis: I'd be happy to see other people pick it up; I'm also happy to put time into it. There would be some value to write out the tasks in more detail. Do we feel the current NM
did not work out :) doing it at the start of the meeting now.
- What was the plan at the start of the month (list of goals)?
- What happened? (brief narrative)
- What is the plan for this month (list of goals)?
We don't have that format, do we want to try to follow it going forward?
Jack: I had a plan to make a triagebot PR so we can make an agenda, I started labeling issues, tried to make it more automated… it'd be nice if we could just, a week before the meeting, have to automatically generate and get things filled out.
NM: We've tried various things and this has always been difficult. The list of initiatives gets long, maybe we need to focus it more narrowly.
CE: The working group structure doesn't necessarily map well to what work is underway.
NM: A bot could help here. People are reluctant to close someone else's initiative. But a bot could do this.
Jack: I'm not sure the list of initiatives is that long. And seeing the list helps us keep track of maybe what we should get back to. As long as we don't overburden ourselves by doubling the list, it helps us track what might need to happen.
NM: Writing progress reports does help, in my experience, to help push me to do the final 5% of certain projects.
Jack: What should we do?
NM: Maybe a bot that pings people in Zulip and then you could go to the issue and see the updates. Maybe on a cadence of once a week or once per two weeks to prompt people to publish updates.
Jack: It can be nice to have things in one document.
NM: This is the job of the triagebot.
Jack: It'd be nice if the tracking issues had comments as updates.
NM: That's how I imagine it.
Jack: +1, but someone has to do it.
NM: In the interim, we could do it by hand.
NM: Let's investigate if there is a Zulip bot that can schedule messages?
Oli: Who is going to do that?
NM: Not seeing one is a quick search. Historically, triagebot needed a cron functionality, and no-one has done that yet.
Oli: We use a GitHub action for this in Miri. It's scheduled to run on a fixed cadence.
Jack: I'll own this. But someone remind me.
TC: Can infra team add some kind of cronjob that runs triagebo, as triagebot already runs in the infrastructure?
jack: I'll figure it out.
lqd: Ask Jakub (kobzol) on infra team.
Where does const-eval fit in?
Should update the https://github.com/rust-lang/types-team README to reflect reality.
NM: Ideally a-mir-formality would be normative, spec writers would find out how to interact with that.
NM: It'd be nice if the spec gave requirements/invariants that something like a-mir-formality would provide the detail for.
CE: We should say what we think the spec should include or not include because we're the ones on the hook. The level at which you document something is a decision in and of itself.
NM: There is a discussion to be had.
NM: This is something I wanted to bring up. In T-lang, we sometimes kick things over to T-types. Is that working?
lcnr: Not clear distinctions – we always ping the other team if there's an uncertainty.
CE: It'd be nice to know with more certainty when T-types can make a unilateral decision. There can be delay in nominating things for T-lang just to check.
NM: We don't have an official way to nominate with urgency. The ops work that TC has being doing has been a help here.
TC: People have been reaching out to point out when there are urgent issues.
NM: Can nominate and not block.
CE: That's probably what I should be doing.
lcnr: Does T-lang look at closed nominated issues?
TC: For T-lang, triagebot does not currently add those to the agenda.
CE: Hearing NM say this is what I've been waiting for.
NM: I feel it's within my power as lead to say this is the right answer.
NM: We don't have a triage meeting. We tried to do it async.
CE: We should be sweeping through everything that doesn't get attention.
Jack: I think we're getting better at this.
CE: We're actually pretty good at responding to P-critical-esque issues.
NM: In the planning meeting, we've been: 1) doing status on initiatives, 2) doing a backlog bonanza; trying to keep an SLA…
lcnr: Would hope we can get through all nominated issues every planning meeting.
NM: It'd be nice if T-lang nominations resulted in an automatic Zulip thread.
TC: The calls for the triage meetings work well for T-lang. Is that something we'd want to consider?
(Discussion about the pros and cons.)
CE: I'm in favor, but we should discuss this with the full team.
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe