Determine GitHub LFS impact on contributor experience

[mairin]

Related to: instructlab/instructlab#62 (comment)

Over time the documents inside the taxonomy repo might get quite large. Cloning a massive repository will be an impediment to first time contributors. So having all the documents download as part of the clone might not be a good idea.

There was a decision to require contributors submitting knowledge to submit the documents via git-lfs.

How does requiring LFS impact contributor experience both command line and GitHub UI? For both:

• contributors using git clients
• contributors using the GitHub UI

[xukai92]

related issue: #8

[bjhargrave]

Git LFS storage on GitHub is a paid feature when you exceed 1 GiB of storage or 1 GiB a month of bandwidth. Interestingly, forks count against the parent's repository's quota for storage and bandwidth. Additional data packs costs $5 per month for 50 GiB for bandwidth and 50 GiB for storage.

To add files to LFS, users will need to use the git client and also install the LFS addon. LFS will need to be configured to understand the extensions to place in LFS. This list can be managed via a .gitattributes file in this repository.

Contributors will not need to install LFS to clone the repo, but they will not be able to see or add files of the extentions configured for LFS.

I think it makes sense to use LFS if we expect individual files to exceed 50 MiB in size. But it may not make sense to use LFS just to handle a large amount of total data in the repository.

[bjhargrave]

@mairin Since we are not putting knowledge documents in the taxonomy repository, perhaps this issue can be closed?