Make repo public

[bendnorman]

• [x] Remove EIA key
• [x] Delete zenodo archive of EIP and LBNL datasets.
  • [x] Remove old PR from archiving repo
  • [x] Remove datastore, add lbnl to git
• [x] Remove sensitive EIP info
  • [x] remove sponsor names from notebooks
  • [X] remove sensitive columns from raw data file
  • [x] rerun relevant notebooks to remove embedded bits of sensitive data
• [x] Add MIT license to repo
• [x] Add CC license to data in readme. Add a description to the BigQuery datasets that links to the licensing language in the repo. Bigquery dataset licensing example: BQ dataset, repo
• [x] Make BigQuery data public.
• [x] Rerun the full ETL.

Things to remove from git history:

• [x] EIA key
• [x] EIP dataset
• [x] Notebooks with sponsor name
• [x] Notebooks with sensitive EIP data
• [x] Sponsor name from src/dbcp/transform/eip_infrastructure.py
• [x] Double check sensitive EIP data is removed
• [x] Double check sponsors name does not appear in github search
• [x] Double check sensitive notebook output histories are clear.

[bendnorman]

It doesn't look like bfg removes sensitive information from open branches, example. We have 24 open branches that I think would have to be deleted. Many of them have already been merged we just didn't delete the branch.

I think we have two options to really clear out this repo:

1. Continue with this repo:
   • Delete all merged branches that still have sensitive data.
   • I don't know of any way to force Github to reindex a repo so sensitive information can still come up in search results. We could hope that no one searches for the sponsors name in the repo and that GItHub reindexes the repo soon.
2. Create a duplicate repo from the most recent commit.
   • This would resolve all of the sensitive information issues.
   • We would lose all of our issues because a private repository issue cannot be transferred to a public repository.
   • This new repo would become our working repo so we wouldn't be able to easily revert to changes made before the new repo was created.

@TrentonBush what do you think is the best option?

[TrentonBush]

Given the choice, I'd rather keep the current repo. But if there are lots of additional steps to making that happen, I think option 2 isn't horrible. Comparing branches to issues, it looks like branches are easier to get rid of. It looks like almost every branch has already been merged or abandoned. I just took a brief tour through the open issues and could close about 40% of them without trying very hard.

I guess I'd vote for option 1 and to ignore the temporary indexing problem. If I search for The Term that Shall Not Be Named I see over 1k repos. I think we would be quite far down that list.

[bendnorman]

Sounds good. I'll move forward with option one.

[bendnorman]

I deleted branches that have been merged. @TrentonBush do you mind going through the remaining branches? I'm not familiar with the work living on the remaining branches.