neithernut / issue-states Goto Github PK

I think a format for conditions should be specified. Of course, the library should also gain support for such a format (how exactly the interface will look like is another interesting question which I do not want to discuss here).

The original idea was to have the user declare a suitable format for conditions. The rationale behind it was that specifying a format may be too restrictive. However, specifying a format would clearly improve (potential) interoperability of tools and software making use of issue states. It would also avoid a situation where a user or admin would have to "learn" a new condition format for every new tool.

git-dit already has a format for conditions. It allows checking for:

• presence of a piece of metadata (just the name of the metadata)
• presence + exact match of value (<name>=<value>)
• presence + contains substring (<name>~<value>)
• negations of any of the above (!<condition>)

The supported datatypes so far are strings and lists of strings. A longish-term plan included adding more operators (e.g. < and > for numerical or partially ordered values).

One option would be to just take this format, add a bunch of operators, and include it in issue-states. But I'm not sure. Maybe the format could be improved.

@MichaelMure, given that git-bug is a potential user, do you have any ideas or preferences?

Hi @neithernut

This is quite interesting. Do you have an example of set of rules that could be used ?

It would be subjective and depend on the actual features that the tracker support but it would help to show the benefits of this solution.

One obvious benefits is that it would allow the end user to define their own rules and adapt the tracker to their workflow instead of the other way around.