admin/update-contributing-doc

[tohuynh]

Pull request recommendations:

• [x] Name your pull request your-development-type/short-description. Ex: feature/read-tiff-files
• [x] Link to any relevant issue in the PR description. Ex: Resolves [gh-12], adds tiff file format support
• [x] Provide context of changes. Some of the new contributors are having issue with squash and merge commit practice, where their commits from their previous PR are a part of their new PR. This guide will help avoid the problem for new contributors. Also made the doc a little bit cleaner.

This guide won't help the contributors who are currently having this issue. The solution I can think of is to delete their fork repo, fork again, and follow this guide. @JacksonMaxfield do you know any other way?

• [x] Provide relevant tests for your feature or bug fix.
• [x] Provide or update documentation for any feature added by your pull request.

Thanks for contributing!

[evamaxfield]

I guess I don't know what the issue of "delete the fork and remake the fork" is. If their fork's head is drastically different from CouncilDataProject/seattle they could simply pull upstream master and force push to their origin master no?

[tohuynh]

This is excellent. Thanks for updating these. Can you mirror them to cdptools as well?

Yes, will do.

[tohuynh]

I guess I don't know what the issue of "delete the fork and remake the fork" is. If their fork's head is drastically different from CouncilDataProject/seattle they could simply pull upstream master and force push to their origin master no?

Yes, but the issue is to prevent old commits(from previous PRs) from being a part of a new PR.

Suppose I have 'commit a' in my master branch. I make a PR and it gets merged to upstream master.

I make another commit 'commit b' in my master branch. If I pull from upstream master, the git history will look like something this:

...,the squash and merge commit (which contains 'commit a'), 'commit a', 'commit b'.

If I make another PR, the git history of the PR will contain 'commit a', 'commit b'.

For example, if you look at the latest commit on cdptools, you will see * Cloning prod to target firebase database functionality as one of the squashed commits. ` Which was a commit from one of the previous PR, but isn't relevant to process single event PR.

[evamaxfield]

Ahhh I see what you are saying. Yea I mean this is basically just going back to people should be like full force clearing their master branch.

The ideal would be: never branch off another branch but I guess this is a place I need to learn better open source practices.