4 ms·

Skimmed quicky through the article, but I think it's worth pointing out that: > While tweeting with anger, Daniel pointed out that I should tell them kindly an

Skimmed quicky through the article, but I think it's worth pointing out that: > While tweeting with anger, Daniel pointed out that I should tell them kindly and it’ll work out. I’m sure it will. Let’s hope I can make it work first. I don’t like just opening issues. I’d rather send a patch directly. Sending patches directly is a non-collaborative approach to open source. Issues are made for discussion, and PRs for resolutions; as a matter of fact, some projects state this explicitly, in order to waste maintainers' time with unproductive PRs. Disliking issues implies (in a way) disliking collaboration. Maintainers who don't respond to issues are unlikely to respond to PRs/patches anyway. EDIT: Extra context: the maintainers are very responsive to PRs (see history of closed ones¹); writing a rant instead of opening issues and/or PRs is... hm. ¹=https://github.com/TwinProduction/gatus/pulls?q=is%3Apr+is%3Aclosed https://github.com/TwinProduction/gatus/pulls?q=is%3Apr+is%3...

delusional 5y ago
I can only speak for myself, but i feel that the easiest way for me to communicate my issue is to show how i would fix it. If I can't propose a fix I don't feel like i know enough to raise an issue.
- rualca 5y ago
  > (...) but i feel that the easiest way for me to communicate my issue is to show how i would fix it. I don't agree. A PR does not automatically mean that the changeset is good or well thought-out, or matches the architecture. Refusing to discuss a problem or exchange ideas regarding potential changes also raises a red flag regarding the nature of said contribution. Keep this in mind: just because you believe your patch scratches your itch, that doesn't mean your itch is the problem. Moreover, it wasn't that long ago that the Linux project had to remove PRs from the repo because a team was caught abusing the PR process.
  - Spivak 5y ago
    Sure but then you just put the discussion in the PR. The point is that having the code immediately says what you want done, that it’s possible and probably a new failing test case that demonstrates the issue.
    - rualca 5y ago
      > Sure but then you just put the discussion in the PR. The PR is nothing more than a request to discuss the changeset. The point is that trying to start a discussion on a problem by skipping the discussion of the problem and instead jumping onto a changeset that's proposed without considering neither the problem nor the constraints can and very often is a complete waste of time for all parties involved. Let's frame it the other way around: what is there to gain by not getting up to speed on the design constraints by refusing to onboard or even engage with the maintainers?
      - pritambaral 5y ago
        > The PR is nothing more than a request to discuss the changeset. This makes no sense. Why does the subject of a PR have to be a specific version of a specific changeset? Why can't the discussion be the subject, with the supplied code changes be considered a supporting "attachment" for the discussion? PRs allow for commentary and discussions. In fact, PRs let you do everything an "issue" let's you do, but not vice versa. You can't "attach" code changes to issues. Not without creating a PR anyway. ---- Let's not forget what GH-style "issues" and "pull requests" were supposed to emulate and replace: email threads. While GH's UI elements are better at most things than emails, they're not better at everything. Emails are a lot more flexible and powerful, even if not as "pretty". PRs? They can't even let me suggest code changes (when reviewing someone's PR) using my IDE/editor. Or even suggest a code change that's not contiguous. Diff-of-diffs is a concept that GH has barely understood, but one that's just obvious with plain emails.
      - UncleEntity 5y ago
        > what is there to gain by not getting up to speed on the design constraints by refusing to onboard or even engage with the maintainers? Usually my only engagement with maintainers is when their library doesn’t do what I want it to do for whatever reason and is in the form of a bug fix (or less commonly an added feature). I don’t want to ‘onboard’, I just want to use the software and since I spent the time figuring out why it was failing me I ‘pay it forward’ with what I found —- which is usually a diff of my changes. Absolutely no desire to attend committee meetings to discuss the social ramifications of my changes or whatever they get up to these days…
