@perfinion and I have been stuck on making the most of this tensorflow/build repo, so I put together a little policy proposal that should help our goals:
- Showcase and emphasize community build-related projects and resources
- Require minimal upkeep and decision-making from the repo owners
With those in mind, consider these new rules defining what goes into the repo:
Repo Guidelines
- The repo's README is a list of items that can be one of two things:
- Link to an external repository with a brief description
- Description of a subfolder in the repo.
- Subfolders can be either:
- Code for a small bit of code, or a guide, or documentation (Why not a wiki?: GitHub wikis don't have PRs or ownership.) -- anything, but it should be small.
- The README's header includes the same subfolder description and attribution as in the root README.
- The attribution matches up with an entry in the root CODEOWNERS file for the directory.
- CI: If CI is important we'd prefer a separate repo be used, but small things like GitHub actions should be OK. We'll have to see some examples before making a decision on this.
- A collection of subfolders with a common theme, e.g. a bunch of independent Docker projects.
- All root README descriptions will be moved into this folder's README.
- This isn't necessary until many similar folders are added.
With this, the repo can hold anything, in a simple structure, with clear ownership, like Windows Subsystem for Linux guides or the Dockerfiles we currently have or SIG Build-official guides for resource usage (once we get around to them...). We'll have to rearrange a couple things, but nothing major. It'll be a nice way to formalize a showcase & guide.
I think we can use this to similarly extract more community stuff from the main tensorflow/tensorflow repo, which will let us feature more community projects. We'll leave the Community Builds table on the main README until we see a reason to migrate it (like if this plan works really well).
What are your thoughts? Leave a comment and/or join us in Dec. 1st's meeting (see http://bit.ly/tf-sig-build-notes).
@perfinion and I have been stuck on making the most of this tensorflow/build repo, so I put together a little policy proposal that should help our goals:
With those in mind, consider these new rules defining what goes into the repo:
Repo Guidelines
With this, the repo can hold anything, in a simple structure, with clear ownership, like Windows Subsystem for Linux guides or the Dockerfiles we currently have or SIG Build-official guides for resource usage (once we get around to them...). We'll have to rearrange a couple things, but nothing major. It'll be a nice way to formalize a showcase & guide.
I think we can use this to similarly extract more community stuff from the main tensorflow/tensorflow repo, which will let us feature more community projects. We'll leave the Community Builds table on the main README until we see a reason to migrate it (like if this plan works really well).
What are your thoughts? Leave a comment and/or join us in Dec. 1st's meeting (see http://bit.ly/tf-sig-build-notes).