@newpavlov Thank you for the link. I wasn’t aware of that thread. It was full of good stuff to take into consideration.
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.
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.)
1 Like
We could use something where discussions can be forked/branched, merged, and even contain changes.
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.
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.
Not a bad plug though, I actually referenced that in the initial post 
. 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.
1 Like
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.
1 Like
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.
My apologies, I misunderstood what you were saying.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.