How to contribute to DEV this hacktoberfest
Tags: hacktoberfest, beginners, contributorswanted
Published: 2019-10-01 13:35:26

<center>
### **First of all, if you haven't yet done so...**

### **[⭐️⭐️⭐️ Add a star to the dev.to repo on GitHub ⭐️⭐️⭐️](https://github.com/thepracticaldev/dev.to)**

**Much appreciated ❤️**
</center>

Today is the first day of [Hacktoberfest](https://hacktoberfest.digitalocean.com/)—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](https://github.com/thepracticaldev/dev.to).

## 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 (dev.to), 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 thepracticaldev/dev.to %}

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...

{% link https://dev.to/nickytonline/what-arewere-your-go-to-resources-for-learning-ruby-and-rails-5611 %}

## 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](https://codeclimate.com/github/thepracticaldev/dev.to/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...

{% link https://dev.to/spalonytoster/refactoring-not-so-scary %}

{% link https://dev.to/arne_mertz/refactoring-basics %}

{% link https://dev.to/jnschrag/refactoring-the-worst-code-i-ve-ever-written-42c7 %}

### 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](https://github.com/thepracticaldev/dev.to/issues?q=is%3Aopen+is%3Aissue+label%3A%22type%3A+bug%22).

Here is an example issue...

{% github https://github.com/thepracticaldev/dev.to/issues/4098 %}

Of course, you are more than welcome to discover bugs on your own and then help out by [creating your own bug report](https://github.com/thepracticaldev/dev.to/issues/new?template=bug_report.md) in the form of an isssue.

### Tests

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...

{% link https://dev.to/jeremy/rspec-from-scratch-part-1-how-to-write-a-test-4ce8 %}

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

{% link https://dev.to/softchris/testing-your-apps-like-a-boss-with-react-js-and-jest-1hkh %}

### Features

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](https://github.com/thepracticaldev/dev.to/issues/new?template=feature_request.md). 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...

{% github https://github.com/thepracticaldev/dev.to/issues/4103 %}

### 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 [docs.dev.to](https://docs.dev.to). 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!