| ▲ | lokar a day ago |
| To me, that touches on the central issue. I think most people support the “I don’t care about the tool, only the outcome “ But, we have long had a stable social system for collaboration, and in particular dealing with low quality contributions. Mostly (or at least ideally) it involves taking some time to look at the contribution and provide some feedback. The time invested is not worth it on a single exchange basis, but it’s a repeat game, so you are investing in the future. LLMs, and people willing to just spam crap they don’t really understand blows that all up. |
|
| ▲ | moring a day ago | parent | next [-] |
| I'm not convinced it blows up. It might also end up placing a larger burden on contributors, and especially first-time contributors, to provide concise, high-quality documentation that justifies their contribution. I'm thinking of something like: Explain, in at most 300 characters, why we should merge your change, or at least why we should invest the time to read a longer explanation (somethings things ARE complex). If you don't do that, or those 300 characters aren't convincing, or have nothing to do with your change or the longer explanation, then you get a canned response so the maintainers waste minimal time. |
| |
| ▲ | thayne a day ago | parent | next [-] | | That doesn't really solve the problem. I've gotten PRs that do do an adequate job of explaining why why something should be implemented. Then I look at the code and it doesn't fully solve the problem, or it does so in a way that will obviously break something else. | | |
| ▲ | moring a day ago | parent | next [-] | | In that case, isn't a sufficiently reasoned "why" a contribution in itself? Not trying to downplay the time wasted to reject the PR, though. | |
| ▲ | lokar a day ago | parent | prev [-] | | A colleague once setup a PR description template that asked for short sections like: - Why is this change needed (big picture) - Why are you doing it this way (small picture) - What are the trade-offs you made for this approach - How do you know this is correct, that it works the way you think it does? - What other changes or approaches does committing to this way block in the future? etc. If you had actually thought through what you were doing, it was a few min to fill it all out. People were just on auto-pilot really struggled. | | |
| ▲ | aleph_minus_one a day ago | parent [-] | | > If you had actually thought through what you were doing, it was a few min to fill it all out. ... for people who are native speakers of English. | | |
| ▲ | lokar a day ago | parent [-] | | Software engineering is a highly collaborative process. To be successful you need to be pretty good at reading and writing whatever language the team is using. I've worked with plenty of non-native speakers who were well above the average I see for natives. In the last 10 years I found the level of just basic writing for new Jr engineers has really fallen. If you can't write, you can't think |
|
|
| |
| ▲ | Keyframe a day ago | parent | prev [-] | | you know EXACTLY what would happen in such a system. | | |
| ▲ | moring a day ago | parent [-] | | I don't, please enlighten me. | | |
| ▲ | lokar a day ago | parent | next [-] | | My prediction is that many new contributors would complain loudly. Some existing contributors would sympathize. It’s I think a normal evolution of a social norm. There will be a period of competing values. | |
| ▲ | Keyframe a day ago | parent | prev | next [-] | | people would use LLMS for those summaries, defeating the purpose. You can already see it in PRs in companies where LLM code is pushed. | |
| ▲ | CamperBob2 a day ago | parent | prev [-] | | Explain, in at most 300 characters, why we should merge your change, or at least why we should invest the time to read a longer explanation (somethings things ARE complex) would simply become a prompt. The solution, of course, is to use the best available LLMs as the first line of defense against slop contributions. But if the project maintainers have issued a sweeping fatwa prohibiting an entire class of useful tools, that option along with many others is off the table. | | |
| ▲ | tiahura a day ago | parent [-] | | I wonder if some of these projects with ayatollah maintainers are looking at forks sooner rather than later? |
|
|
|
|
|
| ▲ | hypfer a day ago | parent | prev [-] |
| Nah, that was already blown up way before LLMs existed. Foss wasn't exactly not miserable before 2022. The dysfunction just got amplified so that we cannot fix it anymore by just throwing more human resources at the problem. |
| |
| ▲ | lokar a day ago | parent [-] | | I tried to nod a bit to the inconsistency. Some projects clearly lost patience with imperfect contributions long ago. But many were still pretty supportive. This dynamic also plays out in many companies. I see a lot of posts from mid to sr engineers frustrated with plummeting code quality and unsure how to manage the reviews. They are increasingly pulling away from the idea that they should mentor people to do better. | | |
| ▲ | aleph_minus_one a day ago | parent | next [-] | | > They are increasingly pulling away from the idea that they should mentor people to do better. Two considerations on this: 1. In the USA, it is common to switch jobs often (in opposite to, for example, Germany). So, in the US-American system it is not often worth the effort to invest a lot of mentoring ressources into some employee if he will leave soon anyway. 2. I personally observe that I often do try to give less experienced programmers good hints on how to improve, but my kind of thinking about programming is often so different that my advice is often of no use for them. Or I often get the arrogant reaction by less experienced programmers that I care far too much about obscure details. I thus seriously do believe that the only way to help junior programmers to become better is to completely crush their ego and arrogance (just like a doctoral study programme in, say, mathematics does to the doctoral students), which is of course not allowed at work. :-( | |
| ▲ | Retric a day ago | parent | prev [-] | | The correct response to irresponsible AI use in the workplace is maintaining standards and rejecting poor quality. Performance improvement plans as a fair warning followed by firing people works for incompetence or laziness, AI doesn’t change anything. I’ll admit I’ve seen a spike in negative performance reviews but this is the new normal people will adapt. | | |
| ▲ | blackqueeriroh a day ago | parent [-] | | It’s almost like late-stage capitalism isn’t built to support mentorship and education and enabling human improvement! |
|
|
|