I’m thinking more for the scale of something like OpenMW, as we’ve got more frequently asked questions than we could hope to put on an FAQ page. In the olden days, stuff showed up from our forums when people googled it, and now it doesn’t, so we get loads of questions through Discord, and very rarely one from Matrix.
If past support questions showed up in searches, then more users would be able to help themselves and would never need to ask for support, so it wouldn’t matter as much what platform it happened on.
Personally, I think it would be good if support discords were all bridged to matrix spaces (currently doable, but matrix needs locking down more than discord to stop spam as the tools to prevent and remove it are worse) and the matrix history was archived somewhere search engines could index it like mailing list archives are (currently not doable). That approach would let users use what they want without forcing anyone else to, and keeps self help as easy as it was in the days of forums.
There are kinds of analytics that are incompatible with the GPL, as you can’t restrict what users do with GPL software, and that includes asking children not to submit analytics containing information you’re not allowed to know about children under COPPA. The only options are to hope your software is only used by adults, or not implement any kinds of analytics that collect the relevant kinds of personal information.
Like other commenters have said, start by asking the upstream developer (whether that’s by sending a message with a link to the fork or by sending a mega-PR that says you don’t expect it to be merged as-is in the description). They should be the best judge of how they’d prefer to handle it. The thing I’d add is that you should try to avoid taking it personally if their preferred approach isn’t one you think is a good idea. Sometimes good fixes end up never merged because of disagreements becoming too heated even if everyone’s basically on the same page about the fox being good. There’s also a decent chance that your refactors are things the upstream developer explicitly doesn’t want and would otherwise have done them themselves and implemented the same fix, too, or they don’t agree that your fix is good enough. They won’t want to be on the hook for maintaining contributions that use approaches and code style that they don’t like, and that’s okay. They also might know something you don’t about their project that would make something that’s obviously a good idea to you obviously a bad idea to them.
Basically, just try and remember that if it’s a hobby project, it makes progress when the maintainer is having a good time, and gets abandoned when they’re not anymore, so try and avoid making a mess and having arguments when they’re the one that’ll have to deal with any fallout from any mistakes.