Curated list maintained by the community #91

New Issue

GiteaMirror · 2025-11-06T15:05:41-06:00

GiteaMirror commented

2025-11-06 15:05:41 -06:00

Originally created by @brillout on GitHub (Jul 17, 2016).

While curating a list of react components/libraries I realized that this is a lot of work for a single person. They are around 10 000 of them. Even for a small group of person this is still a lot of work.

I'm writing a prototype to let the community decide if a resource should be included to the list or not.

A problem I can see with that is the quality of curation to be lower.
Although, if for example 5 persons say that a resource is useful then it could/should be a reason enough to include this resource to the curated list.

Thoughts?

Originally created by @brillout on GitHub (Jul 17, 2016). While curating a list of react components/libraries I realized that this is a lot of work for a single person. They are around 10 000 of them. Even for a small group of person this is still a lot of work. I'm writing a prototype to let the community decide if a resource should be included to the list or not. A problem I can see with that is the quality of curation to be lower. Although, if for example 5 persons say that a resource is useful then it could/should be a reason enough to include this resource to the curated list. Thoughts?

GiteaMirror closed this issue

2025-11-06 15:05:41 -06:00

GiteaMirror commented

2025-11-06 15:05:42 -06:00

@sindresorhus commented on GitHub (Jul 21, 2016):

Does it really matter if there are 10.000 of them? You only include what you have experience with and good stuff people suggest. No point in going through them all. Let the community suggest what they find to be the best.

Although, if for example 5 persons say that a resource is useful then it could/should be a reason enough to include this resource to the curated list.

With voting, rarely. I don't think democracy is able to collectively reason about quality. Then it becomes more of a popularity contest. A person bothering to submit a pull request is a better metric.

@sindresorhus commented on GitHub (Jul 21, 2016): Does it really matter if there are 10.000 of them? You only include what you have experience with and good stuff people suggest. No point in going through them all. Let the community suggest what they find to be the best. > Although, if for example 5 persons say that a resource is useful then it could/should be a reason enough to include this resource to the curated list. With voting, rarely. I don't think democracy is able to collectively reason about quality. Then it becomes more of a popularity contest. A person bothering to submit a pull request is a better metric.

GiteaMirror commented

2025-11-06 15:05:42 -06:00

@brillout commented on GitHub (Jul 27, 2016):

No point in going through them all.

That's actually what I want to avoid. I don't have much motivation to go through an enormous amount of components.

But there are many good components missing from the curated list.

So instead of creating a PR, a user would simply fill a form.
That would make adding a react component much easier.
Therefore many more good components could be collected that way.

With voting, rarely. I don't think democracy is able to collectively reason about quality.

Initially my plan was to automatically git push to the curated list once a react component has received 2-3 approvals from peers. But you are probably right and instead I'm going to do a final review and manually git push the changes.

Thanks for the input.

@brillout commented on GitHub (Jul 27, 2016): > No point in going through them all. That's actually what I want to avoid. I don't have much motivation to go through an enormous amount of components. But there are many good components missing from the curated list. So instead of creating a PR, a user would simply fill a form. That would make adding a react component much easier. Therefore many more good components could be collected that way. > With voting, rarely. I don't think democracy is able to collectively reason about quality. Initially my plan was to automatically git push to the curated list once a react component has received 2-3 approvals from peers. But you are probably right and instead I'm going to do a final review and manually git push the changes. Thanks for the input.

GiteaMirror commented

2025-11-06 15:05:42 -06:00

@sindresorhus commented on GitHub (Jul 27, 2016):

So instead of creating a PR, a user would simply fill a form.

It's beneficial to not make it too easy to submit, so people actually only submit stuff they care about.

@sindresorhus commented on GitHub (Jul 27, 2016): > So instead of creating a PR, a user would simply fill a form. It's beneficial to not make it too easy to submit, so people actually only submit stuff they care about.

GiteaMirror commented

2025-11-06 15:05:42 -06:00

@brillout commented on GitHub (Aug 1, 2016):

I'll do a final review to reject low quality submissions.

I see this as an experiment and I guess it's difficult to predict the outcome of this.

This ticket doesn't have much activity so maybe it should be closed in order to keep the issue list small.

@brillout commented on GitHub (Aug 1, 2016): I'll do a final review to reject low quality submissions. I see this as an experiment and I guess it's difficult to predict the outcome of this. This ticket doesn't have much activity so maybe it should be closed in order to keep the issue list small.

GiteaMirror commented

2025-11-06 15:05:43 -06:00

@aschrijver commented on GitHub (Aug 20, 2016):

@brillout I like your idea. Came to this issue, because I find it frustrating that awesome entries are sometimes waiting for months (== ages when converted to non-IT-standard-time 😉 ) before being committed, and was going to suggest something similar. Makes awesome, well....much less so.
(PS I am not blaming the nice chaps that maintain the awesome lists, I know times can be busy).

