Suggestions for repo changes

[overestimate]

Changes that should be made:

• [x] Pin an issue for smaller bugs
  • See Apollo Lake Platform Validation for a good example of how this could look
• [ ] Add a stable branch Use a dev branch for development
• [ ] Only release changes as stable when main is updated and stable
• [x] Mark unstable builds (builds from main branch) as pre-release
• [x] Add issue template
  • Check ISSUE_TEMPLATE.md for an example template
• [x] Add PR template
  • Check PULL_REQUEST_TEMPLATE.md for an example template
• [x] Add a CONTRIBUTORS.md file
  • These are typically used for listing contributors and listing what all can be done as a contribution
• [x] Move documentation to another markdown file
• Add mirrors on other sites such as Gitlab or Bitbucket
  • Although this is a good idea, do this at your own free will

[ollivxv]

agreed

[Kqzz]

I agree with most of those things.. however, I don’t think a stable branch makes sense. If someone wants the source code for a particular release (all releases are theoretically stable) then they can download that from the tag, where it’s in a zip. If they want the git commit they can look at the logs for the release and go back to that commit in the repo.

I’ll start using a “dev” branch when I’m writing new code, and once it works and is tested, then I’ll merge into main.

i don’t want to move docs out of the README, for now. Eventually I’d like to move the docs to a proper place, not a markdown file. I’m interested in options for that, since I want something that’s free & open source and allows for GitHub contributions.

[emilyisoffline]

i like pizza

[overestimate]

I agree with most of those things.. however, I don’t think a stable branch makes sense. If someone wants the source code for a particular release (all releases are theoretically stable) then they can download that from the tag, where it’s in a zip. If they want the git commit they can look at the logs for the release and go back to that commit in the repo. I’ll start using a “dev” branch when I’m writing new code, and once it works and is tested, then I’ll merge into main.

that works too, as long as you have a rolling and a stable release system it should be good for those points

[overestimate]

marked documentation movement as done because it will not be occuring also working on contrib, issue, and pr markdowns and adding a bug megathread soon

[overestimate]

issue template, pr template, and CONTRIBUTORS.md now pending in #8

[ollivxv]

I agree with most of those things.. however, I don’t think a stable branch makes sense. If someone wants the source code for a particular release (all releases are theoretically stable) then they can download that from the tag, where it’s in a zip. If they want the git commit they can look at the logs for the release and go back to that commit in the repo.

I’ll start using a “dev” branch when I’m writing new code, and once it works and is tested, then I’ll merge into main.

i don’t want to move docs out of the README, for now. Eventually I’d like to move the docs to a proper place, not a markdown file. I’m interested in options for that, since I want something that’s free & open source and allows for GitHub contributions.

HI KQZZ

[Kqzz]

Mark unstable builds (builds from main branch) as pre-release

To be honest I doubt I'll do this. It's just too much work, when realistically I just want a feature out and being used, and if it's buggy, I'll try to fix it quickly or tell people to go back 1 version.

[overestimate]

Mark unstable builds (builds from main branch) as pre-release

To be honest I doubt I'll do this. It's just too much work, when realistically I just want a feature out and being used, and if it's buggy, I'll try to fix it quickly or tell people to go back 1 version.

just do it via github actions?