gherkin language for acceptance criteria

Good idea, but why not just write that into the criteria yourself?

Well, that's what I eventually did. But the reasons would be:

1) you already have the three-part formula for user stories (as a... I want to... so that...), so, for simmetry's sake, a matching three-part formula for the respective acceptance tests (given... when... then...) would be a logical thing, IMO; You would even take advantage of the already implemented three-part-template from user stories.

2) having template text labels help to enforce a consistent style, and, again IMO, increase tremendously the speed of writing, since you don't even need to think about structure while writing, only content (and content/structure separation is always a Good Thing©)

So, as things are today,:

1) If I write one complete acceptance test per item, I loose the visual separation of the three conceptually separated parts, and end up manually mixing structure and content. It makes everything much harder to write and much harder to read than it needs to be (specially after you've already given so much attention to subtle productivity details that make a huge difference, such as automatically going to the next field with enter, automatically entering edit mode upon click, etc.)

2) If I write one third of the test per item (as I actually did**), I spend three items to represent one conceptual unit (although composed by three parts), and if you have, say, three acceptance tests, you end up using nine items, and that makes things WAY harder to read than they need to be. It violates the "don't make me think" principle.

Of course, as the acceptance criteria of the sample project suggest, you don't need to use the Given When Then template, but it is so well recognized already as a good template, that I think it should at least be offered as an option, if not enforced right away.

** that's what I'm doing (mind the capitalization workaround):

a) GIVEN the user has written his feature request

b) WHEN the user clicks "Submit"

c) THEN the feature request is sent AND a success message is displayed

Ok, thanks for the explanation. We'll certainly consider that requirement in our backlog.