It could also be a done with a commit hook that checks on some criteria, like formatting and then auto-commits. Could have a filter as well, so it doesn't commit entries with expletive text or clear spam entries. If spam does get through the filter and is added this way, community can file an issue, and PR with removal.

@aschrijver commented on GitHub (Aug 20, 2016): @brillout I like your idea. Came to this issue, because I find it frustrating that awesome entries are sometimes waiting for months (`== ages` when converted to `non-IT-standard-time` :wink: ) before being committed, and was going to suggest something similar. Makes `awesome`, well....much less so. (PS I am not blaming the nice chaps that maintain the awesome lists, I know times can be busy). It could also be a done with a commit hook that checks on some criteria, like formatting and then auto-commits. Could have a filter as well, so it doesn't commit entries with expletive text or clear spam entries. If spam does get through the filter and is added this way, community can file an issue, and PR with removal.

GiteaMirror commented

2025-11-06 15:05:43 -06:00

@brillout commented on GitHub (Sep 1, 2016):

@aschrijver

I find it frustrating that awesome entries are sometimes waiting for months

True that!

auto-commits

I wouldn't do that. Many requests are very low quality. E.g. I checked every component of the awesome-react list and 50% are bad and should be removed (see https://github.com/enaqx/awesome-react/issues/503).

clear spam entries

I actually never saw that. From my experience, it's not a problem. The problem is well intentioned but low quality entries.

Changing the code of conduct as proposed in #748 would probably not address the issue enough. The bottom line is that maintaining a curation is lot's of work and changing the code of conduct will have only a small impact on how much time a contributor spends on his awesome list.

What do you think of making the whole community curate a list? If it works, then it would solve the problem.

@brillout commented on GitHub (Sep 1, 2016): @aschrijver > I find it frustrating that awesome entries are sometimes waiting for months True that! > auto-commits I wouldn't do that. Many requests are very low quality. E.g. I checked every component of the `awesome-react` list and 50% are bad and should be removed (see https://github.com/enaqx/awesome-react/issues/503). > clear spam entries I actually never saw that. From my experience, it's not a problem. The problem is well intentioned but low quality entries. Changing the code of conduct as proposed in #748 would probably not address the issue enough. The bottom line is that maintaining a curation is lot's of work and changing the code of conduct will have only a small impact on how much time a contributor spends on his awesome list. What do you think of making the whole community curate a list? If it works, then it would solve the problem.

GiteaMirror commented

2025-11-06 15:05:43 -06:00

@aschrijver commented on GitHub (Sep 2, 2016):

@brillout, tha would be lovely...seems to me at least 👍

@aschrijver commented on GitHub (Sep 2, 2016): @brillout, tha would be lovely...seems to me at least :+1:

GiteaMirror commented

2025-11-06 15:05:43 -06:00

@brillout commented on GitHub (Sep 18, 2016):

I've been running devarchy.com/react-components for a while now.

the community requested 81 new entries
the community upvoted 67 times (excluding OP upvotes)
the community downvoted 4 times
out of these 81 requests, 33 received votes
48 requests received no votes

I recently made UX changes that makes it easier to vote. I expect the number of votes to increase.

I don't think democracy is able to collectively reason about quality.

@sindresorhus

Cases of "wong" upvotes: (I.e. when the community upvoted a new entry request I ended up rejecting.)

I rejected 1 entry because of its bad quality. It got 1 upvote.
I rejected 2 entries because of missing English documentation. That was the only reason for rejecting them. They got 1 upvote each.

All downvotes led to reasonable rejections.

It seems that "wrong" upvotes is less a problem than I thought: out of 71 votes, only 1 was clearly "wrong".

(Btw. it is amazing the amount of great react components out there. Open source really is marvellous.)

@brillout commented on GitHub (Sep 18, 2016): I've been running [devarchy.com/react-components](http://devarchy.com/react-components) for a while now. - the community requested 81 new entries - the community upvoted 67 times (excluding OP upvotes) - the community downvoted 4 times - out of these 81 requests, 33 received votes - 48 requests received no votes I recently made UX changes that makes it easier to vote. I expect the number of votes to increase. > I don't think democracy is able to collectively reason about quality. @sindresorhus Cases of "wong" upvotes: (I.e. when the community upvoted a new entry request I ended up rejecting.) - I rejected 1 entry because of its bad quality. It got 1 upvote. - I rejected 2 entries because of missing English documentation. That was the only reason for rejecting them. They got 1 upvote each. All downvotes led to reasonable rejections. It seems that "wrong" upvotes is less a problem than I thought: out of 71 votes, only 1 was clearly "wrong". (Btw. it is amazing the amount of great react components out there. Open source really is marvellous.)