awesome-spark-ar

awesome-spark-ar copied to clipboard

We are getting more resources in on this list and starting to see what categories etc. we need. I think we should submit this list to be an official Awesome List, but we need to get some of the requirements in place first.

• [x] Has been around for at least 30 days.

• [x] Includes a succinct description of the project/theme at the top of the readme. (Example)

• [ ] It's the result of hard work and the best I could possibly produce. If you have not put in considerable effort into your list, your pull request will be immediately closed.

• [x] The repo name of your list should be in lowercase slug format: awesome-name-of-list.

• [x] The heading title of your list should be in title case format: # Awesome Name of List.

• [x] Non-generated Markdown file in a GitHub repo.

• [x] The repo should have awesome-list & awesome as GitHub topics. I encourage you to add more relevant topics.

• [x] Not a duplicate. Please search for existing submissions.

• [ ] Only has awesome items. Awesome lists are curations of the best, not everything.

• [ ] Does not contain items that are unmaintained, has archived repo, deprecated, or missing docs. If you really need to include such items, they should be in a separate Markdown file.

• [ ] Includes a project logo/illustration whenever possible.

• [x] Entries have a description unless the title is descriptive enough by itself. It rarely is though.

• [x] Includes the Awesome badge.

• [x] Has a Table of Contents section.

• [x] Has an appropriate license.

• [x] Has contribution guidelines.

• [x] Has consistent formatting and proper spelling/grammar.

• [x] Doesn't include a Travis badge.

• [x] Doesn't include an Inspired by awesome-foo or Inspired by the Awesome project kinda link at the top of the readme. The Awesome badge is enough.

Things to do before submitting:

• [ ] Check grammar

• [ ] Don't open a Draft / WIP pull request while you work on the guidelines. A pull request should be 100% ready and should adhere to all the guidelines when you open it.

• [ ] Run awesome-lint on your list and fix the reported issues.

Make sure to read the full requirements for details.

Some inspiration:

• Awesome Unity
• Awesome Game Boy Development
• Awesome Newsletters
• Awesome Tech Videos

I like this! I can start to work on the content table if you want. I think we should also agree on a standard/template and tidy up the open source patches bit, cause its kind of a mess; there are:

• Profiles (first item)

• Repositories with multiple different things inside (sixth item)

• And even though I love his content, I can't seem to realise why Matt's twitch channel is on the list (seventh item)

Looking at the list there's not an easy way to find something

I think we should also agree on a standard/template and tidy up the open source patches bit, cause its kind of a mess; there are:

I 100% agree with you! I think profiles should be removed, and link to the individual patches instead, as profiles may contain anything. The same goes for gumroad links, I think these patches should go under "paid patches" or a category like that. (What do you think @hongweitang ?). Also, I think maybe do Patches in one category, scripts in another, and example projects in another.

For videos, I think it's better to link to specific tutorials that are validated as good and up top date tutorials rather than channels?

In conclusion, I think I don't link to profiles, but content. So my suggestion for the table of content is:

1. Official documentation and links
2. Patches 2a. Free patches 2b. Paid patches
3. Scripts
4. Tutorials 4a. Videos 4b. Articles 4c. Streams
5. Miscellaneous resources and collections (Such as Billy's Spark AR TV, and the wiki pages)

We should continue the discussion in issue #1 I think.

Yeah definetely we should align the standard/template. During edit I also realized that there were too many profiles and not the right focus on specific content to learn from.

I would not remove the section with streams. I think it can still be a valid source of knowledge.

I would not remove the section with streams.

I think a specific stream can go under tutorials like proposed in the table of content structure? Usually, in a stream, they cover a set of topics that will be useful to have in the title. So linking to the specific stream on a topic rather than the account was the proposal.

Yeah true so we can sort specific links to their tutorial topics. Vertex Displacement videos could be under topic Shaders