Pre-meta-RFC: rate limiting the firehose

[Centril]

But mostly, I would argue that what RFC discussions need is actually more conversation style than what GitHub offers, and so where GitHub optimizes for what I would maybe call an exchange of facts (in issues or PRs), RFCs need something closer to exchanges of ideas. In some ways, by your own admission of advocating for table of contents/summaries as an important addition, it seems you are arguing (and I would agree) that perhaps the more important feature of RFC discussion is not the record keeping, but rather the establishment of a shared understanding of the design space for a given RFC.

It’s a mixed bag; T-Lang RFCs are both about ideas, but also about the technical details, especially in the reference sections. I think the way we use GitHub can be adjusted and tweaked to fit the needs of the RFC process, but we need some work on bots, and someone needs to do that work.

[samsieber]

I concur that Github is better suited to this than Discord, mostly for the edit-ability and keeping things up to date, along with the inline file support (well, commenting on commit files…). Although getting to conclusions takes a lot of discussion most of the time consuming or reviewing an RFC you want the structured conclusions and easy visibility of the reasoning behind such things. The conversations are the unorganized organic source. I think the we should prioritize reading - write once, read a ton.

I’ll go out on a limb and say while I think GitHub is better than Discord, I think it’s okay, not great. We can shore it up with a bot, and shore it up more with writing special tools to stick in the appropriate metadata in a well formed state. Part of me wonders though it it wouldn’t just be better to write a separate tool and just store data in GitHub as the backend (because of the wonderful linking / file preview support / being able to stick other things as well in there). But maybe that’s what you mean the bot suggestion.

[mark-i-m]

Aside: I’ve been trying hard to stabilize things the last month; I’ve looked at what can be stabilized and proposed stabilization for those; for all the rest it appeared to me that they were blocked on implementation work or open design questions.

I know, and I appreciate it

Along the way some proposals just get blocked by design concerns that were either unforeseeable during the RFC’s discussion or we thought we had a solution but it turned out it wasn’t good enough.

Right, and I think often this happens because (a) the appropriate teams/contributors don’t have bandwidth to work on it ATM; or (b) the feature just doesn’t get much usage, and so arguably it shouldn’t have been accepted.

---

But mostly, I would argue that what RFC discussions need is actually more conversation style than what GitHub offers, and so where GitHub optimizes for what I would maybe call an exchange of facts (in issues or PRs), RFCs need something closer to exchanges of ideas. In some ways, by your own admission of advocating for table of contents/summaries as an important addition, it seems you are arguing (and I would agree) that perhaps the more important feature of RFC discussion is not the record keeping, but rather the establishment of a shared understanding of the design space for a given RFC.

This brings out an important point I think: IMHO RFCs serve two equally important purposes:

1. Design discussion
2. Documentation.

It think GitHub is better suited for documentation (“exchange of facts”). I’m a bit torn on Discord. It might be a better discussion forum, but I’m not fully convinced that that’s what we want; wouldn’t that make the firehose worse?

On the other hand, I can maybe see Discord making it easier to go have a discussion with someone on the side and come back to the main thread to post a summary. I’m not super familiar with Discord, but perhaps a reasonable format would be that:

• The main RFC thread is on Github.
• Each RFC thread has a corresponding Discord space opened up for people to have side discussions
• People are encouraged to go have smaller group discussions on DMs or something (does Discord have DMs?) and come back to post their conclusions on the GitHub thread.

I realize that this already happens a bit today. What I am suggesting is that this becomes the standard: chatter doesn’t happen on the github thread; it happens on Discord. The Github thread just contains the history of the discussion.

[notriddle]

So regarding GitHub vs Discord etc.

@mark-i-m @samsieber @djc

Discourse, with an S (that is, IRLO) is the alternative to GitHub that anybody with any sense is proposing for doing RFCs. Discord, the chat room product with two D’s, would make a terrible location for long-term knowledge storage. This forum, on the other hand, might actually work.

Edit: I realized after rereading that the above paragraph could be read two ways, one of which is not what I meant. Nobody here proposed replacing GitHub with Discord as the source of truth for RFC’s, and I don’t think doing so makes any sense. Continuing to use GitHub as the source of truth for RFC’s, instead of migrating to Discourse, is pretty reasonable, mostly because GitHub has better archiving for the RFC texts and is already required for participating in other Rust-related activities.

[josh]

the alternative to GitHub that anybody with any sense

Please don’t use phrasing like this. I like the idea of using Discourse for RFCs too, but “anybody with any sense” is excessive in its implication of lack of sense on any other side.

[mark-i-m]

@notriddle Thanks! Indeed I was misreading @djc’s post. But now that you mention it. What would you think of using a Discor_d_ (the chat room) for discussion while maintaining Github as the main history of the RFC, as I mentioned in my previous message.

I’m not sure Disco_urse_ (this place) is much better than GitHub at limiting the firehose, and it has worse bot integration TMK.

[Centril]

I know, and I appreciate it

Thanks for working on ? yourself!

Right, and I think often this happens because (a) the appropriate teams/contributors don’t have bandwidth to work on it ATM; or (b) the feature just doesn’t get much usage, and so arguably it shouldn’t have been accepted.

Well, in the case of inherent associated types for example the reason why it’s blocked is because of lazy normalization (AFAIK), and solving it depends on Chalk, so this is a case of growing things in leaps and bounds. But growing in leaps and bounds still means that it is being worked on, just not so directly and it doesn’t give you instant gratification.

There’s also a bunch of tracking issues for old things that are slated for removal but which we’ve been slow to phase out (e.g. due to rocket.rs using it…).

We eventually work on things; for example, type ascription needed design work, and here is the design work. If something doesn’t get worked on by anyone for some time, it’s also not the end of the world. While more foundational architectural work is being done, we can try to fix other things that are needed and more readily possible to fix; examples include ? in macros, or-patterns, and so on.

[alexreg]

several much more fundamental ones have been pending for too long. For example:

• Const generics (and in particular, arrays generic over the size parameter)
• Trait objects of more than one non-marker trait
• Implementing Fn* on user-defined types
• Associated type defaults

While I don’t really agree with this RFC in general (I think it’s always important to keep the influx of ideas and even RFCs going strong), this is probably a fair point. That said, const generics is a very complex feature, and I know @varkor has been working long and hard on it.

Some of the others features mentioned above, in particular multi-trait objects, I agree need to be given much higher priority. I’ve discussed it before with Niko and @dhardy, but it hasn’t really taken off yet. If you’re interested in moving it forwards, I very much urge you to get on the Zulip channels and chat to the three of us about it.

In general, I’d like to see more triaging of rustc development (implementation) work, to better apportion the time of the experts on the compiler team. That’s about it. I’m not sure what their thoughts on this are though. I know several of them feel stretched, so this may be a useful thing.

[notriddle]

@notriddle Thanks! Indeed I was misreading @djc’s post. But now that you mention it. What would you think of using a Discor_d_ (the chat room) for discussion while maintaining Github as the main history of the RFC, as I mentioned in my previous message.

My first thought is that it’s a terrible idea (and, just for the record, I think GitHub and Discourse are both sensible choices for the main RFC discussion, but that using Discord is not).

IRC-style chat rooms with lots of participants, like a busy RFC room would become, devolve into typing races, since the interface encourages you to post quickly and a large number of people causes the room to be dominated by whoever can compose and type their ideas fastest. This is actually kind of a problem already, but reducing it from a couple long posts every hour to a post every few seconds would be worse. A chat room with ten or fewer semi-active participants can be a joy, both because it’s slower and because there’s a better sense of mutual trust and restraint when you’re actually keeping track of individual other people.

I’m not sure Disco_urse_ (this place) is much better than GitHub at limiting the firehose, and it has worse bot integration TMK.

Discourse forum has quite good bot integration. Here’s one where they hooked hubot up to it. Here’s their API docs. Here’s a webhook integration that I wrote, though it’s not technically a bot since it doesn’t make posts, but only sucks data out of the forum.

The described bot in the OP, where a second post is automatically made, is perfectly possible using Discourse webhooks and the API. In addition, the bot could mark the post as publicly editable, allowing non-staff members to contribute to the discussion summary (it wouldn’t act as a rate-limiter, but it would still help as a place to summarize).

Discourse also allows the forum operators to install custom JavaScript/CSS gizmos, a feature that neither GitHub nor Discord share. Custom Ruby plug-ins are also supported, but I think that requires an enterprise plan that Rust doesn’t have.

[mark-i-m]

Thanks for working on ? yourself!

If something doesn’t get worked on by anyone for some time, it’s also not the end of the world.

I agree, but this is IMHO tech debt, and we should strive to limit it.

IRC-style chat rooms with lots of participants, like a busy RFC room would become, devolve into typing races, since the interface encourages you to post quickly and a large number of people causes the room to be dominated by whoever can compose and type their ideas fastest. This is actually kind of a problem already, but reducing it from a couple long posts every hour to a post every few seconds would be worse. A chat room with ten or fewer semi-active participants can be a joy, both because it’s slower and because there’s a better sense of mutual trust and restraint when you’re actually keeping track of individual other people.

Yeah, that’s my concern too. I just thought I would throw the idea out there.

Also, thanks for enlightening me on the integration support. That’s good to know. I suppose that puts Discourse back in the running in my mind, but I would still like some sort of rate limiting.

[Centril]

I agree, but this is IMHO tech debt, and we should strive to limit it.

Well if it isn’t implemented, then there’s no actual debt in the compiler; if is implemented then I agree it’s technical debt; but it’s temporary debt that can and usually is eventually paid. If we don’t fix something in 6 months or a year, I can live with that.

[Soni]

Hmm. This might be a really awful idea, but, why are we still using a single branch for RFC work?

What if we made each branch its own RFC, but more importantly, INCLUDING relevant conversation. I’m not sure how to do PRs with this but there’s probably a way.

We can fork PRs, add our comments to files, fork those, merge those, etc, etc, and keep the whole discussion organized. And GitHub PR comments get locked by rfcbot, and only FCP actions happen through those.

One of the benefits of this is that we get to move out of GitHub whenever, since the PR work will all be on the git repo, and not on the proprietary issue tracker.

[mark-i-m]

My experience has been that using git to manage text is not fun. Concurrent editors and different editor configurations with regards to things like line endings and soft/hard wrap mean that trivial edits become massive merge conflicts.

[Soni]

Use the blockchain. Use the commit messages but don’t commit any data.

Edit: Git is a blockchain. Each commit is a block, and it links to the previous block, just like a chain. A commit-based (instead of edit-based file-based) comment system provides many benefits like immutability etc. You can further use signed commits to guarantee the identity of the comment author. Additionally, you allow a conversation to further fork into sub-conversations because git has built-in support for branching off a commit history.

[scottmcm]

At most C comments can occur between note s. If C comments occur and nobody has issued a summary note of activity since the last note , rfcbot locks the thread . I propose C = 30 because that’s about the most I can keep up with before I give up on following a thread.

This penalizes those who take time to make careful replies. The RFCs that get the most flooded are the ones that get a huge number of posts from a fairly small number of people immediately. I don’t want to de-facto encourage “unlock sniping”.

[mark-i-m]

Yeah, I’ve thought about that too, but I don’t have a good solution. My hope is that the CoC can help?

[JeanMertz]

Reading the discussion between @mark-i-m and @Centril made me think about how the structure of teams in a company impacts the way it operates (also somewhat related to Conway’s law).

The biggest example is Microsoft having a “Windows” team and Apple having a “Software” team. Where Microsoft has long had issues where new initiatives had to be tied to Windows in some way, because that team had gathered so much influence during its profitable years, that shifting the overarching strategy of Microsoft away from Windows towards services/cloud was nearly impossible, and it almost killed the company.

This is in contrast to Apple, which obviously has different people working on MacOS and iOS, but they are all part of the same “software” division, and report to the same team lead.

In Rust’s case, having a “no new features” year results in T-Lang people rightfully asking “what does that mean for us?”.

It’s not as drastic as the Windows situation, but I thought it an interesting observation to share. I also think (as I think @mark-i-m and @Centril do) that there’s still a lot to do for T-Lang even without major new features being introduced. Perhaps a “no features” year is even more challenging, as a lot of things will be in-motion and have to be tied together as a cohesive whole.

EDIT: interestingly, it turns out Satya Nadella himself referenced Conway’s law in his “Embracing our future” email to the company. I should have probably just copied his words, as they better describe what I’m getting at:

To truly get the best impact from our efforts, we will have to push ourselves to transcend Conway’s law. Having a deep sense of customers’ unmet and unarticulated needs must drive our innovation. We can’t let any organizational boundaries get in the way of innovation for our customers.

EDIT 2: In case my post is perceived the wrong way, I want to clarify that I’m not in any way suggesting that any members of T-Lang are against a “no new features” policy because of self interests. While I don’t know @Centril personally, I’ve read enough of his posts and responses to know that his values in no way suggest a “Windows-like mentality”, but I just thought it could be valuable to add the above information to this thread, in hopes of adding some valuable insights to this (and other) discussions regarding the 2019 roadmap, how it affects the community, and how it can affect the different teams working on Rust.

[scottmcm]

Yeah, I’ve thought about that too, but I don’t have a good solution. My hope is that the CoC can help?

Sadly I don’t have one either. My first thought was to send such things back here, but that just moves the fire hose without fixing it.

Maybe some kind of post-level categorization could help? If there was a way to file similar statements under an umbrella…

I’m not sure that there are any CoC problems with the posts, though. They’re nearly always made in good faith; there’s just a ton of them.

[mark-i-m]

@scottmcm Right, I agree with you. I meant something like this:

The Code of Conduct is updated to explicitly state that it is considered poor etiquette to comment without making a good-faith effort to read and understand the ToC. Repeat offenders may be evicted.

Not sure if that’s the right approach, though. I also don’t want to intimidate newcomers (“Oh, maybe I shouldn’t post because I’m eating the post quota”).

In part that’s why I suggest Discor_d_… People go have there little discussion somewhere on a DM, and come back with their conclusions. It does have the problems that @notriddle mentioned though…

---

I do wonder if there is a way to have a meta-eRFC X where we experiment with different ways of passing X to see what works well.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.