Can we stop using git(hub) for RFCs?

[notriddle]

If people are yelling at you on IRC, that’s unacceptable. Please let the moderators know about that.

[nikomatsakis]

I am also not a fan of discussion on GitHub. I’ve toyed around with many ideas for how to setup RFCs and so forth, but I’ve not found something I like better all around. For larger RFCs that will take some time to develop – or a group of related RFCs – I think creating a separate repo can be a good approach. Wikis might be suitable, but in general they don’t support discussion very well. A separate repo allows you to open issues, take pull requests, etc.

I’m also a fan of the idea of having GH basically consist of links to discuss threads, with people writing summaries of the key outcomes of each discussion. But that requires a lot of manual effort and doesn’t often happen.

Tricky problem!

[iopq]

Yes, I’m not a fan of my exact solution either. But I feel like the person who puts in a pull request has too much responsibility since they have the final say on how the RFC looks like. So they have to update it when issues come up in discussion. I don’t see much of multiple people fixing the same RFC until it’s accepted because it’s more of a bother to do a pull request of a pull request.

[Manishearth]

I think the design of the RFC process is such that a single person or a small group of people propose an rfc and decide what goes in it, so a wiki would not work great. When you do want to collaborate, you can always hand out push access to your fork.

The rfc process is centered around review and discussion, neither of which work well on a wiki.

Really, it’s totally fine to work on an RFC via the github UI, in which case it’s almost no different from a wiki in the first place; with the caveat that you have to make the initial fork and make it into a pull request, neither of which are too complicated. We could add better documentation for this workflow, perhaps.

It’s unacceptable that you got yelled at in IRC for this. You don’t even need to keep the history clean here, the rfcs get squashed and moved by the team before being merged.

[iopq]

I think I got yelled for more like saying it’s awkward to use Git, rather than the particulars of my pull request. Still, Git shouldn’t be a requirement to use Rust or contribute to RFCs. Some people prefer using other version control systems.

[jethrogb]

Git shouldn’t be a requirement to use Rust or contribute to RFCs

Not sure if it shouldn’t, but it is. Everyone working on a single project necessarily needs to use the same VCS (or one compatible with the main one). Which VCS is used is determined collectively by the project, not by the preference of individual users. If you want Rust to switch to a different VCS, you can propose an RFC for that, but I sincerely doubt it will get any traction.

[Manishearth]

Again, you don’t need to know much about Git to use the online editing interface; you’d need to learn that amount of tooling to work with wikicode anyway.

Yes, this will lead to a messy git history in the rfc, but like I said, this doesn’t actually matter much.

[iopq]

it’s a little bit more complicated when you’re trying to edit someone ELSE’S RFC since it’s not merged yet

Edit: I messed it up and accidentally committed to my master branch, damn it

[Manishearth]

Write, ilke I mentioned the process as designed isn’t supposed to be one where that’s too common (and if you are collaborating on an rfc, grant access to the repo)

[iopq]

You’re right, I’ll go track down huonw and get right on it. My point is you never know if your RFC later needs to be updated or handed off to another person.

Maybe my ideal system is closer to StackOverflow where anyone can suggest edits, but moderators can approve/disapprove them.

[kornel]

Google Docs allows commenting and proposing changes. It’s not so good with markdown and archiving though.

[milesrout]

Whether or not git is required to contribute to Rust (which it inevitably will be, whether directly or through an extension to another VCS that talks git like Kiln Harmony or something), GitHub should not be. GitHub is proprietary software and the company behind it is pretty shady.

[fdietze]

I’m following the issues with RFC/discussion tooling since some time now.

With the goal to solve many of the problems that arise in a large group of collaborators, a friend and I started to work on a new kind of collaboration project.

The core idea can be imagined as a mix of the expressiveness of mind-mapping, Wiki and realtime collaborative editing.

I mentioned the first prototype (https://github.com/woost/wust) earlier. With all the things we’ve learned from the first prototype, we started a second one from scratch: https://github.com/woost/wust2. It is in an early stage of development, but you can already play with the online demo and try basic collaboration features: https://wust.space

The large Rust community seems like a very good use-case for our system, so we are very open to implement improvements to support the Rust development process.

Please ask me any questions.

[notriddle]

If we forget the “need” to use markdown for a minute, wouldn’t Google Docs have all the features the RFC process needs?

[fdietze]

I believe you could achieve a lot with Google Docs. Realtime collaborative editing is great for working on content together. And the fact that everybody can edit everybody else’s contributions is good for having discussions inside the document and continuously refactor and clean up. But conceptually you only have the realtime-advantage over a wiki.

It’s a bit inflexible if you want to share the same content between different documents. At the same time, it is tedious to keep links, backlinks to other documents and overview documents up to date.

And of course it’s not open source, but there are alternatives.

Edit: I forgot to mention that the commenting feature would work like the line-based notes on github.

[Storyyeller]

Also, there’s no way to link to a specific revision of a Google Doc. I’m not even sure if people other than the owner can see the revision history at all.

[Ixrec]

My impression is that RFCs are not meant to be collaboratively edited in real time in a single session, but rather collaboratively discussed/reviewed over a long period of time and typically only updated by the original author. In particular, I think any credible replacement for github for RFC purposes would need to provide the ability to

• comment on specific parts of the RFC
• reply to any comment
• link to any past comment
• have a complete public edit history
• link to any past edit or part of a past edit
• subscribe to/unsubscribe from all updates/comments on a particular RFC
• somehow support an equivalent of fcpbot

As far as I know, google docs doesn’t offer those features, since realtime collaborative editing precludes a lot of them. I can’t seem to find any of them in wust either, though that may only be because I can’t figure out what on earth is going on in that demo.

[Nemo157]

Sounds like Google Wave, if only that were still usable

[fdietze]

@Ixrec The current Wust development version only supports connecting, replying, deleting, editing and nesting of posts. All wrapped in a quite unusable UI. So yes, the demo right now is very limited and can be confusing.

The point I want to communicate is that the goals of the project align very well with what the Rust community needs. Every single point you mentioned is actually part of what we want to achieve: Collaboration in big nested graphs with proper versioning (parts of the edit history can be commented on) and integration with other services like GitHub. Even partial ordering of posts is planned which would be useful to model roadmaps with different levels of detail an link them directly to the relevant tasks/RFCs/discussions.

@Nemo157 Google Wave was one important inspiration for our project idea.

Since the Rust community actually faces the challenges we want to solve, we are very interested in feedback and criticism for the idea itself, so that we can prioritize development.

[system]

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