Voting system

[markets]

In order to ensure higher quality of resources, could be a good idea to introduce some kind of simple voting system.

• 5 postive votes (+1) => add it to the list (or merge PR if any)
• 5 negative votes (-1) => remove it from list

What do you think? We can add a VOTING.md file explaining the rules or just add a section into the CONTRIBUTING.md document.

[LuqiPan]

How about this:

Each gem-adding pr only adds 1 gem at a time, and should append [add-gem] before the title of the pr.

Then people can directly vote as a comment for the pr. And also they can provide some reason for up-vote or down-vote.

[markets]

Yes, votes could be :+1: or :-1:. What do you think about place for this explanations, new file or contribution guides?

[LuqiPan]

I think the format for the PR sould go into contributing guide.

But the voting rules could also go into the README file, maybe in the first several paragraphs, because voting takes even less effort than a pr, so people can always contribute to this by just voting.

[markets]

Agreed. It will be more visible for everybody. I'll do it in this way next days (some draft will be really appreciated :smile:)

[markets]

Also, we can use labels/colors to [add-gem] PR and the same for [delete-gem] => ++ visibility

[LuqiPan]

Yeah, labels will definitely make it more easy to find/filter.

[anggiaj]

DevDocs has nice voting system :)

https://trello.com/b/6BmTulfx/devdocs-documentation

[sshaw]

The contribution guidelines are clear, voting could lead to unneeded exclusions and bickering. Really seems like overkill and will make things unnecessarily complicated, IMHO.

[markets]

@sshaw I see your point, but I think we need some kind of filtering. Otherwise, the list could grow a lot and may lose value. The idea is to add only awesome/bests/essentials/most-used projects/resources for each category, as is described in quality standards. This will ensure better quality IMHO.

[mbrookes]

This is always going to be a challenge, as there are some absolute gems (ho-ho :smile: ) out there that aren't necessarily well know, but equally there are some must-haves that aren't well maintained.

Short of building a replacement for Ruby Toolbox, I think the only pragmatic way is to have some quantitate measures to judge by, but that @markets gets to make editorial decisions for gems that fall outside of whatever the defined rules are (DataMapper for example).

Measures could include:

• Number of Github stars
• Time since last update
• Ruby version supported
• Rails version supported (if Rails specific)

etc.

Trouble is, someone then has to manually iterate over the list pruning as needed. Also something could get removed which subsequently gets updated, so removals would have to be tracked.

Tricky!

[markets]

Quantitative measures would be very useful, like RubyToolbox has. But, since (at least for now) this project is just a markdown file, it's not easy to mantain something dynamic (just comment-votes on issues or external services).

An option could be: write some ruby scripts to fetch the data and update the Readme file, run the script regurally.

Another option: convert to an app, similar to RubyToolbox but with different ideas and features. This way allows us to add cool features like: stars, downloads, votes, contributors, last update... There is a similar project here: https://github.com/stevepm/populargems

I personally like the project as it is, due to its simplicity (and ToC format). Btw, RubyToolbox is very useful and would be very positive for the project and the community if it was open-sourced (news on this @colszowka ?). In this way, both projects can coexist and bring different things to the Ruby ecosystem.

Any kind of idea or feedback is really appreciated :+1:

Should we start to think in a new dynamic app?

[mbrookes]

On the quantitive measures, you could still have these, but as contribution guidelines - must have 50 stars and have been updated within 12 months to be added, will be removed if it hasn't had an update for 24 months, that sort of idea...

I like the simple format too, I was just trying to think of a way to enforce some rules so the list doesn't bloat with every gem out there, without adding a huge maintenance burden.

Your script idea sounds like it might strike a good balance.

[markets]

Yes, some extra rules as contribution guides + script to update the file is probably a good balance.

Having this data, the links, into a kind of structured data (Array, Set, Hash, JSON, YAML, ...) would facilitate things and would be easy to build for example: an API, a simple CLI to list things in the terminal...

If we take that path, we should consider a couple of scenarios:

a) keep Readme as "database" => scripts should parse the file b) move database to Array, Set, Hash, JSON, YAML... => Readme would be built via the scripts

[mbrookes]

I can't decide between them: :a: :game_die: :b:

b) is probably easier, but effectively excludes using Github PRs as a contribution mechanism...

[markets]

Option b) doesn't exclude PRs. Data will be stored in a file and tracked in the repo. For example:

data
└── awesome.yaml
scripts
├── build
├── update
└── ...
README.md
CONTRIBUTION.md

Updates would go here, not to Readme file:

# awesome.yaml
abstraction:
  - name: ActiveInteraction
    link: http://...
    description: Manage application specific business logic
  - name: Cells
    link: http://...
    description: View Components for Rails.

[mbrookes]

Good point, I wasn't thinking of them in that form. But now that you mention it, they're all just serialisation formats at the end of the day!

[markets]

Good example: https://github.com/clayallsopp/motion-toolbox.com.

They have all the data in a JSON: https://github.com/clayallsopp/motion-toolbox.com/blob/master/data.json.

I also like this approach, it's simple, we have the data into a structured type and people can keep contributing with ease.

[mbrookes]

Yes, although I think your YAML example is probably less prone to errors...

[mbrookes]

The other thing I wondered is if it would be worth having additional meta-data in the YAML for example whether the resource is Rails specific. But by extension we could split the list and have awesome-ruby, and awesome-rails, which would help with bloat, and keep the lists focused. Thoughts?

[markets]

I'm also thinking on focus more efforts to the site part. That will allow us to make a more friendly and interesting presentation of all of this data. Good example https://github.com/clayallsopp/motion-toolbox.com; simple, easy to mantain, easy to contribute, good results.

Some ideas:

• Keep as a static site (Middleman or Jekyll integration) to be deployed to GH pages
• Resources stored into a YAML
• Tags per item (into the YAML) => we could use it to implement filters (by Rails projects for example)
• Fetch some meta-data from GitHub via script

I really like current workflow: push commit to readme file => site autoupdated (fetching file via ajax + github api), but I'm valorating all those changes too. Would be awesome to have some nice frontend theme (I have very little knowledge of design stuff :sweat_smile:) and design.

[markets]

I have opened a new issue (https://github.com/markets/awesome-ruby/issues/189) to think/discuss the migration to another system. Let's keep this issue for the voting discussion.

[markets]

Let's use GitHub reactions and comments to let the community to express their thoughts. Added to contribution guides here https://github.com/markets/awesome-ruby/commit/56ecd65d0d7c221a0103344b2dfc0d2e2eb65787

[ghost]

would it be feasible to implement github's .github folder templates to enforce these guidelines?

[markets]

hi @bernsie, do you mean to copy the content of CONTRIBUTING.md file to a PULL_REQUEST_TEMPLATE.md? Would be nice if GH allows symlinks for that...

PS. this works right now https://github.com/blog/1184-contributing-guidelines

[ghost]

something along those lines yes.

[markets]

@jbernsie pushed here, what are your thoughts about content or formatting? If you think on any modification that improves that file, please don't hesitate to send your proposal. Thanks!

[ghost]

@markets Looks good to me man 👍 no complaints haha