The main challenge is dealing with dynamic data in a way that won’t mess up merge conflicts. Sort order is the main one and it’s pretty bad because a merge conflict will result in multiple tickets with the same sort order. The best way I could think of in the slightly less strict paradigm of the plainban project was to keep a data.yml file for each column which records the sort order of tickets by storing them as a list of uuids and making their name a comment. That way it’s very easy to keep track of the order of tickets on merge conflict in a way that’s not possible in a central data source like a csv file.
sort_order:
- abcd # my cool ticket
- 1234 # another cool ticket
- ab12 # final ticket
Will change current, less merge-friendly implementation to this when I get to it.
Yep - I do it in the scripted version.
The main challenge is dealing with dynamic data in a way that won’t mess up merge conflicts. Sort order is the main one and it’s pretty bad because a merge conflict will result in multiple tickets with the same sort order. The best way I could think of in the slightly less strict paradigm of the plainban project was to keep a
data.ymlfile for each column which records the sort order of tickets by storing them as a list of uuids and making their name a comment. That way it’s very easy to keep track of the order of tickets on merge conflict in a way that’s not possible in a central data source like a csv file.Will change current, less merge-friendly implementation to this when I get to it.