- erhk 5y ago
  Submit a patch with behavior B with the intent of delivering behavior A. Maintainer accepts it on the premise that behavior B is a good change. Since iti s self documenting, it correctly documents the wrong thing. You've now made a patch that you don't understand.
  - pritambaral 5y ago
    > Maintainer accepts it on the premise that behavior B is a good change. This requires that: 1. The patch come with no commentary that says it's a WIP; and/or 2. The maintainer(s) do not read any attached commentary (when and why did we stop reading commit messages?!); and 3. The maintainer(s) do not read/care that the patch is wrong. ---- In short: your scenario works only when everyone does their job poorly.
    - erhk 5y ago
      >In short: your scenario works only when everyone does their job poorly. Yes well thats vaguely the shape of the point I was making
      - pritambaral 5y ago
        > Yes well thats vaguely the shape of the point I was making So, your point is that something is bad because it's /possible/ everyone involved with it could be terrible at their jobs? If that's your point, then I can't imagine why you'd try to make it, because it applies to nearly everything in the universe of "doing things". Similar to your original comment of "You've now made a patch that you don't understand.", you've now made a point that you don't understand.
- pritambaral 5y ago
  Fully agree. Why waste words describing a code change rather than show the change itself. I'd rather use my words for describing the 'why', thank you very much, but not the 'how'. In fact, I do this even when reviewing code: a branch that I can pull from & push to is a lot more welcome than a word vomit I have to interpret and translate to (or from) code.
Smithalicious 5y ago
This is a very subjective, not to mention new (specifically: post-github) thing. Plenty of projects love to receive patches directly. I'm all for doing things the maintainer wants, but to say not using issues is non-collaborative is pants.
- da39a3ee 5y ago
  As long as you write a PR description, explaining why the behavior you are fixing is a bug, and how to reproduce it, and your PR includes tests if the project has tests.
UncleEntity 5y ago
> Sending patches directly is a non-collaborative approach to open source. This is the way I’ve always done it —- find a bug, figure out a fix and shoot off a patch attached to a bug report. Or, software doesn’t do what I want, hack it into submission then send a PR with a patch. Worked well so far. Sometimes they don’t like my code for whatever reason but that’s OK, I tried. The only real exception was when I contributed on a regular basis to one of the larger FLOSS projects where I’d usually run my changes by the module owner to get their feedback before committing since it was just good practice. Not always though.
kortilla 5y ago
Not every bug need a drum circle though. If there is an obvious fix (e.g. an uncaught exception) I love it when community members skip straight to a PR proposal.

delusional 5y ago

I can only speak for myself, but i feel that the easiest way for me to communicate my issue is to show how i would fix it. If I can't propose a fix I don't feel like i know enough to raise an issue.

