My thoughts to you are, from personal experience, is that writing plugins for Ruby to do what you are doing in your “fork” is much easier done from a plugin, when we understand Ruby and Rails enough to easily write a plugin for Discourse (or modify any Rails class).
If we don’t understand Rails and Ruby easy enough to write a Discourse plugin, my experience is forking Discourse and hacking on core is “misguided”.
I guess the analogy is this (sorry for this simple idea):
“Someone finds it difficult to walk; so they decide to run instead.”
Let me explain, if you do not mind:
Before I started writing Rails applications (nothing to do with Discourse), and tried to write Discourse plugins, I was a bit lost; and was even annoyed with Discourse a bit, I think. It’s like when you want to hit a golf ball the first time; it does not go straight and takes a lot of work to hit the ball in the middle of the fairway. Forking Discourse is like pulling out the big driver on the range before you can chip and putt with the short irons!
I took a break from hacking Discourse (many months backed) and worked for a while actually building a number of Rails applications from the ground up; and then (and only then) I began to develop some “instinctive” knowledge about Rails. After that, when I decided to modify Discourse (I’m currently running 6 custom plugins I wrote in production for Discourse), everything became intuitive and plugins which modified the Ruby core became too simple.
Ruby is very flexible. We can override any class, any object. We can redefine every aspect of Ruby. With some experience, we start to go “WOW”, I had no idea Ruby was so flexible (and powerful) and start to “become dangerous” because we can fly like superman with Ruby and Rails. We are on the beginning of our Ruby and Rails journey at that time, not the end!
With the Ruby and Rails knowledge I have gained in 2020, knowing what I know now, I would never fork Discourse and make changes to the Ruby and Rails core as you are proposing, because plugins are just too easy to override and modify Ruby classes, when we understand the basics of Ruby classes and the basics of meta-programming.
I guess what I am saying is, sorry to be so direct, is that if someone thinks they need to hack the Discourse core to make some minor Ruby changes; then they don’t understand Ruby and Rails enough; because if they did, they would not hack the core and just write a quick plugin to override the classes and love monkey-patching.
The same is totally true even more if we are just going modify core Discourse here and there! It would be a bit “nutty” to fork it to do that, tossing away the “people” who are the “real” Discourse (not the code).
I am speaking only from my personal journey in 2020 learning Ruby and Rails. Now, it’s becoming easy (the basics) and I’m “dangerous”, LOL. I can “monkey patch around with anything”, which is not alway good; and that is what Discourse plugins are for.
Keep the core solid as a rock, and enjoy “monkeying around” with Discourse with plugins.
Hope this helps.
Note, while writing this reply, you wrote:
This kinda proves my point, don’t you think?
Writing a “plugin” in Discourse is writing “Ruby code” (on one level) and for others it goes much deeper (in EmberJS).
Before you start writing Discourse plugins, my friendly advice, perhaps seeming not of value to you, is to first go develop some Ruby on Rails apps. Learn your way around Ruby and Rails, at least the basics, after that, you will have answered your own question above.
I was on the phone this morning in conference call with a client for three hours going over a Rails app, validations, models, etc. and then I was taking a break after coding up some of the action items from the call, and read your post.
The shortest path to writing Discourse plugins, in my view, is to learn Rails first.
Hope this helps!