How Can I Contribute

Contribution
1
There are many different ways to contribute to Taiga’s development, just find the one that best fits with your skills. Examples of contributions we would love to receive include:
  • Bug reports
  • Code patches, enhancements
  • Contrib Plugins
  • Documentation improvements
  • Translations
  • UI enhancements

All of these ways may affect the API, the UI, language localization… or other parts of Taiga. There isn’t a single way to contribute, and we’ll be happy to help you with your contributions.

Big features are also welcome but if you want to see your contributions included in Taiga codebase we strongly recommend you start by initiating a chat in this article.

Developer Certificate of Origin + License

Contributing to Taiga by adding code to its repositories (typically a Pull Request) implies acceptance of the DCO and License terms.

By contributing to Kaleidos Ventures, Inc. You accept and agree to the following terms and conditions for Your present and future Contributions submitted to Kaleidos Ventures Inc. Except for the license granted herein to Kaleidos Ventures Inc. and recipients of software distributed by Kaleidos Ventures Inc., You reserve all right, title, and interest in and to Your Contributions.

All Contributions are subject to the following DCO + License terms.

Bug reports

Bugs are about code, but not only about code. You can find a bug in the UX, the design, the translations, the documentation. If you find a bug in Taiga you can always report it:

One of our fellow Taiga developers will search, find and hunt it as soon as possible.

Reporting a bug: Please, before reporting a bug, take time to write down as much detail as possible: explain why this is a bug for you and how can we reproduce it. It’ll be useful as well to know your Operating System and your browser and version. If it’s possible, attach a screenshot to give more context to the bug.

Usually, it takes less time to fix a bug if the developer knows how to find it. Thanks to that information, we’ll be faster fixing any bug.

Localization Bugs: Taiga use Weblate to manage the i18n files so don’t submit a pull request to those files (except -en.json). To fix a translation, just access our team of translators, set up an account in the Taiga Weblate project and start contributing.

Code patches, enhancements

Taiga will always be glad to receive code patches to update, fix or improve its code.

If you know how to improve our code base or you found a bug, a security vulnerability or a performance issue and you think you can solve it, we will be very happy to accept your pull-request. If your code requires considerable changes, we recommend you first talk to us directly. We will find the best way to help. If you would like to implement it by yourself consider if it’s a small or a big change.

Besides, you’d probably like to make yourself confortable with the development environment. If you find some problems, please let us know in our troubleshooting section.

Small Changes

They can be crafted and submited to the Github repositories as a Pull Request.

Major Changes

Before contributing with a major change to Taiga, it should be discussed first with the Taiga Team so that we can better coordinate our efforts, prevent duplication of work, and help you to craft the change so that it is successfully accepted into the project. Please, contact us by writing a comment in this article or via [support@taiga.io](Support email).

We have defined a concrete workflow for these changes:

  1. User Story: Send us a complete description of the functionality you’d like to develop, how it should work, for which profiles, as if you were writing a User Story. Please include some ideas of what would be a definition of Done of the User Story. The team will review it, decide whether or not it could make it into Taiga Core. If not, you can always write a plugin.
  2. Mentorship: If accepted, Taiga team will help you, and a person from the team will be your contact in the development process. The Story will be visible in the Taiga Kanban.
  3. User Experience: The functionality will require some wireframes or ideas to be developed correctly. A good UX its an essential part of Taiga success. You should create a user experience proposal and the Taiga UX team will help you.
  4. Design: The design should respect the Taiga style. Try to reproduce other areas of the site. The Taiga design team will review this proposal as well.
  5. Development: The next step is the development. Remember to add unit, integration and e2d tests as well as the new code. We have the API well documented too in taiga-doc.
  6. Pull request: The last step it to create the Pull Reuqest. Remember to add a good description and screenshots are welcome too. Once the pull request is done, someone else from the team will review the code to ensure that it fits with the good practices and styles. If it does, the PR will be merged and will be on the next Taiga release.

Don’t forget to add your name to AUTHORS.rst file!

If you think you are not able to do one or more of the parts of the process, your contribution is still welcome, but we cannot ensure that it will make it soon into the Taiga core anytime soon. It will depend on our priority backlog.

Thanks a lot! It is really great that we could make Taiga better with the help of the community.

Contrib Plugins

Taiga supports contrib plugins to add or overwrite some functionalities. You can create your own contribs and share the the community or use any of the contrib plugins.

Documentation improvements

Currently, we have authored three main documentation hubs:

  • API: Our API documentation and reference for developing from Taiga API.
  • Documentation: If you need to install Taiga on your own server, this is the place to find some guides.
  • Taiga Resources: This page is intended to be the support reference page for the users.

If you find some errors, or want to propose changes to improve readability, you can create issues or submit code changes to these repositories:

Translations

We are eager to get your help translating Taiga. It’s easy (and fun!): just access our team of translators with the link below, set up an account in Weblate and start contributing. Join us to make sure your language is covered! Help Taiga to translate content

Localization Bugs: Taiga use Weblate to manage the i18n files so don’t submit a pull request to those files (except -en.json). To fix a translation, just access our team of translators, set up an account in the Taiga Weblate project and start contributing.

UI enhancements

Taiga is made for developers and designers. We care enormously about UI because usability and design are both critical aspects of the Taiga experience.

If you have some ideas to make Taiga UI better, we will love to receive your feedback. Please send us your enhancement, with the reason and, if possible, an example. Our design and UX team will review your proposal as soon as possible. We recommend you to leave your messages in this article so we can have a lot of different opinions and debate.

3

;k,`o’l.-pWe are very excited about TaigaNext and use it for managing projects daily. I wanted to toss a hat into the ring for schedule management for TaigaNext. While I do understand the freedom of schedule concept, pretty much every task in Taiga has a real world interface with a calendar. From everything to meeting deadlines, to “what the heck am I working on today?” Our team would love to see task scheduling, and some kind of calendar export\integration. Maybe a Gantt chart for project timelines. This is the one thing we are missing terribly, and at times has us considering other options. We come running back to taiga for simplicity and fast interface. Great work by the whole team in any case. Thanks to all.

4

UI suggestion for epics

The progress bar for epics only have 2 colors at the moment.

If we can have the color code of the user stories populate the progress bar that would be really cool. This will allow users to see at a glance what tasks are contributing progress (or lack of).

At the moment, only tasks that are marked “done” (is closed) contributes to the progress bar. However, tasks marked with different statuses do not shade in the progress bar.

This same concept can easily carry over to user stories. If this is already a feature or something we can easily implement ourselves I’m very interested in finding out!