4 ms·

I go for #1 pretty frequently but my biggest frustration with trying to contribute to open source projects is: the repository whose owner pops in every 6 months

by floren 6y ago

I go for #1 pretty frequently but my biggest frustration with trying to contribute to open source projects is: the repository whose owner pops in every 6 months or so to merge a PR or two, then disappears. Just enough activity to hope that they might eventually merge my outstanding PRs, not quite dead enough for me to just fork and move on with my life...

_greim_ 6y ago
Merging a PR is work too, assuming the maintainer cares enough to review the code. Why not sponsor the project by placing a $300 bounty on the PR merge? As an OSS maintainer who's been on the other side of this in the past, that would have been quite a motivation for me.
- rectang 6y ago
  Most pull requests are crap. They are drive-by fixes that do not take maintainability into account, because they only solve the problem that the PR submitter needs solved right now. Transforming a sloppy drive-by patch into something which doesn't pile on technical debt is hard. For all but the most brilliantly architected projects, it requires someone who can keep the entire project in their head — a core maintainer. The expectation that unlimited PRs will be reviewed for free is corrosive and contributes to the core-maintainer burnout described in the article.
  - throwawaywrench 6y ago
    >because they only solve the problem that the PR submitter needs solved right now. This is something that can lead to angry interactions between maintainers and pull request raisers. Never mind adding technical debt, pull requests can outright break uses cases they don't care about in order to implement the single use case they do care about. raiser: "Merge my PR. It fixes this issue." maintainer: "It fixes this single issue but you've broken this for everyone else." raiser: table flip
    - sergeykish 6y ago
      Why? Just use own fork for a while. PR is sharing fix with others, it is visible even if not merged.
    - rusticpenn 6y ago
      A good test strategy would fix the problem. "Your PR fails all these tests, so can you make them all work before submitting the request?"
      - throwawaywrench 6y ago
        Definitely. You just need to keep an eye out for people removing failing tests because they think they are irrelevant :|
  - _greim_ 6y ago
    Some of this burden can be offloaded to robots though, via static types, unit tests, linting, and automatic code formatting. I even go so far as to envision my unit tests as a squad of soldiers laying in ambush around my use cases, waiting to pounce on transgressors.

by floren 6y ago

_greim_ 6y ago

Merging a PR is work too, assuming the maintainer cares enough to review the code. Why not sponsor the project by placing a $300 bounty on the PR merge? As an OSS maintainer who's been on the other side of this in the past, that would have been quite a motivation for me.

rectang 6y ago
Most pull requests are crap. They are drive-by fixes that do not take maintainability into account, because they only solve the problem that the PR submitter needs solved right now. Transforming a sloppy drive-by patch into something which doesn't pile on technical debt is hard. For all but the most brilliantly architected projects, it requires someone who can keep the entire project in their head — a core maintainer. The expectation that unlimited PRs will be reviewed for free is corrosive and contributes to the core-maintainer burnout described in the article.
- throwawaywrench 6y ago
  >because they only solve the problem that the PR submitter needs solved right now. This is something that can lead to angry interactions between maintainers and pull request raisers. Never mind adding technical debt, pull requests can outright break uses cases they don't care about in order to implement the single use case they do care about. raiser: "Merge my PR. It fixes this issue." maintainer: "It fixes this single issue but you've broken this for everyone else." raiser: table flip
  - sergeykish 6y ago
    Why? Just use own fork for a while. PR is sharing fix with others, it is visible even if not merged.
  - rusticpenn 6y ago
    A good test strategy would fix the problem. "Your PR fails all these tests, so can you make them all work before submitting the request?"
    - throwawaywrench 6y ago
      Definitely. You just need to keep an eye out for people removing failing tests because they think they are irrelevant :|
- _greim_ 6y ago
  Some of this burden can be offloaded to robots though, via static types, unit tests, linting, and automatic code formatting. I even go so far as to envision my unit tests as a squad of soldiers laying in ambush around my use cases, waiting to pounce on transgressors.