DEV Community

Cover image for How to contribute to DEV this hacktoberfest
Ben Halpern for The DEV Team

Posted on

How to contribute to DEV this hacktoberfest

### **First of all, if you haven't yet done so...** ### **[⭐️⭐️⭐️ Add a star to the repo on GitHub ⭐️⭐️⭐️](** **Much appreciated ❤️**

Today is the first day of Hacktoberfest—the world's greatest celebration of open source. 50,000 participants around the world will earn a free t-shirt, plus other great swag and a DEV profile badge. Four pull requests this month is all you need.

While DEV is a co-presenter of the event this year, we are also an open source company! We have several open source repos ripe for contributions. The most significant one is the one that powers this website.

Our purpose for being open source

Open source is sometimes considered a good thing in and of itself. While that may be true, we also feel that it is important to describe our purposes for being open source, as well as the endgame we are building towards.

The central purpose is grounded in promoting transparency and trust. By building our social network with full transparency, we are able to demonstrate exactly how the app works, which data it may or may not be collected, and generally why one should trust the community platform. By building alongside the community itself, we truly get the chance to build what the community most wants, rather than arbitrarily handing down a self-serving vision for what we think social media should be.

The longterm goals are as important as the initial values. While we currently operate a single instance of our software (, we are building towards a re-usable community platform. This product vision will serve more use cases beyond our focus and expertise at DEV, and importantly, it will be free to use without all the value capture being returned to the mothership. We envision a less monolithic future for social networking, where open source technology plays a key role. We anticipate that our core business will be that of a commercial open source shop, rather than a monopoly-model built purely on data surveillance and designed to exploit the attention economy.

All the work that goes into our core platform acts to strengthen the longterm vision, but this second phase we describe has remained just that: secondary. However, shortly after Hacktoberfest, as we conclude 2019, we will be devoting explicit development cycles towards what we call "Phase 2". We will have more information in the coming weeks and months, but for now, the important thing is that we all get together and write features, refactor code, and squash bugs.

How to contribute to DEV

The nitty-gritty can be explained by diving into our repo Readme, documentation, etc...

GitHub logo forem / forem

For empowering community 🌱

Forem 🌱

For Empowering Community

Build Status GitHub commit activity GitHub issues ready for dev GitPod badge

Welcome to the Forem codebase, the platform that powers We are so excited to have you. With your help, we can build out Forem’s usability, scalability, and stability to better serve our communities.

What is Forem?

Forem is open source software for building communities. Communities for your peers, customers, fanbases, families, friends, and any other time and space where people need to come together to be part of a collective See our announcement post for a high-level overview of what Forem is. (or just DEV) is hosted by Forem. It is a community of software developers who write articles, take part in discussions, and build their professional profiles. We value supportive and constructive dialogue in the pursuit of great code and career growth for all members. The ecosystem spans from beginner to advanced developers, and all are welcome to find their place…

But I want to also provide some high level instruction and ideas about what it might take to contribute effectively. This is not always straightforward, especially if you are new to open source or programming in general.

First of all, contributing to the DEV codebase is different from projects like libraries and frameworks in that this is a whole website. So, contributing to our project is a lot like your day-to-day might be as a developer or general creator of websites. You can dive in, inspect some CSS or some controller code, and get started.

Second of all, DEV is a Ruby on Rails app. That means that we generally follow Rails conventions, so you can learn Rails and have a pretty solid idea of how to trace functionality back to its origins. Rails has some "magic" in that there is some implicit functionality in a lot of places that can make it hard to understand without looking into the docs. It's a beloved and mature framework in general, and worth learning due to its place in the software ecosystem (both present and historical).

You may find this thread helpful if you are new to Rails...

The many ways you can contribute to DEV

And now on to the meat. Let's discuss a few types of contributions that can help us all make these important next steps. Software can be improved in many ways—It's not just bugs and features. Structural improvements along the way are vital for the help of a complex app.

Refactor code

Refactoring is the art of improving code quality without modifying the functionality. While sometimes we find a bug to fix or an edge case to handle while we refactor, the general guideline is that this is purely about code quality.

The refactoring task is generally a matter of discovery, but there are ample opportunities throughout any codebase. Peruse the files, or explore our CodeClimate issues for opportunities that have been raised by this automated quality analysis tool.

Code quality is subjective, but code is rarely perfect and there is sure to be plenty of low-hanging fruit in the DEV app!

Here are some resources on refactoring...

Bug fixes

Bugs are everywhere in our software. EVERYWHERE. Sometimes they are critical path issues that affect all users, and sometimes it is a more tolerable edge case. Either way, we rely on the help of contributors to come up with solutions.

Discover bugs in the codebase by filtering by the bug label.

Here is an example issue...

Bug in uploading cover photo #4098

To reproduce:

  • i was editing one of my old posts, i uploaded a different cover photo
  • without saving, i clicked write a post and started writing a new one
  • the selector for cover photo already had the previous one selected there but it wasn't showing
  • uploading a new photo would do nothing
  • i had to click preview and come back to see the cover photo field empty

Of course, you are more than welcome to discover bugs on your own and then help out by creating your own bug report in the form of an isssue.


Any code which does not have its functionality examined by an existing test should have a test included. Tests in our codebase are found in the rspec folder for backend and fullstack-focused tests. Frontend tests are found in the various __tests__ files within app/javascript.

While tests are an important part of any pull request, it's possible to contribute by writing tests as standalone pull requests. Tests need code improvements like any other part of a codebase, and some elements of our code remain wholly untested. New and improved tests are always helpful in giving us confidence to deploy against our test suite.

This might help you get started with rspec...

On the JavaScript side we use jest. You may fine this helpful...


Features can be one of the more difficult contributions, largely due to communication shortcomings from our core product team—but small contributions to features are always available. When we feel like a feature has enough information that outside contributors will be capable of jumping in, we add the help-wanted label.

Feature development is also most accessible when you can discover green fields with needed maturation. Our API controllers represent opportunities to create new endpoints that we do not already cover. New variations on endpoints can be added without disrupting the current functionality.

Feel free to pitch features in the form of issues. We love pull requests, but it is best when we can discuss the issues ahead of time to avoid any misalignment or confusion.

Here is an example issue...

Collapsing the comment section preference in settings #4103

vhgn avatar
vhgn posted on

I'm always frustrated, when I see a very long scrollbar and can't figure out how long is it going to take to read. There could be a lot of comments which will take a lot of space, so it's uncomfortable to check the progress.

The simplest solution, I think, is adding a comment auto-collapsing feature in settings. When I turn on "Auto-collapse comment/bottom section" in my preferences, every new article loaded will not have comments and featured articles, instead there can be a simple "Show comments" button which will unwrap the components.

Accessibility (a11y)

Accessibility is a great area to contribute because problems can be discovered through use of the production app and the solutions are often relatively straightfoward for us maintainers to interpret and accept (with exceptions, of course). Accessibility is also critical for any application and we strive to provide an accessible experience. This will be especially important as our open source code begins to earn usage outside of our domain, where we have the potential to have a broader impact.

If you identify accessibility issues, please chip in with an issue or pull request!

Documentation (and copy)

For the health of our project, it is important that the next person understand how to get started. If you encounter any counter-intuitive elements of our codebase, feel free to contribute to our documentation.

Documentation can be found in the docs folder, and will be built as a static site at Our API docs can be found in api_v0.yml.

Our app is also full of "copy", e.g. the text that explains things for the end user. If there are any improvements to be made here, perhaps in emails or in signup copy etc. Please go for it!

Final thoughts

We welcome all sorts of contributions, and encourage you to read our documentation, to look for friendly labels, and to get involved in the project.

Please think of it as a longterm relationship. Sometimes we can't merge your pull request. Sometimes we might need to give you more context about how a feature should work.

Let's all work together on building the most inclusive and constructive community in the coding world... And an open source codebase which will live on to provide welcoming community in every other world it is needed.

Happy coding!

Top comments (6)

lightalloy profile image
Anna Buianova

A couple of issues from me to contribute to:

Few items left to move delays to ActiveJob:

Move delay calls to ActiveJob #3136

As described in #2497, to be less dependent of DelayedJob we also need to move jobs which are created by calling delay method to ActiveJob:

Here is the list of the calls:

  • [x]
  • [ ] MembershipMailer.delay.new_membership_subscription_email
  • [ ] MembershipMailer.delay.subscription_update_confirm_email
  • [ ] MembershipMailer.delay.subscription_cancellation_email
  • [ ] user.follow
  • [ ] reaction.create
  • [ ]
  • [ ] HtmlVariantSuccess.create
  • [ ] HtmlVariantTrial.create
  • [ ] message.send_push
  • [ ]
  • [ ] several calls in trigger_delayed_index

Actions for each of the calls:

  • create a corresponding ActiveJob, specify a queue name
  • call the required method inside a job
  • replace the delay method calls with a job perform_later call
  • you may need to modify the existing tests by using perform_enqueued_job instead of run_background_jobs_immediately helper

Remember to pass record ids (if needed) instead of ActiveRecord objects to a job to avoid deserialization errors (#1621)

<div class="gh-btn-container"><a class="gh-btn" href="">View on GitHub</a></div>

Remove unused methods:

Remove unused `_without_delay` methods #2950

While asynchronous methods are being moved to separate Active Jobs (#1996, #2497), we keep _without_delay methods for a while, because the jobs that use this method can still exist at the moment of deploy. But eventually, we need to delete them to declutter because most of them are not actively used in the codebase. Some of these methods are used in the codebase explicitly. I suppose that it's worth to replace such calls with the perform_now job calls. But at least we should delete the unused methods.

<div class="gh-btn-container"><a class="gh-btn" href="">View on GitHub</a></div>

Display podcast episode's published_at date #3498

I would like to see published_at date of an episode on its page, in the podcasts feed and on the podcast's episodes list. It would allow me to understand if the episode is fresh and if the podcast is active.

<div class="gh-btn-container"><a class="gh-btn" href="">View on GitHub</a></div>

ben profile image
Ben Halpern

I'm already on my way 😉

jess profile image
Jess Lee

I can't believe so many people have already completed the challenge 🙀

amorpheuz profile image
Yash Dave

Hyped to continue contributing to the repo throughout hacktoberfest! Good luck to all the contributors.

ben profile image
Ben Halpern


terceranexus6 profile image

Already sent a PR! I wanted to be able to add my mastodon instance for a while now... I would be happy if I can contribute with your repo as well!