Open KodrAus opened 6 years ago
So, I have read @quodlibetor's notes, but I'm not quite sure where technical discussions should take place at the moment. Should there also be a tracking issue at the chrono repository? Or perhaps the new RFC repository? I'm a bit confused about what belongs in which repository, since according to the latter, we are invited to "open tickets / PRs, no matter how minor". I suppose that only major suggestions to the crate would require an RFC, right? :)
I agree that a gitter channel would be useful, as it often leads to a faster exchange of ideas without making issues too noisy.
For long term planning or just brainstorming I think I would prefer putting that in the RFCs repo. And yes you should feel free to open any tickets you want in there.
I'll create a gitter channel as well. I'm imagining treating the RFCs repo as sort of a forum, for now, to work around the lack of better channels. I'm open to ideas for better channels -- I'm concerned that creating a tag for chrono in urlo would be too noisy for people there, but I would welcome the extra input if people think that would be reasonable. I'm also open to other ideas.
I purposefully left my planned solutions out of my notes document so that people would feel free to propose their own, without thinking that the plan is figured out. So: any kind of brainstorming ticket would be fine there. I would prefer to keep chrono itself focused on current issues: bugs, PRs, support, etc.
chrono
is one of the top 100 most depended on crates, and the most popular datetime library for Rust. It needs more support to revamp the API, answer open design questions and work towards a stable release.@quodlibetor How could we best support
chrono
? I've got a few notes I thought I'd just drop in to get the ball rolling. A lot of this might've already crossed your mind!There are some simple things we could put in place in preparation for more maintainers coming on board, like setting up a dedicated gitter channel, and maybe bors.
Would you like some more input from the community on where current deficiencies are and what a stable
chrono
should look like? Would you prefer to cover the design space yourself more before looking for input? I think the RFCs repo you set up is great :+1:A library evaluation using the API Guidelines as a checklist might not be very useful right now if the API is going to change a lot, but having that place for active and unstructured design discussion could be really worthwhile at just about any stage of your revitalisation effort.
It looks like we've got some idea of where
chrono
is now and wherechrono
should end up which should be really helpful for framing an evaluation/design thread (whatever shape that would end up taking). Perhaps we could flesh that out into some concrete RFC with a rough roadmap first?Does anyone have any other thoughts?
I'm really excited to see
chrono
get some dedicated maintainership again! Thanks @quodlibetor for taking it on!