So I just merged rfc#2909 (@varkor's RFC on "destructuring assigment"). There is a tracking issue https://github.com/rust-lang/rust/issues/71126. I'd like to track this on the project board. I am debating whether to create a "project group" issue for it or add the tracking issue. @Josh Triplett I think you expressed the idea that we should be more uniform, which I'm inclined to agree with, but I am not sure the best way to resolve this overall discrepancy =)
(Also, this is not exactly a project group I suppose)
I think being more uniform is nice, but I am pretty strongly opposed I think to calling things project groups unless they actually are :)
That said, I think it's totally reasonable if e.g. @varkor and a liaison from the lang team form a tiny project group.
Happy to do whatever is most convenient for the lang team.
Yeah so I think what I'd like is to rename the project-group label to just project
actually I don't know if I'd like that :)
but I've wrestled some with this question -- actually @Josh Triplett and I sketched out a bit in our last call and I thought we were getting to some useful distinctions, the idea being to separate out a bit better the phases and steps between them
but I think in general I'm a bit annoyed about the duplication between various kinds of "tracking issues"
I'm all for just making it "project".
the other option is just to use tracking issues directly
if we don't then .. what is the role of the tracking issue vs project issue?
I guess I see it as kind of useful to have the "clean issue" and also the "lang team specific comments"
but thus far we've not gotten into much of a rhythm around liaisons actually posting updates in advance of the meeting
I suppose maybe I can do a better job actively pinging people and requesting that
I don't relish the idea of creating a bunch of project issues, one for each unstable tracking issue
otoh it might be useful
I've been liking the "talk about this on Zulip or a dedicated issue, not this tracking issue" part of a bunch of these. Maybe we could just make that the all-up policy for tracking issues?
I think so long as they avoid the floods of messages they're ok.
I'm liking the "post summaries to github and everything else to Zulip" approach.
I think the second bit may not be "to Zulip" necessarily, but I think I do really like "everything else not on the issue" bit.
yes strong +1 on this
I really dislike how tracking issues track a bunch of random comments and questions
at the same time, there does need to be a venue for folks to raise them
it is true that if these all become active projects, they would have associated streams
which helps somewhat
I am a bit worried about how lang-team project issues are a kind of "silo", too
I'd particularly like to consolidate with libs/compiler practice a bit
e.g., if there is a joint lang-libs project, does it need two issues? or just one?
just one feels right
presumably with roughly 2 weekly-ish comments, from the team(s)
One sounds great, and it can be on two tracking boards if need be.
One Zulip stream as well.
Last updated: Jan 26 2022 at 08:34 UTC