-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update list to fulfill the requirements to be an official Awesome List. #4
Comments
Some inspiration: |
I like this! I can start to work on the content table if you want.
Looking at the list there's not an easy way to find something |
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:
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 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 |
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.
Has been around for at least 30 days.
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.
The repo name of your list should be in lowercase slug format:
awesome-name-of-list
.The heading title of your list should be in title case format:
# Awesome Name of List
.Non-generated Markdown file in a GitHub repo.
The repo should have
awesome-list
&awesome
as GitHub topics. I encourage you to add more relevant topics.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.
Entries have a description unless the title is descriptive enough by itself. It rarely is though.
Includes the Awesome badge.
Has a Table of Contents section.
Has an appropriate license.
Has contribution guidelines.
Has consistent formatting and proper spelling/grammar.
Doesn't include a Travis badge.
Doesn't include an
Inspired by awesome-foo
orInspired 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.
The text was updated successfully, but these errors were encountered: