Philosophy behind SIL™

Looking for the documentation on the newest versions of SIL Engine and the Simple Issue Language for Jira 8 for Server/Data Center? Click here !

[Back in 2010 ...]

It all started when a customer requested us to do the same validator in 3 different ways. Then, the company (a bank) thought that it would be nice to add a very complicated logic behind, logic that should be changed anyway on the real Jira production system. In the meantime, another customer came and asked us to do the same, but in a slightly different way.

Because those functionalities were needed 'yesterday', we implemented it like it was requested, then we took a deep breath. Here's what we wrote in an 'Business Requirements' document at that time:

The problem with current functionalities is that we developed too many post functions doing basically the same thing but linked to a certain field (for instance assignee, or reporter). The same observation is true for conditions and post functions.
This is wrong, since the function is basically the same: we set a field value to a constant (including here the null value) , to another field's value or to a calculated value. The result is not flexible, certainly not configurable, and minimizes our chances when configuring a Jira installation.

The above is always true with any app that offers functions related to a certain field. But this is not the only problem that we had.

Of course, one could ask "But why didn't just use the ScriptRunner app?" (or any other). To tell you sincerely, we tried. But customers do not like groovy and to deal with all those Jira internals (yeah, some people really hate the idea that tab defines the block!). Plus, when upgrading Jira, they needed to upgrade all the scripts and re-test them. We heard our customers moaning.

Actually, we just needed something else: for us it made no sense to write import statements, or take care of the objects when all you needed to do is to set the assignee of an issue on a certain user. It was clear that we needed a new language. And because every language needs to bear a name, we called it SIL™ (Simple Issue Language™) and the containing app Power Scripts™ for Jira. Lack of inspiration, you may say.

Not quite.

From the very beginning, SIL™ was developed independently of Jira, despite of the name (as a side-note, our installers actually run for every app that needs to be installed - guess what? - a SIL script). On top of the language that can be used as a standard language script, like bean shell, groovy, jyton, etc, we have developed variable resolvers that are able to extract Jira issue fields and deal with them accordingly.

It's true, syntax was very crude, the editors were not very pleasant to use. But it worked so well.

[... in the meantime ...]

Armed with this tool we had some huge Jira customization projects. There are Jira instances out-there that one would need for sure to take a second look to convince herself / himself that it is a Jira for REAL !

And we just got better and better, simplifying the syntax, adding functionality over functionality, routine over routine, support for many more custom fields.

[... and the present]

We established ourselves as a provider for very complex Jira solutions. SIL™ has just made its way in 6 of our public apps:

And still we're getting better.