Hacker News Reader

Comment by delfinom | Hacker News Reader

Glad to see you are volunteering to submit PRs to resolve these issues on an open source project

For me, when someone is critical of another person having spent their time checking out if there are any optimisations for something submitted to HN with, lets face it, snarky, "Well, raise a PR then", that's quite a shame.

The question is if the feedback is in line with the announcement.

Basically the same a pointing out a spelling error on a single slide in a CS class. You are technically correct about the feedback, but it is misplaced and not worth spending time on in class.

Given that this post was about a website redesign I feel his comment seems on topic.

Personally I'd say the issues are not about the design, but infrastructure and potentially UX (dependent on who that target group is, how their usage pattern is, etc.).

It's not. For starters you need to get the repo, make a branch, do the changes add tests, you may need an account to raise the PR on whatever platform, then there's possibly a CLA to raise. Whereas whoever raised the submission in the first place probably has some interaction with the project, therefore mentioning this in HN could then be taken by the submitter and raised as a feature request so someone could make a PR.

For me, I see an open source project that probably has limited resources/time/volunteer effort to support it.

I read that comment as, "rip huge chunks of Bootstrap and jQuery out of it - should be quick"... well I am guessing given Bootstrap design patterns that they used these tools as a core library in-which they built their site around. They may be planning to leverage these tools in the future, or even just want to give themselves the option to... It's an over-simplification. Likely, this site got them to where they wanted to be... a much more modern-looking site without a ton of effort sunk into development.

It's also completely disingenuous to talk about these filesizes in pre-gzip numbers vs. post. When you look at these "optimizations" without taking into account gzip you are looking at a "worst case scenario" that doesn't exist - this site is gzipping it's assets over the wire. The jQuery gripe is more like 33.6Kb vs 96Kb when you look at it through the gzip lens.

---

This sort of response (and subsequent defense) is why I would never show my creations here. It's emotionally difficult for me to see such a stable and mature project as Munin accomplish a bit of modernization only to be nitpicked like this. Munin is a great tool.

"Raise a PR" is perfectly valid here when it comes down to it. I think the internet will handle the extra ~100Kb/page load just fine.

> They may be planning to leverage these tools in the future

If that's the case then creating a PR and raising it would be a waste of time, as it'd be rejected.

Raise an issue first, gauge the reaction, and then create a PR if you think they would welcome it.

Whether it's a website or some other open source project, maintainers usually don't like it when you create a massive refactoring PR without talking with them first.

If, luckily, the maintainers are on HN, I guess talking about the "problem" here could very well substitute for raising an issue on whatever platform they use.

Completely agree. It seems there's no repo for this site anyway, judging be other comments.

Your comment prompted me to check to see if I could do that. The website build process doesn't appear to be documented and it's been built in a template system I'm not familiar with. So I can't.

That is actually something I'd expect gp know/check before suggesting submit pr/make issue/submit patch. I mean, if the website repo isn't available - the only "better" way to give feedback, would be to submit a link/the text of the hn comment to the project mail list/chat channel etc.

I certainly think "open an issue/please make a pr" is a fine suggestion regarding FOSS projects in general.

Ed: isn't this the repo, built via github workflows ? https://github.com/munin-monitoring/munin-monitoring.github....

Beyond that; is there much cause to spend (any) effort to go from 0.5mb to less, really? Especially considering gzip?

Sorry about that. I actually commented on it at

https://munin-monitoring.org/munin/website/2021/04/20/we-mad...

FWIW I did mean my comment more as a suggestion of where people could look for optimizations (in this site or their own sites) rather than a criticism of what you've made. I apologize for not communicating that better.

Reply on news.ycombinator.com