3 ms·

> (...) 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

by 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…

by rualca 5y ago

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…