Comment by socalgal2

Comment by socalgal2 10 hours ago

8 replies

View on Hacker News

I haven't seen your PRs and I don't work on those project. I have small projects that receive few patches.

My experience of the few patches I have received though is they are 100% without exception, bad patches. Bad in that, without me putting an hour or 2 of work into them I can't just accept them. The most common case is no tests. The patch fixes an issue, but the issue exists because there was no test for the case the patch is fixing. So, to accept the PR, I have to download it and spend time writing a test.

Other common experiences are bad coding practices and non-matching styles so I have two choices

(1) spend 30-60 minutes downloading the patch, fixing these issues myself

(2) spend 40-60 minutes adding comments to try to get the person who posted the PR to make their patch acceptable (40-60 mins includes the back and forth).

More often than not, (2) never gets a response. The contributor's POV is they provided a fix and I should be happy to take it as is. I get that. At a certain level they are correct. But, these projects are hobby projects and I have limited time. So I generally don't do (2) because if they ignore the comments then it's wasted time, and (1) has the hurdle that I need to take an hour out to deal with it.

SOLAR_FIELDS 10 hours ago

Your first example should be solved by the maintainers outlining clear contribution guidelines. It’s not hard to point some automation at a pr and comment if someone didn’t follow contribution guidelines.

Nonmatching styles can be mostly solved with linting and static analysis

There’s no fix for bad code outside of manual review beyond that. But doing those things should significantly cut down on your noise.

Reply View 3 replies
  • pousada 9 hours ago

    Trust me it’s not being solved by a CONTRIBUTING.md with guidelines.

    90% of contributors won’t read it at all or only some parts of it and ignore the rest.

    Most PRs you get solve some super specific individual problem and aren’t relevant for the wider community that uses your OSS.

    It’s not their fault really but most contributions are so bad it doesn’t serve to spend any time on reviewing them earnestly.

    (Been maintaining several popular projects for the last 7 years)

    Reply View 1 reply
  • socalgal2 3 hours ago

    I haven't seen static analyis cover the things I'm concerned with.

    Examples, calculating something twice instead of pulling the calculation out of the loop (one case) or into a separate function so that 2 separated places where it's calculated don't get out of sync (a different case). Another might be using an let x; if (cond) x = v1 else x = v2 (which is 3-9 lines depending on your brace style) vs const x = cond ? v1 : v2. When v1 and v2 are relatively simple expressons. I haven't seen a checker that will find stuff like this.

    Reply View 0 replies
xyst 10 hours ago

Wouldn’t it be best to ask contributor to reproduce the bug with a test rather than just completely ghost them?

Companies such as Google have billions at their disposal yet still can’t figure out simple project management?

Google of the past is no more, unfortunately.

Reply View 2 replies
  • pousada 9 hours ago

    It’s not worth the time. You will spend uncountable hours of (unpaid) extremely exhausting labour talking to people who only care about solving their personal super specific problems. This is true for 90%+, there are exceptions but they are exceedingly rare

    Trust me I tried many many times.

    This has nothing to do with Google being evil it’s just one of the realities of maintaining a big open source project.

    Reply View 1 reply
    • bruce511 3 hours ago

      I'll add that for small projects, (and I suppose large ones) it's also a "unwelcome" task. Kinda like docs is.

      Open Source projects are typically done by people who like coding. Writing docs, reviewing PRs, "management" are all chores, not fun parts of the project.

      I manage a couple of projects that get submissions. Handling that is really not the fun part of my day. Fortunately I get very few. I can understand why ones that get a lot see it as a burden, not as the great gift the submitter thinks it is.

      Personally I don't want to spend hours each day reviewing PRs. That's not what I signed up for.

      Reply View 0 replies
mschuster91 6 hours ago

One problem with tests is that every project has different philosophies on how to write and how to organize tests. Others have no way of running them locally because it‘s all CD, and often figuring out how to write and organize tests takes longer than fixing the bug itself. Or the stack has little support for running just one specific test (aka the test you‘re trying to write). Or tests need resources you don’t have.

Reply View 0 replies