-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should we track incomplete ideas here instead of in the rust issue tracker? #158
Comments
I'm not sure about where pure unbaked design discussion should go. Consensus seems to be that the issue tracker is not the right place these days to be having that kind of speculative conversation, but here is also not a good place to be refining a design - it's better to have a solid design with some early consensus before launching an RFC. My current preference is to try to move design discussions to http://discuss.rust-lang.org. We've set this forum up as a place where we can have discussion about the development of Rust itself (as the mailing list is too user-centric at this point to continue having reasonable design discussions). |
I do not see why discuss.rust-lang.org would be favored over reddit. |
Reddit is not particularly well suited for long-term discussion of something. |
is discourse? It has the same longevity that reddit does, and it gets overshadowed by new threads just as much as reddit. |
The discussion list in discourse is ordered by update time, where Reddit is ordered by "hot" by default, which heavily favors new content. |
The way I see it for long term discussion on reddit is that people who weigh in have done so by the day that it has been on the front page of the subreddit, and after that, people get notifications for replies, keeping them in the conversation. But you're right, thats definitely a reason for discourse, I just don't like splitting the community further. |
Discourse also has an email gateway and tagging of discussions. |
What sort of design discussions are we thinking about? I thought the recent discussion about integer overflow on the ML went pretty well. (But maybe there's other kinds of things it would be less appropriate for, though I can't think of specific counterexamples at the moment.) |
My perspective is that rust-dev is moving to service the broader Rust I honestly don't know what place the ML has between these two resources. On Tue, Jul 8, 2014 at 12:31 AM, Gábor Lehel [email protected]
|
If http://discuss.rust-lang.org should be used, shouldn't it be linked to from http://rust-lang.org and in the /r/rust sidebar? |
I don't really trust reddit comment threads for any long discussions. Until it's a one-on-one thing where you keep getting tagged by replies, it's basically impossible to come back to a comment thread and figure out which posts are new. It seems fairly standard to split mailing lists into "user-facing" and "internal", just like |
After dwelling on it, I think a separate venue like discuss.rust-lang.org would need to have very significant technical advantages to outweigh the drawback of splintering communications into yet another forum. I already have to keep tabs on rust-dev, reddit, here, and the main Rust repository, and IRC is already too much bother; I don't want another. I also suspect fewer people would end up frequenting it than any of the others: everyone uses e-mail, and lots of lots of people are on GitHub and redmine, while this one is standalone. Why not (as suggested in the OP) just have not-yet-ready-for-an-RFC discussions here, but in ordinary issues rather than on PRs? |
Closing. discuss.rust-lang.org is the answer for now. |
impl Debug for SendError
Over the past couple of years, we've had a number of rust tickets that hypothesize "if we had feature X, we could design an API like this", where we have an idea, but we're not ready for an RFC. For example:
We also have had a number of these thought experiments in IRC, which were never captured and probably forgotten.
Does it still make sense to track these features in the rust issue tracker? It's rather easy for these threads to run on for years and for them to get lost in the noise. I think it might make more sense to have those conversations over in this repository. That would make these a bit easier to discover and track their current state of conceptualization. It would also make it easier to close these conversations down if we decide to never go in that direction.
The text was updated successfully, but these errors were encountered: