Rust 2019: Address the "Big" Problem


#13

I do believe we need better tools to discuss RFCs and make decisions.

Right now, RFCs often get so many comments that GitHub collapses several hundred of them. However, RFCs are discussed on other forums, too. This means that nobody has time to read all the discussions on all forums.

I’m proposing a tool to file RFCs, discuss them, and reach a consensus. This tool could also be used for everything else that requires a decision by the community. In this tool, an RFC consists of three parts: The wiki, the feelings section, and the discussion. The wiki describes the RFC in detail and is editable by anyone.

In the feelings section, users can express their feelings (e.g. “this is confusing” or “this adds unnecessary complexity” or “nobody needs this” or “this would help me a lot” or “I prefer the syntax with the question mark”). Feelings consist of one sentence and can be voted on (totally agree / somewhat agree / somewhat disagree / totally disagree). The feelings are then sorted by how many users agree with them. They basically act as a survey that points out the most frequent concerns.

The comments section should be a tree (reddit-like) to allow structuring long discussions.

I’d like to know what you think about this, and what else you think is important. I’d volunteer to create this tool (but hopefully with some input and help).


#14

The comments section should be a DAG (git-like).


#15

@Soni, while the comments being attached to changes is cool, I don’t see how it addresses the following issues (which I think are the most pressing issues):

  • Comments being disorganized (the same point made repeatedly)
  • Comments being widely-scattered (in multiple locations)

It does raise the bar for adding comments, which maybe reduces both issues… but I don’t think curtailing feedback is a good way to manage community involvement.

I do think it works great for when you have a small number of contributors for any given area of a repository, but the issue that we’re suffering from (but it is a good issue to have!) is the large number of participants in individual RFCs.

I find myself firmly in the camp that a centralized solution is the best for for managing RFCs - perhaps you could explain how the RFC process would benefit from the decentralized DAG format you’re suggesting?


@Aloso, I think those are great ideas. It’d probably be cool to be able to branch discussions off of the feelings points. We probably want some way to let mods modify the discussion (with open history - the point of the modifications wouldn’t be to censor, but to organize). My specific inspiration for this is that in Zulip (chat program), all messages in room need a topic, and if you forget, another person change change the topic for said message so it ends up in the right thread.


#16

Of course we could do something similar. I like the idea of adding tags to comments. Then someone can view all comments with a specific tag. With a tree-like discussion, we could also encourage people to start one top-level discussion for each topic, so it’s structured automatically.


#17

True, true. I was mostly thinking for people who come and make a comment without reading all the threads. Of course if we do have threaded discussion, that’s a lot less likely.


#18

I would like to link post with my draft ideas regarding service for improving RFC process:

Of course it will be hard to build such service from ground-up, so I do not propose to start building it right now, but think about it as a general direction in which I think we probably should move.


#19

It literally attaches parents and children to comments, and you can have multiple branches going on at once. How does that not solve the disorganization problem? (each branch is a separate topic, sort of. you can even merge topics or address many of them at once!)

As for comments being widely-scattered, GitHub can actually display these quite well, if with a few filtering issues. (click the number beside “fork” on a repo. the UI is mostly already there, so they have very little work to do on their end to make the experience better for us.)


#20

@Soni How are the parent-child comments stored - as empty commits and it’s the message? In a text file? In a different text format (json, yaml, maybe folders?) to handle nesting? Anything flat and you’ll probably have tons of merge conflicts.

I consider the current GitHub UI for managing forks, as it relates to using it to explore and get a good overview of branched changes in this scenario, pretty atrocious, not matter how little work it would take for Github to cater to our needs (which I think would be a lot, and even if it was a little, we should base our workflow on a potential change another organization hasn’t yet made).

Your approach comes off (to me) “this is a good idea, and so we should make it work”. I’d like to approach the issue from more of a “what do we want, and what’s the best way to implement it?”. If we can make a way to make it fit into Git after the fact, after we’ve gathered all the “requirements” (quotes because it’s more like aspirations than requirements, and I think not everything will make the cut), then I’m all for it. I do worry that by committing (heh, I love puns) to Git early that we’ll leave features off the table that could be useful. I think that the very least, in order to use Git we’d have to roll our own UI as a frontend for it, so the format stays standardized.


#21

@newpavlov Thank you for the link. I wasn’t aware of that thread. It was full of good stuff to take into consideration.


#22

Yes.

This is reasonable, but something I didn’t want to suggest due to cost.

Consider the github fork UI but with one repo per RFC. This is what I mean when I say it needs filtering options. An option to view only forks of a commit’s children and ignore everything else would make it a fair deal more usable. Additionally, hovering over a commit shows the description, aka the comment in my proposal. Clicking it allows you to fork from it.

While it could use some improvements, it seems quite workable even in its current state! I don’t think we’re gonna find anything like this elsewhere.


#23

Part of the problem with all of this is that what worked at small scale, now needs to be automated.

That’s what we do - we build tools to automate the yucky, error-prone stuff away. Take source control - managing revisions and changes on the bit and byte level are controlled and tracked and can be undone, reapplied to a different version, etc. Instead, you control the larger metaphor - branches, files, revisions.

I think a large-scale open-source development process, with a lot of community discussion and noisy RFCs, lots of features and work being tested, we need to treat that as source code.

Take for example the Unstable book. I look at the first thirty or so items and found four that were no longer unstable, or had been obsoleted by new features that are stable.

This is a symptom of a deeper problem - the initial draft of the Unstable book was back when the change velocity of the language was much lower, so it was easier to keep up to date.

A custom built tool or customized software service that gives us customized workflows, the ability to link issues and categorize issues, search them in robust ways, and so on is what we need.

We need issue tracking software, maybe with a custom plugin for handling the comment volumes in more robust, and still taggable/searchable/categorized ways.

Ie, if someone adds a comment of “I support this RFC”, the comment can be minimized and some sort of counter is incremented and the increment is linked back to the comment - reducing the noise of the comments without removing them. It also adds meaning to that comment, which can then be categorized and searched.

This isn’t an area where we want to be writing lots of new stuff. At my day job, we use Atlassian’s JIRA which can integrate with git repositories. We track issues, feature work, customer reported defects and work, all on it. It has a customized workflow, which varies based on the issue type, which forces us to follow a specific process with issues. For example, the RFC process could be automated this way with the custom workflow tool. Instead of needing to manually follow steps from a checklist, you can only move an RFC in specific directions and ways.

(This isn’t a suggestion to use JIRA - it may not be suitable for many reasons, but merely an example of what is possible out there.)


#24

We could use something where discussions can be forked/branched, merged, and even contain changes.


#25

Soni, please consider what kind of workload that puts on people, and how to manage permissions. It sounds like you’ve got an idea in your head, and despite reasonable objections, keep pushing for it.

No one seems to want to require new contributors, who may have very valid points, questions, observations, and experience to offer, to go through an onerous, manual process, that can be easily missed.

I certainly don’t.


#26

I don’t, either. I’m not proposing

I’m proposing we evaluate git as a suitable solution, and see what we can do about the shortcomings. We can build tools on top of git/github to make the process easier.


#27

Shameless plug: Pre-meta-RFC: rate limiting the firehose


#28

Not a bad plug though, I actually referenced that in the initial post :slight_smile:. I think it’s worth re-posting though because it was only referenced in passing. I’m more of a fan of the staged rfc process proposal (mid last year? Also linked in the initial post). I’m a big fan of the ToC part you mentioned.


#29

The unstable book is already automated by the way: a PR that adds a new unstable feature can’t land without a page on the book, and a PR that stabilizes/removes a feature without removing the page from the unstable book can’t land either.


#30

Are you sure about that? https://github.com/rust-lang/rust/issues/57224


#31

Yes, there is a tidy check that prevents a PR from landing in those cases I mentioned. Every page on the book is related to a feature that’s currently unstable, but the problem is the content of those pages, not the pages themselves. I don’t think we can automate writing documentation though.

Adding a tidy check to ensure the tracking issue link on those pages is correct could be done in theory, but I don’t think it’s a good idea: it would make all the PRs in our queue to fail as soon as the tracking issue is closed/moved, causing too much hassle for the team.


#32

My apologies, I misunderstood what you were saying.