What I wanted to say about sprints, @davidtwco, was that I also don't necessarily want to impose it, or be too strict about it, but I think it's probably something that will evolve semi-naturally, at least for longer-running groups. In particular, I think it's really useful to be able to stop, spend some time assessing where you are, writing mentoring instructions, putting up a public post announcing what's been happening, and calling for contribution, and that seems to fit a 'sprint-like' structure pretty well.
This is precisely what I had imagined the "compiler-team triage checkins" being, and maybe it should play that role, but maybe it's something that wants to be distinct. Not sure. I guess I feel like I'd like to try it in some working groups and see how we feel. :)
That all makes sense. I think if that sort of workflow naturally evolves then we can document and provide some guidance about what has worked for other working groups.
(OTOH if it is working, maybe imposing it lets us build it into our meeting strucure, which might be helpful, idk)
anyway, gotta go do other things :)
I've been thinking about this. I don't feel great about trying to have a fixed "sprint timeline" and so forth, but I think encouraging people to outline a roadmap with specific steps is a good idea, and I think it would be nice to kind of ensure that the roadmap is periodically updated.
To this end, I was wondering if an obvious step would be to make a ROADMAP.md file in each working-group directory that outlines the rough "phases" of the project and where things are.
I also think it's going to be something that potential contributors would like to look into.
(Before adding to the template, I would want to create these for some actual working groups)