Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Changing how we develop Ladybird

ladybird.org

Post reply on HN
Print view View original

531–540 of 602 posts

Re: Changing how we develop Ladybird

#531

Post by kelnos »

dcrazy wrote: post #404
Based-A wrote: post #401

Earlier quoted context omitted.

Come on, are you really going to strawman "engineering should be inherently disqualifying" into "so people shouldn't DIY in their own home"? Please try a little bit harder.

I’m not strawmanning anything. I’m pointing out what I believe to be ridiculous gatekeeping. Software engineering isn’t some holy magic that must be kept from the masses. I can go on YouTube and get step-by-step instructions on how to safely wire an entire house. In many jurisdictions I would even be allowed to do that. I can get instructions on how to completely redo a bathroom, down to the studs and up through the…

> I can go on YouTube and get step-by-step instructions on how to safely wire an entire house.

Sure, and I'd be comfortable doing that with my house. I wouldn't be comfortable with some random person off the street coming up and saying to me, "hey, I watched a bunch of YouTube videos about wiring; you should invite me in to rewire your house".

That is the proper analogy here.

Re: Changing how we develop Ladybird

#532

Post by altairprime »

tuyiown wrote: post #73
nh2 wrote: post #63

> There will not be a [..] process for submitting patches by [any] means > Outside involvement still matters: clear bug reports So I can find a bug, I can fix it, but I am not allowed to tell them how exactly I did it. Instead they have to re-figure it out. The team must be thrilled to re-do work they know was already put in by others, repeatedly. As a user-and-eveloper, why would I sink time into a project with such…

> So I can find a bug, I can fix it, but I am not allowed to tell them how exactly I did it. Pin pointing the issue is way more than valuable than code. If you wrote a fix, you have analyzed the bug. The value is there, not in the fix. Sharing your fine analysis is the maximized contribution. Code is an optional bonus at most.

'I applied this change to my local fork as a temporary workaround, in case it's useful to consider' is the way to express this.

In one memorable case, by presenting it as problem+tempfix and inviting discussion, the developer argued that I should focus on repairing the other software that was the cause of brokenness. I agreed with them, we mutually closed the issue, and my code was (correctly) discarded.

Code is a secondary and optional part of the feedback process. Yes, it can be a more precise language for conveying a problem report. No, it is not necessarily a boon. Code never carried significant intrinsic value — the motivation of the author to show up and interactively participate with the project that was infinitely more valuable than any one patch! — and now with AI, code carries negative intrinsic value, indicative of drive-by patches with no likelihood of future participation.

The most effective contribution I made this month to a project was to spend three weeks reproducing a bug and then informing them of the process to repro it themselves. They were head over heels grateful, not only because I bothered to write a bug report, but because I followed up a week later when I managed to create a second repro case of the exact same issue under wholly different circumstances. The issue is, at its core, a reasoning error about a protocol handshake-setup-command process across 2+ devices, and patching their code to fix it is meaningless compared to the value I provided by simply showing my work in tracking down the problem.

Pull requests are, these days, more often an expression of entitlement ('I deserve praise, be grateful for my code, comply with my designs, or else') than of free-time invested into the project ('Hi, we've been working together in various bug reports for a while, and I saw this problem and felt like it would be a fun side project to hack on') and so I wholly endorse their decision to refuse them.

Re: Changing how we develop Ladybird

#533

Post by malicka »

krapp wrote: post #509
thewebguyd wrote: post #420

Earlier quoted context omitted.

> I hope this spreads to all of the internet. It is. Unfortunately, its not happening with open platforms. Communities are migrating to private discord servers, and less is discussed in public/in the open. I think we should still separate "working in the open" from "allowing or not outside contributions." Outside contributions are fine to be denied, however I think work and discussions should still more or less happe…

Gatekeeping doesn't work if institutional knowledge is freely given to all, the entire point is that knowledge is only available to a select few and acts as a shibboleth to keep the tourists out.

This kind of gatekeeping isn’t about knowledge (which is free and should be freely shared — basic hacker ethic), but about social standing.

Re: Changing how we develop Ladybird

#534

Post by philovivero »

progbits wrote: post #149
torben-friis wrote: post #118

Earlier quoted context omitted.

There is certainly a certain... entitlement? (It's not the perfect word, but I fail to find a proper term) from some of the vibe crowd. Like an attachment to the output and refusal to accept that most of the work was not theirs. It is seen in the way they approach contributions but also in regular language. I created X, insistence that their 'curation' was very influencial to the output, difficulty to mention LLM con…

I've experienced the following sequence more than once at work, and I remain baffled by it each time: - Receive a huge vibecoded PR for complicated new feature. - Complain that this needs some design doc to figure out the right approach first. - Author says no need for design doc, easier to have vibed implementation and discuss the concrete code instead of abstract document. - I disagree (obviously), but review the P…

SRE.

"You ship it, you take the pager. Once it's stable, then SRE org will take the feature. If it gets unstable again, SRE will hand it back."

If someone vibe codes something, and it works, then no reason not to merge it. So just set it up so if it doesn't work, they're on the line to fix it.

Along with their oh-so-supportive manager.

But also, if you have the clout, doing what you're doing nips the problem in the bud earlier, and so is more efficient. Good that you have the clout.

Re: Changing how we develop Ladybird

#535

Post by WhyIsItAlwaysHN »

habinero wrote: post #48
WhyIsItAlwaysHN wrote: post #39

They could make two kinds of pull requests and add much more strict criteria for public contributions. For example, they could say that the PR has to be smaller in size and well-documented for human review, otherwise it's closed by an automation. And then if someone wants to do a larger contribution, they could have a process like making an issue, discussing the approach and then collaborating with a maintainer to ge…

That doesn't solve the volume or quality problem. LLMs can split one giant PR into 50 smaller PRs just as easily and "well-documented" isn't something you can determine automatically. Why is it so hard to just accept that AI PRs suck and create an enormous amount of toil?

Well it still looks suspicious if a user creates 50 PRs in one go. So you would close them automatically.

As for well-documented, the reviewer can decide that when they are reviewing the smaller PR.

Nobody said volume is not a problem, but closing down contributions entirely is a step too far.

Re: Changing how we develop Ladybird

#536

Post by clhodapp »

In the age of AI, perhaps it will be more common to see major forks of open-source projects emerge, with the upstream back-porting a few of the larger features themselves because they're impressed at what the fork is able to do, as opposed to the fork making PR's back into the upstream.

Re: Changing how we develop Ladybird

#537

Post by crabmusket »

aorth wrote: post #475
spacechild1 wrote: post #284

Earlier quoted context omitted.

That's the most succinct way I have seen someone put it, thanks! It's really the same issue, no matter if it's software, online comments, e-mails, artworks, homework, etc. We engage because we expect to be interacting with the output of another human being. AI fundamentally betrays this expectation.

Yes, and there was a good post about exactly this social contract last week https://jola.dev/posts/the-social-contract-of-writing . I find the argument compelling on the face of it and true in my experience with colleagues and the broader digital landscape recently.

Yes, and it cites the Oxide RFD that introduced this specific wording to me too:

https://rfd.shared.oxide.computer/rfd/0576#_llms_as_writers

> LLM-generated prose undermines a social contract of sorts: absent LLMs, it is presumed that of the reader and the writer, it is the writer that has undertaken the greater intellectual exertion. (That is, it is more work to write than to read!) For the reader, this is important: should they struggle with an idea, they can reasonably assume that the writer themselves understands it — and it is the least a reader can do to labor to make sense of it.

Re: Changing how we develop Ladybird

#538

Post by thewebguyd »

krapp wrote: post #509
thewebguyd wrote: post #420

Earlier quoted context omitted.

> I hope this spreads to all of the internet. It is. Unfortunately, its not happening with open platforms. Communities are migrating to private discord servers, and less is discussed in public/in the open. I think we should still separate "working in the open" from "allowing or not outside contributions." Outside contributions are fine to be denied, however I think work and discussions should still more or less happe…

Gatekeeping doesn't work if institutional knowledge is freely given to all, the entire point is that knowledge is only available to a select few and acts as a shibboleth to keep the tourists out.

Knowledge isn't what should be gatekept. Participation in the community, sure, maybe, but not information/knowledge.

Re: Changing how we develop Ladybird

#539

Post by TalkingCodeMonk »

elestor wrote: post #511
TalkingCodeMonk wrote: post #367

Earlier quoted context omitted.

So the solution is for FOSS developers to pay large sums of money to AI companies, to solve the problem that the AI companies created, for profit? ... and you typed this out as though extorting charities were a solution, instead of a grotesquely immoral and unethical systemic failure?

I'm on your side, but don't you think 'grotesquely immoral and unethical' is a bit of an exhaggeration? It's just software.

Why do you believe morals and ethics do not apply to software? Would you say nuclear weapons are "just physics"? What about the software involved? In that context, software is a tool that can make or break civilizations.

Honestly, this kind of disregard and reductive reasoning comes across as corrupt and sociopathic. The sentiment is a recurring theme I see on HN more than any other forum, and representative of the moral and ethical systemic failure permeating modern business and governance; how most politicians, investors, and leaders treat their users/customers/employees/constituents adversarially, as though they are marks to be fooled, manipulated, and exploited without conscience.

We should always hold each other accountable and ensure our beliefs and actions are conducive to improving everyones quality of life and standard of living. Software is no exception. These should not just be virtues to be signaled through marketing, or while standing on a pulpit, or being recorded. They are how we should strive to live our lives in private, even when nobody is watching.

Re: Changing how we develop Ladybird

#540

Post by matheusmoreira »

Fraterkes wrote: post #66

I've been looking a lot at Godot (another big open source project) PRs lately, and there's been kind of a surge of wholy ai-generated PRs (both code and description). This is agains project-policy, so people creating these PRs usually get mildly told off. What's surprising is that while many submitters take that fairly well, some people get really indignant, essentially calling the maintainers ungrateful. It's kinda…

> there's no inherent value in producing a big lump of code

I dunno. If that lump of code makes the program do things it wasn't doing before, I'd say there's a lot of value in it. We can definitely scrutinize the code's quality but there's no way anyone can argue with working code that makes the program better or more featureful than it was before.

Post reply on HN