Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[DOCUMENTATION] It's not 100% clear how to contribute new benchmarks

Open
#205 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Stale
Tech stack
ruby
Domain
documentation

Research direction

Read CONTRIBUTING.md and the benchmark guidance in README.md, then compare the naming examples in code/proc-and-block/proc-call-vs-yield.rb. Document how benchmark contributors should report machine details, interpret the stated improvement goal, name benchmark methods, and determine who updates the README; done means these questions have clear guidance in the contributing documentation.

Written by the indexing model from the issue text.

Description

Suggestion

There's this CONTRIBUTING file with some details https://github.com/fastruby/fast-ruby/blob/master/CONTRIBUTING.md

But I still have questions that I think it's worth documenting:

  • The README says All results listed in README.md are running with Ruby 2.2.0p0 on OS X 10.10.1. Machine information: MacBook Pro (Retina, 15-inch, Mid 2014), 2.5 GHz Intel Core i7, 16 GB 1600 MHz DDR3. Your results may vary, but you get the idea. : ) so it's not clear how and who should update the readme, maybe that should be removed from there and added for each benchmark so people adding benchmarks can add their specs?
  • It's not clear what to do with the Goal described in the Contributing file (for example, it says At least 12% improvement, does it mean that a benchmark showing less than that improvement is not accepted / useful?)
  • I see code that has methods named fast and slow (and even slow2, slow3 https://github.com/fastruby/fast-ruby/blob/master/code/proc-and-block/proc-call-vs-yield.rb), I don't think that's the expectation (it makes things harder to read when multiple methods are called slowX), I think it could be described better in the CONTRIBUTING file if that's actually the case
Dominant language
Ruby
Stars
5.7k
Forks
370
PR merge metrics
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from fastruby/fast-ruby

All issues in fastruby/fast-ruby

Similar issues

More Ruby issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.