3 ms·

Issues I get (and practice), but PRs? Are you requesting a PR from yourself, approving the PR when you have meditated about it for a day? :)

codycraven 7y ago
I could see being able to look at your code diff outside the context of your editor could help you identify issues you wouldn't otherwise see. Especially if your brain flips into code review mode when looking at a GitHub PR.
deforciant 7y ago
I do PRs for any minor/major features on a project that I work alone :) it helps to see a better diff in github, also see CI status (using drone) and also to review it after few days when I can be objective about it. Project is quite big at the moment with a lot of moving parts so it helps to have a process. Also, each PR has a name and short summary of what was changed, added, fixed. So when something breaks in 6 months it's easy to track down related PRs and refresh my memory.
pizza234 7y ago
> Are you requesting a PR from yourself, approving the PR when you have meditated about it for a day? :) He :-) I definitely agree that this is more on the obsessive side of being structured - but on the other hand, the cost is virtually zero (I open and close PRs via commandline). In those conditions, I'd say that issues and PRs are both complementary and necessary parts of a certain perspective/workflow. When I open an issue, it's a request for action. PRs are the other side of the coin - the represent the action that satisfies the request (as a matter of fact, "Closes #..." is crucial for me). Opening an issue and closing it without a Pr, for me it... asymmetric (also practically: assigning a PR to an issues gives you the reference in the interface). Ultimately it's a matter of fully embracing a workflow. Ideologies aside though, PRs nowadays are not just an isolated concept - typically, they carry various hooks (CI, code analyzers etc.) that do help. So, in a way, somebody is meditating on my code, even if it's just a machine ;-)

codycraven 7y ago

I could see being able to look at your code diff outside the context of your editor could help you identify issues you wouldn't otherwise see. Especially if your brain flips into code review mode when looking at a GitHub PR.

deforciant 7y ago

I do PRs for any minor/major features on a project that I work alone :) it helps to see a better diff in github, also see CI status (using drone) and also to review it after few days when I can be objective about it. Project is quite big at the moment with a lot of moving parts so it helps to have a process. Also, each PR has a name and short summary of what was changed, added, fixed. So when something breaks in 6 months it's easy to track down related PRs and refresh my memory.

pizza234 7y ago

> Are you requesting a PR from yourself, approving the PR when you have meditated about it for a day? :) He :-) I definitely agree that this is more on the obsessive side of being structured - but on the other hand, the cost is virtually zero (I open and close PRs via commandline). In those conditions, I'd say that issues and PRs are both complementary and necessary parts of a certain perspective/workflow. When I open an issue, it's a request for action. PRs are the other side of the coin - the represent the action that satisfies the request (as a matter of fact, "Closes #..." is crucial for me). Opening an issue and closing it without a Pr, for me it... asymmetric (also practically: assigning a PR to an issues gives you the reference in the interface). Ultimately it's a matter of fully embracing a workflow. Ideologies aside though, PRs nowadays are not just an isolated concept - typically, they carry various hooks (CI, code analyzers etc.) that do help. So, in a way, somebody is meditating on my code, even if it's just a machine ;-)