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

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

What are/were your go to resources for learning Ruby and Rails?

Nick Taylor ・ Aug 18 '18

#discuss #ruby #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...

Refactoring is not so scary

Maciej Posłuszny ・ Aug 19 '17

#refactoring #cleancode #languageagnostic

Refactoring Basics

Arne Mertz ・ Sep 1 '17

#refactoring #cleancode #coding #development

Refactoring the Worst Code I’ve Ever Written

Jacque Schrag ・ Apr 18 '19

#javascript #beginners #es6 #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

AlbertoMontalesi posted on Sep 23, 2019

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

View on GitHub

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.

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

TDD Basics: How to Write an RSpec Test

Jeremy Schuurmans ・ Jun 12 '19

#ruby #testing #tutorial #beginners

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

Testing your apps like a boss with React.js and Jest

Chris Noring ・ Jun 9 '19

#beginners #react #tutorial #javascript

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. 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 posted on Sep 25, 2019

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.

View on GitHub

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