Lemdro.id

1 point

1 year ago

Well, yeah, which would make perfect sense if a) Firefox was made by volunteers instead of whatever weird blend of non-profit and for-profit companies are running Mozilla these days, and b) if I was filing a bug report instead of casually mentioning that Firefox can be buggy sometimes in social media.

If I was filing a bug report I’d be attaching… you know, logs. And repro steps. As you do in a bug report. I don’t even know if Firefox has a bug submission process for the public. I assume they don’t. Most of those are worthless anyway.

Look, besides the notion that the whole discussion is rather pointless, the idea I was trying to impress earlier is that the end user doesn’t care or need to care about the challenges of OSS development. Being free and open source may be a practical selling point, a moral selling point or not a selling point at all, but ultimately when you use a thing you just kinda need it to work first. When you complain, or even just mention, an issue with some piece of OSS in places like this you just tend to get a bunch of IT and workarounds back.

Which is fine, I get it, it’s people trying to be nice, but… you know, it doesn’t make a great case for the ecosystem. Me saying “eeeh, FF can be a bit flaky sometimes you may want to reboot it every now and then” is an anecdote. Me saying that and going down a rabbit hole of profiling and memory snapshots in the futile attempt to fix some arcane interaction between Youtube and a bunch of add-on software Youtube doesn’t want me to run is rightfully enough to put off the average person. All I’m saying is not every person mentioning a thing they noticed in a piece of OSS needs a howto doc and a list of highly technical homework as a response.

report

[ - ]

Blake [he/him]@feddit.uk

1 point

1 year ago

I guess I don’t really understand - can you help me understand your viewpoint? What do you think a good response would be? Just like, “oh yeah, that sucks dude?” Sorry if I made it feel like I was expecting you to do technical tasks, it was just an offer of help to get it fixed, but obviously if you’d rather not do that, you’re not compelled! Just trying to help really. I don’t know what the better response would be - I’m autistic so sometimes I miss social cues so sorry if that’s the case!

report

[ - ]

1 point

1 year ago

The point was a simple observation that the OSS community tends to confuse feedback for requests of technical support.

It’s not you in particular and it’s not mean spirited or wrong to do. It is, however, a relevant note on why some OSS struggles with reach.

My go-to example of this is that nobody cares that Blender is open source, but people tend to flag it for GIMP. Because Blender “just works” and has comparable UX and features to paid alternatives. I know what’s on GIMP or Krita and my comment isn’t a call for help, just an observation.

In this case… well, yeah, it sucks that Firefox has a long-standing performance bug. If it gets fixed in the future it’ll be fine. If it doesn’t I’ll survive, but it may put off some people from joining if the effective experience is less responsive than Chrome’s despite what benchmarks may say.

report

[ - ]

Blake [he/him]@feddit.uk

1 point

1 year ago

Thanks for the extra information, but I still think I’m missing something - what’s the reason behind providing feedback if you don’t want them to do anything about the feedback? Like, you’re just making conversation about it, like sharing funny bugs you had in Skyrim?

I guess there’s a difference between talking about bugs and UX, because if you said that you prefer Photoshop to GIMP because you think Photoshop’s UX is better, I totally understand that, and “tech support” isn’t really appropriate, but isn’t that different for people who are talking about their specific performance issues? Like, how would you want people to respond to that?

it may put off some people from joining if the effective experience is less responsive than Chrome

Isn’t that a reason for people to be more helpful in helping others resolve their performance issues and to raise bug reports as appropriate? I really feel like you’re trying to have your cake and eat it too, here - it feels like you want Firefox to fix performance issues, but you feel like the issues should be fixed without actually giving devs the information they need to fix them. That’s just not going to happen for any app/software, OSS or not

report

[ - ]

1 point

1 year ago

Isn’t that a reason for people to be more helpful in helping others resolve their performance issues and to raise bug reports as appropriate?

No, see, that’s my point. There’s a whole family of bugs where people don’t want to be told how to fix the bug themselves, they want the bug to never have happened in the first place. Or, you know, at best for it to be patched and removed without their intervention.

Showstopper bugs? Sure, those you just want a way to get past so you can do what you want to do, but experiential bugs, bugs that don’t block you but make things slightly more annoying? For most people any additional effort in fixing the bug just makes the bug worse at that point. Especially if it’s not an open-and-closed “just do this and it fixes it”.

A slight performance degradation over time that clears up with a reset is not that big of a deal. Being walked through debugging processes I’ve already tried that won’t actually fix the issue is an extra annoyance on top of having to deal with the bug. At best. At worst it feels patronizing, in that hey, I know what I’m doing, right? It’s annoying in the way calling customer support and having to go through the dumb easy part of the script where they tell you to turn the thing off and on again is annoying. Except I didn’t call customer service, I just complained about the bug and now people on the Internet are crawling out of their hideouts to do customer service at me.

So no, no every situation calls for trying to walk somebody mentioning a bug through basic QA processes. Software is supposed to just work, and for the average user, if you add homework on top of their software not working, that’s just extra incentive to not use the software. OSS fans sometimes miss that small but relevant part of the user experience.

report

[ - ]

Blake [he/him]@feddit.uk

1 point

1 year ago

Maybe it would be easier to reframe the conversation.

Imagine that you live in a city that has a garage that gives away free cars. Most people get one and it works perfectly fine, but sometimes people modify them and it causes issues with the engine, nothing major but it’s a minor inconvenience. Maybe turning the car off and on again resolves it.

When said people have issues and talk about it, people ask them questions like “what changes did you make?” and “what kind of issues are you having?” with the idea of trying to help them, and maybe they’d suggest things like “try checking the on board diagnostics” or “check the spark gap” to try and help.

Don’t you see how saying, “I just expect it to work without having to do any homework or spending any time trying to fix it. I’m not a mechanic.” is kind of absurd in that situation?

It’s totally unreasonable to expect extremely complex software to always just work with zero bugs, even if you pay $$$$ for it. People can expect it to “just work” all they want - and for Firefox, it does. If you’re adding third party addons that break it, then you don’t have a Firefox problem, you’ve got an addon problem.

If you don’t want help, you don’t need to post about it. Being honest, you just seem pretty entitled to me, and I’m not trying to insult you, I just genuinely don’t understand what you expect with regards to your own situation. You say that you’re happy with the workaround you have but also that you think it should be fixed and you think it’s a problem with the OSS community that someone tried to help you to get it fixed? I just do not get it.

report

[ - ]

1 point

1 year ago

Yeah, no, I’m actively saying just that.

I’m actively saying that when most people hear a little noise under the hood they do one of two things: ignore it or take the car to a mechanic and use a different transport method for a bit until it’s fixed.

I’m saying that if somebody casually mentions “my car does a little noise” over the watercooler and the other person goes “hey, have you popped the hood and checked the spark gap” or “can you pull up the on board diagnostics and maybe we can go over them now?” the usual reaction is to make up some excuse or get glassy eyed and move on with your day.

That is absolutely how that goes.

And no, it’s not optimal or even particularly reasonable, but that’s the thing, it doesn’t have to be. When the average person engages with a market product for fun or casual usage they are often willing to invest zero effort in improving it from the out of the box experience, at least early on. And that’s their prerogative. That low barrier to attrition is a key element of UX design, and it absolutely applies to technical issues.

report