My Experience Contributing to Open Source

December 16, 2020

Subscribe and stay up to date

No spam, we promise! You will only 
receive essential emails.
coding python
Joaquin Garmendia
Written By
Joaquin Garmendia
Topic
Engineering

Why I will choose to contribute to open source in the future


Contributing to open source is a fun way to learn and improve your coding skills - and you get to do so by helping others. Open source communities are often open to new participants in a learning environment; this makes the experience of contributing joyful.

 

A good way to decide where to contribute is to choose open source software that you use daily. In that sense, if you know the software that you are about to contribute to, you can identify easily where help is needed and where you can add new and interesting features.

 

In this article I will detail contributions that I made and demonstrate more or less the workflow of contributing to Open Source. The projects I will focus on are the following:

  • scrapy: Python web crawling and scraping framework. 
  • jrnl: Text journal application for the command line.
  • polybar: A fast and easy-to-use tool for creating a status bar.

 

 

Scrapy| Add a new extension to check settings names 

Scrapy is a very customizable tool; one of the main ways to customize it is through settings. Scrapy settings allow you to customize the behaviour of all Scrapy components, including the core, extensions, pipelines and spiders themselves. The infrastructure of the settings provides a global namespace of key-value mappings that the code can use to pull configuration values from.

 

So, for example if `DNSCACHE_ENABLED` is set to True, our spider will enable DNS in-memory cache. Scrapy has a LOT of configurable variables that are prone to typo errors that did not provide enough feedback for new users to discover this trivial error.

 

This contribution tries to solve that problem by creating a new extension. Initially, a linter was  proposed for the issue, but after some discussion consensus was that a runtime approach will be better. The extension finds unused settings by reading an attribute (`has_been_read`) in the settings dictionary and if possible will suggest a possible replacement. Another advantage of this runtime approach is that it will also find unused settings that possibly are not misspelled settings.

 

PR: https://github.com/scrapy/scrapy/pull/4828

 

 

Scrapy| Add failed and success count stats to feedstorage backends 

Scrapy allows users to specify how to export extracted data (.xml, .json, .csv, etc) and also where to save it (the local filesystem, S3, Google Cloud, an FTP server, standard output). However, those storage backends did not save performance information at the end of the run. A good place to save this information are the statistics that Scrapy generates during the run. These stats can be used to measure how the run performed, as it contains stats about memory usage, the finish timestamp and starting timestamp, etc. 

 

The idea of this PR is to add a new stat that will help users to know if the storage backend had some problem while saving. For example, if a spider saves to S3 and the local filesystem but the S3 credentials were wrong, this stat will be presented to the user:

{...

 'elapsed_time_seconds': 11.61577,

 'feedexport/failed_count/S3FeedStorage': 2,

 'feedexport/success_count/FileFeedStorage': 2,

 'finish_reason': 'finished',

 ...}

 

PR: https://github.com/scrapy/scrapy/pull/4850

 

 

jrnl | Add default display format option to config file

jrnl supports a wide variety of formats(Markdown, JSON, YAML, etc); however the usability for this feature was not the best. That is because if you want to (for example) print the last eight entries in Markdown format you can use this command:

 

jrnl -8 --export md

 

 

That could be tedious for users that want to print as Markdown every time, because they must add the `--export md` option continually. In order to avoid that annoyance, this contribution adds a new option to the configuration file: `display_format`, which is an option that can be set to any of the exporters that jrnl has.

 

PR: https://github.com/jrnl-org/jrnl/pull/1050

 

 

Polybar| Remove upper bound to get_volume

Polybar has a feature to show a system’s actual volume. The problem is that it does not “recognize” when volume goes beyond 100%. This is a possibility that sound systems such as PulseAudio gives you, allowing you to increment volume beyond 100% to 150%.

 

This minor feature only requires avoiding clamping the volume between [0, 100]. Maybe the “hardest” part was compiling the code and testing the changes.

 

PR: https://github.com/polybar/polybar/pull/2184

 

 

Conclusion

Knowledge obtained from discussions with maintainers, getting more involved with projects that were interesting to me, and the welcoming communities are some of the major reasons I will seek to contribute to open source in the future.

What are your thoughts on open source?

View all posts

Subscribe and stay up to date

No spam, we promise! You will only 
receive essential emails.

Speak Your Mind

book a free demo

Subscribe and stay up to date