Catchup number fifteen

[rthbound]

Noticed the topic branch for #15 is a bit out of date.

This catches it up, resolving merge conflicts.

Merge branch 'master' of github.com:deptofdefense/code.mil into catchup-number-fifteen

  - Signed off by Ryan T. Hosford <tad.hosford@gmail.com>

 Conflicts:
        [RESOLVED] LICENSE-agreement.md

[rthbound]

/cc @tomberek

[tomberek]

@rthbound This will take some discussion to make a decision. Thanks for the rebase. We'll try to address this week.

[rthbound]

No problem.

This does not consider whether #15 is a good idea, it just clears the conflicts (for now).

I'm just getting my contribute on, here 💪

[rthbound]

@tomberek:

It's just a dirty old merge actually. I can't git push --force-with-lease to your branch, so my rebasing wouldn't help much.

Honestly, this PR will probably just get in the way. I'm sure you'd rather rebase for ✨ history.

Wait. Actually, does that bring up a good policy question (whether or not DoD employees should overwrite history at all)?

[tomberek]

@rthbound Good question. I'm not sure what precedent there is in the policy rewriting of history for projects. I can try to attack this from a few angles:

1. Does anything prevent or forbid the rewriting of history? Is the Git history FOIA-able? Would a rewrite be considered the destruction of records?
2. Attribution: I suspect that the right to attribution for an author should be maintained. Nevertheless, I can imagine a scenario where an author may request a history rewrite or authorize one. So conceivably a rewrite would be acceptable given authorization by the authors of the commits in question. Because Git uses the hash of history in future commits, this (something like BFG) will change the hash of other author's commits, but not their content. Would every subsequent commit's author need to authorize? This seems excessive.
3. Some rewrites may be trivial or pragmatic. Someone's PR is just a mess of merges or back-and-forth changes with poor messages, or re-basing to enhance clarity. There seems to be precedent for OSS projects to try to maintain a clean history.
4. Mistakes are often made, personal data, credentials, sensitive information may all make it's way into a repository. Perhaps some of it is included before a repository is made public. Can a project manager decide to open source it with a "clean slate"? Allowing that seems to be the safest option, one I suspect most managers would pick given the opportunity. Disallowing this would only discourage project from becoming open. I would rather have projects released with a wiped history than have no projects released at all.

I'm not sure I've reached a conclusion, but a blanket ban doesn't seem right. Nor does allowing the unfettered rewrite. Where does one draw the line?

[rthbound]

1. FOIA. Tricky, but hugely important.
2. Attribution. I would expect the maintainers of the canonical repository to not squash/obliterate any commits or contributions they accept from me. The following sounds okay / not problematic:

   change the hash of other author's commits, but not their content

3. Trivial rewrites. Avoid these. Just refuse to merge a commit until the contributor meets your standards. Maybe in the contributing guidelines you say "before we merge, we may ask you to squash your commits into one so we can maintain a clean history." The only time I see that being a problem is if a contribution is comprised of commits from many authors.
4. Mistakes. If credentials are published, that's embarrassing. I'd argue that you should absolutely not overwrite that history, but rather change your credentials. Maybe I'm a bad guy subscribing to changes. I cache/persist all of them. You push credentials, I snag them. You wipe history. You just hid evidence showing you're to blame for my subsequent abuses.
5. There was (5) hidden within (4). I think it'd be okay for you to open source with a clean slate (assumption: you're talking about squashing a ton of history down to one "initial commit", then open sourcing some government work). If you open source a project in this way, I would expect that the original history would still be available and subject to FOIA.

That's my feedback, granted I'm just an enthusiastic open source contributor.

[stephenscapelliti]

1. FOIA pertains to government data and info. Some data is specifically excluded from FOIA, while others are excludable if certain conditions are met. Much of it is subjective.

2. Rewrites could be scrutinized to determine intent, particularly falsification, fraud, and cover-ups.

[BrandonBouier]

I'm not a fan of rewrites.

[BrandonBouier]

While I encourage the discussion on this, this conversation is better suited as an issue (which @tomberek is creating - Issue #67) instead of a pull request. so I will close this.