Skip to content
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

Closed
erickt opened this issue Jul 7, 2014 · 13 comments
Closed
Labels
T-core Relevant to the core team, which will review and decide on the RFC.

Comments

@erickt
Copy link

erickt commented Jul 7, 2014

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.

@brson
Copy link
Contributor

brson commented Jul 7, 2014

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).

@sinistersnare
Copy link

I do not see why discuss.rust-lang.org would be favored over reddit.

@sfackler
Copy link
Member

sfackler commented Jul 8, 2014

Reddit is not particularly well suited for long-term discussion of something.

@sinistersnare
Copy link

is discourse? It has the same longevity that reddit does, and it gets overshadowed by new threads just as much as reddit.

@sfackler
Copy link
Member

sfackler commented Jul 8, 2014

The discussion list in discourse is ordered by update time, where Reddit is ordered by "hot" by default, which heavily favors new content.

@sinistersnare
Copy link

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.

@huonw
Copy link
Member

huonw commented Jul 8, 2014

Discourse also has an email gateway and tagging of discussions.

@glaebhoerl
Copy link
Contributor

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).

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.)

@emberian
Copy link
Member

emberian commented Jul 8, 2014

My perspective is that rust-dev is moving to service the broader Rust
community. Long ago, it was just us rustc hackers and maybe some people
giving it a spin, but now there are significant projects who have
announcements to make, lots of people who want to ask for help, etc. A lot
of that seems to be happening on reddit now, instead of the ML. Whereas
discuss.rl.o is more for the #rust-internals people.

I honestly don't know what place the ML has between these two resources.
ISTM that most people just want to use reddit. I'm pretty happy with
Discourse so far, I think it can be a good platform for the serious, long
discussions we need to have, as opposed to the
soundbyte/not-very-thoughtful/overly short style reddit seems to promote.

On Tue, Jul 8, 2014 at 12:31 AM, Gábor Lehel [email protected]
wrote:

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).

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.)


Reply to this email directly or view it on GitHub
#158 (comment).

http://octayn.net/

@asb
Copy link

asb commented Jul 9, 2014

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?

@ben0x539
Copy link

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 #rust vs #rust-internals.

@glaebhoerl
Copy link
Contributor

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?

@brson
Copy link
Contributor

brson commented Jul 31, 2014

Closing. discuss.rust-lang.org is the answer for now.

@brson brson closed this as completed Jul 31, 2014
withoutboats pushed a commit to withoutboats/rfcs that referenced this issue Jan 15, 2017
@Centril Centril added the T-core Relevant to the core team, which will review and decide on the RFC. label Feb 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-core Relevant to the core team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

10 participants