This repository was archived by the owner on Oct 30, 2019. It is now read-only.
Repository navigation
This repository was archived by the owner on Oct 30, 2019. It is now read-only.
Sprint #1 goals #96
Description
During today's meeting we agreed it might be useful to start planning our work in multiple-week sprints. This is the tracking issue for the first sprint.
There's 2 questions around the sprint:
- how long should sprints be?
- what should the goals be for this first sprint?
The current proposal is to have 6 weeks per sprint, similar to Rust's release cadence. But we're not sure yet what the goals should be. If you have any ideas, sharing input in this issue would be fantastic. Thanks!
Activity
davidbarsky commentedon Mar 8, 2019
I think it might be helpful to see where the Futures stabilization is, and if this working group can make progress on driving the futures stabilization forward.
(I originally posted this on the RFC, not here. Oops.)
yoshuawuyts commentedon Mar 11, 2019
@davidbarsky that's a great question! I'm not sure how much we can do right now, as that currently seems to fall more under the umbrella of the async foundations WG. We've talked about doing checkin meetings between the async foundations and async ecosystem working groups. I'll update the working group once the status changes.
I've also added
futures + async/awaitas a recurring item to the agenda so we can keep tabs on it as things change. I don't know if this is the right format, but I think it's worth trying.Hope this is somewhat useful!
gruberb commentedon Mar 11, 2019
Just to dump out my thoughts (I just started working on Tide). So this is all from a newbie perspective:
I see tide, areweasyncyet and arewewebyet as the "core products". When I recommend people Rust for the web, I have to guide them to rocket or actix, which are not as clean and straigh forward as tide.
So I see this working group as the starting point of all things concerning web in Rust. Therefore I would have a goal in mind (I don't know if it's 6 week but we can get started in the first spring) to clean things up and make it presentable.
masterin the next 6 weeksAreas
utilmodule instead ofheadandbody?These are just very rough thoughts. I am building a web app with tide at the moment and these are the areas I found the most challenging. Both from an entry perspecitve (READMEs, tutorials, old issues and stalled PRs). It generally doesn't look very active.
From an implementation point of view, we could work up the stack and make sure these areas are "version 1 solid" and presentable.
I think rounding things up would make it feel that a MVP is ready, that we can build and ship apps with it, and have areweasyncyet and arewewebyet as our additional supporters.
Both from an implementation point of view, but also from a presentation point of view.