We are in the progress of making some improvements to how you can contribute to our products. In this post I’ll walk you through the different ways in which you can contribute and show you some of these changes.
And before you ask: Yes, one of the things we’ve fixed is the CLA server.
Improve our Documentation
Software is more than code. You can help improve the API Reference and Guides via the Edit button found on the top right of each documentation page:
You will need to sign the CLA before we can accept your contribution. This basically allows us to use and improve on your contributions.
If you want to make extensive changes, we recommend to fork the respective repository and Generate and Validate the API Reference before you send a Pull Request (PR). We might also ask you to create a JIRA ticket first to explain the changes.
For the guides the button will take you to the corresponding page on the Wiki we use to generate the guides from. If you don’t have a Wiki account with us yet, it will let you sign up for one first.
Report Bugs and Request Features
We can’t fix or improve what we don’t know about. So even if you’re not able to contribute a fix or feature yourself, you can still contribute by creating a JIRA ticket.
The new AC inbox
This week we closed the Titanium Community (TC) project and moved all tickets to Appcelerator – INBOX (AC). This project now serves as our single Inbox for all products. Once we’ve validated the ticket we will move it to the right project. For most projects you will be able to continue to monitor the progress.
We try to move tickets out of AC as soon as we can. For this to happen, we might need to ask you for additional information. Please observe the How to Submit a Bug Report guide, select the right Component for your ticket to increase the chance of it getting processed quickly.
We’re glad to report that we managed to catch up quite well recently:
There are many factors involved in determining the priority of a ticket. Regressions and critical bugs get top priority of course as well as tickets of customers with certain SLA’s. But one of the key factors is the number of watchers a ticket has. So watch tickets that are important to you and rally other developers to watch yours as well.
Did you know that Appcelerator Engineers follow the same requirements that we ask from you? All commits to our code are done via GitHub Pull Requests that need to meet a set of criteria before being merged:
- Each new feature or fix needs a JIRA ticket to document it.
- Where possible (where isn’t it?) the PR should include a test.
- The author needs to have signed the CLA.
- All GitHub PR checks must pass (CLA & Travis CI)
For more detailed information see Contributing to Titanium.
One of the automatic checks GitHub does for us is whether you have signed the CLA. We’ve had some issues with the CLA server, but just this week we’ve replaced the Node.ACS with a brand new Arrow app and all should be good now.
To help you create a clear Pull Request, we started adopting GitHub’s new Pull Request templates. The first repository where we’ve added this to is titanium_mobile. When you create a new PR it will remind you to include a link to a JIRA ticket and prefix the (clear) title with the ticket number between square brackets. This helps us to process your PR faster.
Another improvement we’re experimenting with in titanium_mobile is labels. We add labels to all community PR’s to indicate the type of change but most importantly what is blocking the issue from being processed, e.g. if it needs docs or a JIRA ticket.
We hope this will help to clarify why a PR can sometimes hang around for a while, without needing to read through all of it’s comments.
Once they’ve proved succesfull, we hope to introduce PR Templates and Labels to other repositories as well. We’ll also update and consolidate our Guides on Contributing. Finally, we’re working on making it easier to generate unit tests for Titanium, Alloy and other products.
Code strong! ?