Proper Branch/Pull Request etiquette

[SWeav02]

@jacksund I'm starting to contribute to Simmate a lot more and with that comes a new challenge of using git properly. I know it's recommended to have most pull request be only for small changes. However, I'm not sure what the best method is when I have several small changes that rely on each other. For example, I just created PR #585 which has several name changes. Now I'm working on debugging several issues with the bader_dev workflow and this is easiest when I fix the bugs after the changes I made in PR #585.

For situations like this, is it more appropriate to make a new branch after #585, keep editing, and submit a new PR, or should I keep editing #585 directly? The problem I see with the first is that if I submit another PR, there will be duplicate changes across both PRs. The problem with the second is that the PR becomes much larger.

[jacksund]

We'll be fine if PRs don't follow best practices all the time.

In an ideal world, you would stage PRs via "nested" forks -- plus Github would need to allow for listing PR dependencies. The whole process just becomes inconvenient and difficult to follow for some (link).

Instead, I would say just do one of the following:

1. if you need large changes AND everything changed within the week, throw all those updates into a single PR. These take more time to review/understand for maintainers, so make sure to have a good PR description that summarizes everything
2. if you are fine with make one edit then waiting a day to make your other edits, then keep the PRs small and tackle them one day at a time

Simmate & our apps are still in v0.x so we'll have to go with option 1 in most cases. If Simmate ever hits a v1.x milestone, we'll need more of option 2 -- but that still feels a long way off

[SWeav02]

Ok great! That makes a lot of sense to me. I'll be making a larger PR this week then, since I want to get everything working again quickly.

[SWeav02]

While we're in the discussion, is it better to submit a PR as a draft relatively early on in case other contributors have suggestions, or get it to a nearly completed state?

[jacksund]

the earlier the better!

Even if you haven't added changes yet, opening the PR let's me know what you're working on (so I don't start coding the same thing). Likewise, you can use issues (instead of PRs) to set yourself as "assigned" or set a due date.

I'll take a peak at draft PRs too in case there's something I can add/say to save you time. Then you can mark the PR as ready and request a review whenever it hits that stage

[SWeav02]

Ok, sounds good! I'll start opening issues and/or PRs more frequently.

[jacksund]

Sweet! As you get hang of things, I'll expand your permissions on the repo too 👍