Philosophy behind SIL

[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 workflow actions (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 validators.

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, function over function, support for many more custom fields.