How to conquer the Multiverse about awseome-301daysofcode-test

[benjaminspak]

I was thinking of this issue the other day. People enjoy ranking, but how do we make an objective ranking system that favors quality over popular opinion.

Ultimately, while not automated, we should make this process vetted with certain quality criteria. Someone who shares a resource must have a reason behind why they are sharing it. Then, a small team of reviewers can assess if the resource is good.

[maxdevjs]

Interesting points. I share your POV, anyway a couple considerations:

• can we have an objective ranking system? How can we assert that my criteria as reviewer is most valuable of your as proponent?
• or that quality over popular opinion is the best option when people is targeted beneficiary?
• how to put together such like-minded team?
• ranking is actually needed (from the beginning)?
• from contributing.md (which is just an example):

Use the following format: [Resource Title](link): Description.

the description could include the reason. Every submission (and every self adding to the community) would be a pull request, then the team would unfailingly assess the content, if necessary rejecting it.

Then

• a team is needed
• how to maintain everything the simplest possible

[benjaminspak]

Hmm good points and questions.

We could allow members to list:

• overall experience with programming
• top 3 favorite resources

Then, simply make a list of the members' top 3 resources per member.

[benjaminspak]

This would:

• Require members to rank their best/favorite resources.

• We would sacrifice a little objective quality, but not require a team.

• Member would feel like they had greater control.

• We imply the difficulty level of the resources based on the years of experience a member has.

• Then, members would know which resources may be more tailored to beginners, and which may require more of an expert's POV to understand.

• We could also limit the possibility of one member sharing many resources. Which, over time I would assume the quality of their resources would decrease.

• Also, early adopters could post often, and build up a sub-faction within the group. This would pull focus away from the group as a whole, and onto one member. Ideally, I'd like to avoid this.

[maxdevjs]

Something like this?

- your surname and name [about](http://example.com/about) | [301-days-code journal](http://example.com/301-days-code-journal) | [twitter](https://twitter.com/example) | [github](https://github.com/example)
- one sentence overall experience with programming when entering 301-days-code (otherwise this would quickly get outdated needing further updates)
- three preferred resources (assuming people would want to be added at the beginning, how can they know what is actually effective for personal learning in the field?)

would read:

• your surname and name about | 301-days-code journal | twitter | github
• one sentence overall experience with programming when entering 301-days-code (otherwise this would quickly get outdated needing further updates)
• three preferred resources (people at the beginning can know what is effective for personal learning?)

without a learn section / folder / entry. Straightforward and manageable, I like it.

At first I thought that the learn section would not require a rigid "commitment", allowing people to feel more free. The three resources structure overtime could make people willing to change the initial idea -> further overload for team / maintainer(s)?

The following are pertinent points:

• We could also limit the possibility of one member sharing many resources.
• Also, early adopters could post often, and build up a sub-faction within the group.

I can be be wrong, but those issues would be naturally addressed by the pull request acceptation process: assumed that the pull request is analyzed by someone you trust, automatically (human fault allowing) some skimming is embedded and inevitable.

Paradoxically, early adopters would be the easier to be checked, due to smaller number of entries

[benjaminspak]

Hmm that is a really good point. Early adopters would be easier to be checked. They would have more helpful resources than a newbie would too.

How about we allow 3 resources as a founder perk? 3 resources for the first 100 members, for example.

[benjaminspak]

Maybe the first 10 adapters can contribute more. Then we can narrow the allow the submissions as we grow. If there are dibplicated of resources we can then do a contest to allow member to vote on a new unmentioned resource.

[benjaminspak]

Also, you're right. Pull requests would already act as a filter :)

[maxdevjs]

Yes, good idea (resources).

Twitter Polls (contest)?

[benjaminspak]

Yeah, but I'm open to more ideas :)

[maxdevjs]

Summarizing, what could be the structure? Everything in readme?

[benjaminspak]

Do you think a readme would be the best medium? Or should we list the info on a webpage?

[maxdevjs]

I think Github needs a more effective notification system 😺

Sorry for the late replies.

I do not know. The readme could be a fair starting point, probably would quickly become a mess. If not enough, better to have b and c plans already available.

Anyway, as soon as possible I will start my 300etc journey. I probably will maintain a journal of it. Thinking of a double source system: .md (as backup and readable on a normal repo) and "transpiled" to html pages (for Github pages...?). I will put something in a repo in a couple days, may be can be a base for further ideas.

In the meantime, do you have a particular structure in mind?

[benjaminspak]

So true haha

I think what we came up with before will work well. And I agree, MD will be a good starting point. :)

[maxdevjs]

This has been dormant for some time now. What you think, may have some usefulness?

[benjaminspak]

Yeah, we can use it as a template, if you're like to build out 301daysofcode.com together :)

[maxdevjs]

Oh, wait... switching context, tell me about it :)

Edit.: how do you think it could be implemented?