rualca 5y ago
> (...) but i feel that the easiest way for me to communicate my issue is to show how i would fix it. I don't agree. A PR does not automatically mean that the changeset is good or well thought-out, or matches the architecture. Refusing to discuss a problem or exchange ideas regarding potential changes also raises a red flag regarding the nature of said contribution. Keep this in mind: just because you believe your patch scratches your itch, that doesn't mean your itch is the problem. Moreover, it wasn't that long ago that the Linux project had to remove PRs from the repo because a team was caught abusing the PR process.
- Spivak 5y ago
  Sure but then you just put the discussion in the PR. The point is that having the code immediately says what you want done, that it’s possible and probably a new failing test case that demonstrates the issue.
  - rualca 5y ago
    > Sure but then you just put the discussion in the PR. The PR is nothing more than a request to discuss the changeset. The point is that trying to start a discussion on a problem by skipping the discussion of the problem and instead jumping onto a changeset that's proposed without considering neither the problem nor the constraints can and very often is a complete waste of time for all parties involved. Let's frame it the other way around: what is there to gain by not getting up to speed on the design constraints by refusing to onboard or even engage with the maintainers?
    - pritambaral 5y ago
      > The PR is nothing more than a request to discuss the changeset. This makes no sense. Why does the subject of a PR have to be a specific version of a specific changeset? Why can't the discussion be the subject, with the supplied code changes be considered a supporting "attachment" for the discussion? PRs allow for commentary and discussions. In fact, PRs let you do everything an "issue" let's you do, but not vice versa. You can't "attach" code changes to issues. Not without creating a PR anyway. ---- Let's not forget what GH-style "issues" and "pull requests" were supposed to emulate and replace: email threads. While GH's UI elements are better at most things than emails, they're not better at everything. Emails are a lot more flexible and powerful, even if not as "pretty". PRs? They can't even let me suggest code changes (when reviewing someone's PR) using my IDE/editor. Or even suggest a code change that's not contiguous. Diff-of-diffs is a concept that GH has barely understood, but one that's just obvious with plain emails.
    - UncleEntity 5y ago
      > what is there to gain by not getting up to speed on the design constraints by refusing to onboard or even engage with the maintainers? Usually my only engagement with maintainers is when their library doesn’t do what I want it to do for whatever reason and is in the form of a bug fix (or less commonly an added feature). I don’t want to ‘onboard’, I just want to use the software and since I spent the time figuring out why it was failing me I ‘pay it forward’ with what I found —- which is usually a diff of my changes. Absolutely no desire to attend committee meetings to discuss the social ramifications of my changes or whatever they get up to these days…
erhk 5y ago
Submit a patch with behavior B with the intent of delivering behavior A. Maintainer accepts it on the premise that behavior B is a good change. Since iti s self documenting, it correctly documents the wrong thing. You've now made a patch that you don't understand.
- pritambaral 5y ago
  > Maintainer accepts it on the premise that behavior B is a good change. This requires that: 1. The patch come with no commentary that says it's a WIP; and/or 2. The maintainer(s) do not read any attached commentary (when and why did we stop reading commit messages?!); and 3. The maintainer(s) do not read/care that the patch is wrong. ---- In short: your scenario works only when everyone does their job poorly.
  - erhk 5y ago
    >In short: your scenario works only when everyone does their job poorly. Yes well thats vaguely the shape of the point I was making
    - pritambaral 5y ago
      > Yes well thats vaguely the shape of the point I was making So, your point is that something is bad because it's /possible/ everyone involved with it could be terrible at their jobs? If that's your point, then I can't imagine why you'd try to make it, because it applies to nearly everything in the universe of "doing things". Similar to your original comment of "You've now made a patch that you don't understand.", you've now made a point that you don't understand.
pritambaral 5y ago
Fully agree. Why waste words describing a code change rather than show the change itself. I'd rather use my words for describing the 'why', thank you very much, but not the 'how'. In fact, I do this even when reviewing code: a branch that I can pull from & push to is a lot more welcome than a word vomit I have to interpret and translate to (or from) code.

Smithalicious 5y ago

This is a very subjective, not to mention new (specifically: post-github) thing. Plenty of projects love to receive patches directly. I'm all for doing things the maintainer wants, but to say not using issues is non-collaborative is pants.

da39a3ee 5y ago
As long as you write a PR description, explaining why the behavior you are fixing is a bug, and how to reproduce it, and your PR includes tests if the project has tests.

UncleEntity 5y ago

> Sending patches directly is a non-collaborative approach to open source. This is the way I’ve always done it —- find a bug, figure out a fix and shoot off a patch attached to a bug report. Or, software doesn’t do what I want, hack it into submission then send a PR with a patch. Worked well so far. Sometimes they don’t like my code for whatever reason but that’s OK, I tried. The only real exception was when I contributed on a regular basis to one of the larger FLOSS projects where I’d usually run my changes by the module owner to get their feedback before committing since it was just good practice. Not always though.

kortilla 5y ago

Not every bug need a drum circle though. If there is an obvious fix (e.g. an uncaught exception) I love it when community members skip straight to a PR proposal.