What to contribute
We are always looking for contributions to the Open Build Service.
In particular, this community seeks the following types of contributions:
- code: bug-fix and expand the features of the Open Build Service
- UI/UX design: Improve the look of the OBS UI and enhance how the UI elements work together to create a seamless user experience
- copy editing: fix typos, clarify language, and generally improve the quality of the content of the Open Build Service
- testing: review what the OBS team is working on and/or help out with our automated tests
Read this guide to understand what you can contribute to do that.
Once you are clear on how to contribute code here's a list of things the Open Build Service especially will benefit from.
We maintain a list of bugs and features that we think are easy to start with for the Ruby on Rails application that serves the user and the API interface of the OBS.
If you are new to OBS and/or new to Ruby on Rails this is a good starting point to become a regular contributor to this part of the OBS.
Our CI cycle includes static code analysis for our Ruby code. We only bypass it (take on technical debt) seldomly. But of course at the point we introduced this checking we have not been free of problems. So you find a long TODO list about cognitive/cyclomatic complexity, code duplication etc. in codeclimate that needs addressing.
The same is true for our Ruby style linter Rubocop. We track a TODO list about lots of linter violations that either need (automatic) fixing and review or someone starting a discussion among the OBS developers to agree on a default.
We maintain a list of technical debt we took on and have have the obligation repay some time... If you are a Ruby on Rails expert this is a good starting point to find things worth working on. Many of them include introducing new software design patterns to the code base, major architectural changes and fixing complicated issues. Very good opportunities to get exposure for your Rails kung-fu!
So we always need help to improve the look of the OBS UI elements and enhance how those elements work together to create a seamless user experience. We maintain a not-very comprehensive list of UI / UX Design issues that we think are easy to start with for the OBS user interface which is a good starting point.
But we also don't mind page by page reviews, re-designs and mock ups... The OBS UI has evolved for over a decade (we started in 2006 the year Taylor Swift released her first single!), it's dragging lots of UI cruft and UX problems. And as OBS is a tool for developers, most contributors are also developers who are not necessarily the best UI/UX designers out there, there we said it! 🙊
We would ❤️ to comply to the Web Content Accessibility Guidelines (WCAG) international standard on each and every page in our UI. But we have many issues and no automated accessibility testing.
We aim for the OBS UI to provide a fully responsive web experience. We have the basics covered by using a responsive UI framework and have re-designed a couple of workflows already. But for sure there are many UI elements / pages / workflows left that do not follow our Responsive-Guidelines and the general best practices.
- Proofread
- Update screenshots
- Add chapters
- Introduction to workflows / features
- How to do XYZ... articles
- Document sub-systems
- How to do XYZ... pages
When we are introducing new features or bigger redesigns of existing patterns in the Open Build Service, we do this as part of the beta program. In order to push those features in the right direction, we rely on the feedback of users. You can contribute by joining the beta program and help with us with your feedback.
We are running an extensive automated test suite in our CI cycle. Overall coverage is already at a whooping but that means there are some code paths and workflows not covered yet. If you are knowledgeable in Ruby on Rails and RSpec please help us to improve the spec.