Grammar. I find an amazing amount of typos in the lists people make.
It's readme should have a clear description of what the list contains.
Quality check added content. Not everything is worth adding. It should be a curation of the best, not a list of everything.
Having all lists follow this would improve the quality considerably.
Maybe we could come up with some guidelines on what's a awesome "certified" list?
Anything I missed?
Anyone care to help out opening issues on lists? Both lists included here and not.
Originally created by @sindresorhus on GitHub (Jun 24, 2015).
A lot of lists are missing important things or just too low of quality. We could be nice internet citizens and help out those lists.
Common things I open issues about in lists:
- Missing license. Here we can suggest the same as this repo or CC0 or some other CC license.
- Missing contributing.md. Can just suggest copying the one in this repo and modify it to own needs.
- Succinct description to each item.
- Commentary on each item. Added by the submitter of why the item is worth reading/consuming. See https://github.com/sindresorhus/awesome-scifi#cities-in-flight-1970-by-james-blish-40 for example.
- Grammar. I find an amazing amount of typos in the lists people make.
- It's readme should have a clear description of what the list contains.
- Quality check added content. Not everything is worth adding. It should be a curation of the best, not a list of everything.
Having all lists follow this would improve the quality considerably.
Maybe we could come up with some guidelines on what's a `awesome` "certified" list?
Anything I missed?
**Anyone care to help out opening issues on lists? Both lists included here and not.**
Neat idea. Just going through some of the lists. If a list looks unmaintained, should I open an issue to discuss removal and/or finding an alternative?
@arthurvr commented on GitHub (Jun 24, 2015):
Neat idea. Just going through some of the lists. If a list looks unmaintained, should I open an issue to discuss removal and/or finding an alternative?
@arthurvr Would be happy to change the link to an alternative high quality fork, but don't want to remove it as it's a good resource as is.
@sindresorhus commented on GitHub (Jun 24, 2015):
@arthurvr Would be happy to change the link to an alternative high quality fork, but don't want to remove it as it's a good resource as is.
@sindresorhus Maybe creating a new file called something like guidelines.md that will explain this process?
@inputsh commented on GitHub (Jun 24, 2015):
@sindresorhus Maybe creating a new file called something like `guidelines.md` that will explain this process?
Here's my idea. Of course, you could improve the order a bit.
Only link to awesome content.
Don't link to everything people suggest you to link. Research it, find out if it's really awesome and include it if it is.
Request a personal comment on why something is awesome
It's not enough to just suggest something. You also have to say why do you suggest it and how will the potential users benefit from consuming it.
Make it clear on what the list is about
Make sure your list covers a certain scope and nothing else.
Pay attention to the grammar
Please be sure that you do your best to keep the list grammatically correct.
Choose an appropriate license
See Choose a License for more details. Keep in mind that if you haven't selected a license, it basically means the people are not allowed to reproduce, distribute or create derivative works.
NOTE: I did an interview with a GitHub representative about licenses that could be a perfect addition to this section. It'll be online in a couple of days.
Stylize your list properly
Create table of content, put a picture or two, organize the content into different categories.
Accept other people's opinion
If you're an owner of the list, respect other people's opinion. If there are plenty of users not agreeing to your decision, give it a second thought!
@inputsh commented on GitHub (Jun 25, 2015):
Here's my idea. Of course, you could improve the order a bit.
#### Only link to awesome content.
Don't link to everything people suggest you to link. Research it, find out if it's really awesome and include it if it is.
#### Request a personal comment on why something is awesome
It's not enough to just suggest something. You also have to say _why_ do you suggest it and how will the potential users benefit from consuming it.
#### Make it clear on what the list is about
Make sure your list covers a certain scope and nothing else.
#### Pay attention to the grammar
Please be sure that you do your best to keep the list grammatically correct.
#### Choose an appropriate license
See [Choose a License](http://choosealicense.com/no-license/) for more details. Keep in mind that if you haven't selected a license, it basically means the people are not allowed to reproduce, distribute or create derivative works.
**NOTE**: I did an interview with a GitHub representative about licenses that could be a perfect addition to this section. It'll be online in a couple of days.
#### Stylize your list properly
Create table of content, put a picture or two, organize the content into different categories.
#### Accept other people's opinion
If you're an owner of the list, respect other people's opinion. If there are plenty of users not agreeing to your decision, give it a second thought!
Nice idea, I think we should continue our efforts in making the lists better.
I'll start with my own one and then open issues on other lists. Should we mark "certified awesome" lists which adhere to the awesome guidelines with ☑ or ❤ or another symbol to distinguish them from the ones needing work?
Should we create an "awesome.md" with a "check list" or merge the guidelines into contributing.md?
Kind of like an "awesome manifesto"?
@n1trux commented on GitHub (Jun 27, 2015):
Nice idea, I think we should continue our efforts in making the lists better.
I'll start with my own one and then open issues on other lists. Should we mark "certified awesome" lists which adhere to the awesome guidelines with ☑ or ❤ or another symbol to distinguish them from the ones needing work?
Should we create an "awesome.md" with a "check list" or merge the guidelines into contributing.md?
Kind of like an "awesome manifesto"?
Should we mark "certified awesome" lists which adhere to the awesome guidelines with ☑ or ❤ or another symbol to distinguish them from the ones needing work?
I'd rather we just help everyone get there when the guidelines are decided on. We can remove entries that are non-responsive.
Should we create an "awesome.md" with a "check list" or merge the guidelines into contributing.md?
Kind of like an "awesome manifesto"?
awesome.md file in this repo that is referred to from the readme and contributing.md
@sindresorhus commented on GitHub (Jun 27, 2015):
> Should we mark "certified awesome" lists which adhere to the awesome guidelines with ☑ or ❤ or another symbol to distinguish them from the ones needing work?
I'd rather we just help everyone get there when the guidelines are decided on. We can remove entries that are non-responsive.
> Should we create an "awesome.md" with a "check list" or merge the guidelines into contributing.md?
> Kind of like an "awesome manifesto"?
awesome.md file in this repo that is referred to from the readme and contributing.md
I think such a community should be based on standards and choosen membership. A role model or overall inspiration could be these guys: https://thephpleague.com/
Just replace "PHP Packages" with "Awesome Lists/Content".
@h4cc commented on GitHub (Jun 27, 2015):
I think such a community should be based on standards and choosen membership. A role model or overall inspiration could be these guys: https://thephpleague.com/
Just replace "PHP Packages" with "Awesome Lists/Content".
I think such a community should be based on standards and choosen membership.
What does that even mean? Elaborate?
@sindresorhus commented on GitHub (Jun 27, 2015):
> I think such a community should be based on standards and choosen membership.
What does that even mean? Elaborate?
I'd rather we just help everyone get there when the guidelines are decided on. We can remove entries that are non-responsive.
Fair enough.
awesome.md file in this repo that is referred to from the readme and contributing.md
Okay, I'm doing just that. Should I create a PR or push directly and we discuss later?
@n1trux commented on GitHub (Jun 27, 2015):
> I'd rather we just help everyone get there when the guidelines are decided on. We can remove entries that are non-responsive.
Fair enough.
> awesome.md file in this repo that is referred to from the readme and contributing.md
Okay, I'm doing just that. Should I create a PR or push directly and we discuss later?
Okay, I'm doing just that. Should I create a PR or push directly and we discuss later?
You can usually just push directly, but I think it would be helpful to do a PR so we can discuss directly there.
@sindresorhus commented on GitHub (Jun 27, 2015):
> Okay, I'm doing just that. Should I create a PR or push directly and we discuss later?
You can usually just push directly, but I think it would be helpful to do a PR so we can discuss directly there.
@sindresorhus Its a term i used for the "we" in your previous sentence:
Maybe we could come up with some guidelines on what's a awesome "certified" list?
Defining what is "certified" needs to be a rfc-style decission needed a group of people.
Also calling it "certified" might be counterproductive by scaring maintainers and producing competition. A open and friendly group that could be joined on free will seems way more friendly to me.
@h4cc commented on GitHub (Jun 27, 2015):
> What does that even mean? Elaborate?
@sindresorhus Its a term i used for the "we" in your previous sentence:
> Maybe we could come up with some guidelines on what's a awesome "certified" list?
Defining what is "certified" needs to be a rfc-style decission needed a group of people.
Also calling it "certified" might be counterproductive by scaring maintainers and producing competition. A open and friendly group that could be joined on free will seems way more friendly to me.
I'd rather we just help everyone get there when the guidelines are decided on. We can remove entries that are non-responsive.
Fair enough.
awesome.md file in this repo that is referred to from the readme and contributing.md
Okay, I'm doing just that. Should I create a PR or push directly and we discuss later?
@n1trux commented on GitHub (Jun 27, 2015):
> I'd rather we just help everyone get there when the guidelines are decided on. We can remove entries that are non-responsive.
Fair enough.
> awesome.md file in this repo that is referred to from the readme and contributing.md
Okay, I'm doing just that. Should I create a PR or push directly and we discuss later?
Okay, I'm doing just that. Should I create a PR or push directly and we discuss later?
Create a PR so we can discuss it first.
@arthurvr commented on GitHub (Jun 27, 2015):
> Okay, I'm doing just that. Should I create a PR or push directly and we discuss later?
Create a PR so we can discuss it first.
Also worth checking some lists for broken links. Found quite a bunch of them.
That could be offered as a service. Or every list would have to integrate that into its own CI with travis or such (what i already did).
@h4cc commented on GitHub (Jun 27, 2015):
> Also worth checking some lists for broken links. Found quite a bunch of them.
That could be offered as a service. Or every list would have to integrate that into its own CI with travis or such (what i already did).
er, should I remove it again or should we just discuss it now? facepalm
@n1trux commented on GitHub (Jun 27, 2015):
oh fuck. Accidentally uploaded it before branching :/
https://github.com/sindresorhus/awesome/blob/master/awesome.md
er, should I remove it again or should we just discuss it now? *facepalm*
@sindresorhus I will go through your list and improve the quality of frontend-dev-bookmarks asap. Thank you for your contributions to the community.
@dypsilon commented on GitHub (Jun 29, 2015):
@sindresorhus I will go through your list and improve the quality of frontend-dev-bookmarks asap. Thank you for your contributions to the community.
@xPetrus It's a nice idea, but I honestly don't think it's worth the effort. And it will look weird when only some have graphics.
@sindresorhus commented on GitHub (Jul 7, 2015):
@xPetrus It's a nice idea, but I honestly don't think it's worth the effort. And it will look weird when only some have graphics.
And it will look weird when only some have graphics.
I think this could be solved by putting a placeholder (e.g. blank circle or something) next to any list that doesn't have a graphic... shrugs
@strugee commented on GitHub (Jul 8, 2015):
> And it will look weird when only some have graphics.
I _think_ this could be solved by putting a placeholder (e.g. blank circle or something) next to any list that doesn't have a graphic... _shrugs_
Yeah, I just prefer the simplicity of text. Logos are all different. In my mind, it would look kinda noisy.
@sindresorhus commented on GitHub (Jul 8, 2015):
Yeah, I just prefer the simplicity of text. Logos are all different. In my mind, it would look kinda noisy.
We're still very much open to improvements and additions. I'm sure there's things we've missed.
@sindresorhus commented on GitHub (Jul 9, 2015):
The awesome manifesto is now live: https://github.com/sindresorhus/awesome/blob/master/awesome.md
We're still very much open to improvements and additions. I'm sure there's things we've missed.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @sindresorhus on GitHub (Jun 24, 2015).
A lot of lists are missing important things or just too low of quality. We could be nice internet citizens and help out those lists.
Common things I open issues about in lists:
Having all lists follow this would improve the quality considerably.
Maybe we could come up with some guidelines on what's a
awesome"certified" list?Anything I missed?
Anyone care to help out opening issues on lists? Both lists included here and not.
@sindresorhus commented on GitHub (Jun 24, 2015):
@n1trux
@arthurvr commented on GitHub (Jun 24, 2015):
Neat idea. Just going through some of the lists. If a list looks unmaintained, should I open an issue to discuss removal and/or finding an alternative?
@sindresorhus commented on GitHub (Jun 24, 2015):
Yes, though unmaintained should be a bit loose, meaning not updated in many months.
@arthurvr commented on GitHub (Jun 24, 2015):
@sindresorhus Well, WDYT? https://github.com/dypsilon/frontend-dev-bookmarks. The 54 open PRs...
@sindresorhus commented on GitHub (Jun 24, 2015):
@arthurvr Would be happy to change the link to an alternative high quality fork, but don't want to remove it as it's a good resource as is.
@inputsh commented on GitHub (Jun 24, 2015):
@sindresorhus Maybe creating a new file called something like
guidelines.mdthat will explain this process?@sindresorhus commented on GitHub (Jun 24, 2015):
@aleksandar-todorovic Yes, that's the idea. Just need to decide on what it should contain first.
@inputsh commented on GitHub (Jun 25, 2015):
Here's my idea. Of course, you could improve the order a bit.
Only link to awesome content.
Don't link to everything people suggest you to link. Research it, find out if it's really awesome and include it if it is.
Request a personal comment on why something is awesome
It's not enough to just suggest something. You also have to say why do you suggest it and how will the potential users benefit from consuming it.
Make it clear on what the list is about
Make sure your list covers a certain scope and nothing else.
Pay attention to the grammar
Please be sure that you do your best to keep the list grammatically correct.
Choose an appropriate license
See Choose a License for more details. Keep in mind that if you haven't selected a license, it basically means the people are not allowed to reproduce, distribute or create derivative works.
NOTE: I did an interview with a GitHub representative about licenses that could be a perfect addition to this section. It'll be online in a couple of days.
Stylize your list properly
Create table of content, put a picture or two, organize the content into different categories.
Accept other people's opinion
If you're an owner of the list, respect other people's opinion. If there are plenty of users not agreeing to your decision, give it a second thought!
@n1trux commented on GitHub (Jun 27, 2015):
Nice idea, I think we should continue our efforts in making the lists better.
I'll start with my own one and then open issues on other lists. Should we mark "certified awesome" lists which adhere to the awesome guidelines with ☑ or ❤ or another symbol to distinguish them from the ones needing work?
Should we create an "awesome.md" with a "check list" or merge the guidelines into contributing.md?
Kind of like an "awesome manifesto"?
@arthurvr commented on GitHub (Jun 27, 2015):
I opened quite a bit of issues on lists last week too.
@sindresorhus commented on GitHub (Jun 27, 2015):
I'd rather we just help everyone get there when the guidelines are decided on. We can remove entries that are non-responsive.
awesome.md file in this repo that is referred to from the readme and contributing.md
@h4cc commented on GitHub (Jun 27, 2015):
I think such a community should be based on standards and choosen membership. A role model or overall inspiration could be these guys: https://thephpleague.com/
Just replace "PHP Packages" with "Awesome Lists/Content".
@sindresorhus commented on GitHub (Jun 27, 2015):
What does that even mean? Elaborate?
@n1trux commented on GitHub (Jun 27, 2015):
Fair enough.
Okay, I'm doing just that. Should I create a PR or push directly and we discuss later?
@sindresorhus commented on GitHub (Jun 27, 2015):
You can usually just push directly, but I think it would be helpful to do a PR so we can discuss directly there.
@h4cc commented on GitHub (Jun 27, 2015):
@sindresorhus Its a term i used for the "we" in your previous sentence:
Defining what is "certified" needs to be a rfc-style decission needed a group of people.
Also calling it "certified" might be counterproductive by scaring maintainers and producing competition. A open and friendly group that could be joined on free will seems way more friendly to me.
@n1trux commented on GitHub (Jun 27, 2015):
Fair enough.
Okay, I'm doing just that. Should I create a PR or push directly and we discuss later?
@arthurvr commented on GitHub (Jun 27, 2015):
Create a PR so we can discuss it first.
@arthurvr commented on GitHub (Jun 27, 2015):
Also worth checking some lists for broken links. Found quite a bunch of them.
@h4cc commented on GitHub (Jun 27, 2015):
That could be offered as a service. Or every list would have to integrate that into its own CI with travis or such (what i already did).
@n1trux commented on GitHub (Jun 27, 2015):
oh fuck. Accidentally uploaded it before branching :/
https://github.com/sindresorhus/awesome/blob/master/awesome.md
er, should I remove it again or should we just discuss it now? facepalm
@sindresorhus commented on GitHub (Jun 27, 2015):
@n1trux Fixed it for you. Just click the green pull request button in the repo ;)
@dypsilon commented on GitHub (Jun 29, 2015):
@sindresorhus I will go through your list and improve the quality of frontend-dev-bookmarks asap. Thank you for your contributions to the community.
@gothburz commented on GitHub (Jul 7, 2015):
You know what would be awesome but a long process? adding the logos to each link or just the big ones.
@sindresorhus commented on GitHub (Jul 7, 2015):
@xPetrus It's a nice idea, but I honestly don't think it's worth the effort. And it will look weird when only some have graphics.
@strugee commented on GitHub (Jul 8, 2015):
I think this could be solved by putting a placeholder (e.g. blank circle or something) next to any list that doesn't have a graphic... shrugs
@sindresorhus commented on GitHub (Jul 8, 2015):
Yeah, I just prefer the simplicity of text. Logos are all different. In my mind, it would look kinda noisy.
@sindresorhus commented on GitHub (Jul 9, 2015):
The awesome manifesto is now live: https://github.com/sindresorhus/awesome/blob/master/awesome.md
We're still very much open to improvements and additions. I'm sure there's things we've missed.