feat: Add JIRA sync configuration file

[SecondSkoll]

- [ ] Have you updated CHANGELOG.md with relevant non-documentation file changes?

• No changelog change required, not related to functional changes

- [ ] Have you updated the documentation for this change?

• No documentation should be required, JIRA sync bot is documented here: https://github.com/canonical/gh-jira-sync-bot

[medubelko]

Could you also add a brief description of intent for this to our working policies?

[medubelko]

Should this be included as a trigger? I thought question was for open-ended queries.

[SecondSkoll]

Anything that requires time or effort to address should be captured and have time allocated to be able to remedy it. Potentially this should be more of a "research needed" item rather than just a "question".

[medubelko]

Let's hash that out in the policies. I'm sure everyone will have ideas for label names and purposes.

[medubelko]

It might be worth making this Triaged. As it stands we'll need to triage twice: first for a label, and second for the Jira task.

Alternatively, we could add a triaged label as the trigger, to separate those concerns.

[SecondSkoll]

So we'll need to do multiple layers of triage anyway. The intent of this is to automate pulling these items into Jira so we have visibility over these items for roadmap planning and allocation. Items from this automation get pulled into a backlog epic and then we'll need to move them to an epic for a specific roadmap.

In my mind, something is only "triaged" when we know what's involved and roughly how long it should take, which allows us to assign it to someone for a specific sprint.

[medubelko]

I think I'm concerned with an overabundance of partially-specced Jira issues. Any of the maintainers can freely add labels when creating new issues, which will be instantly shadowed in Jira. If the issue is a non-starter or a duplicate, it's copied nonetheless.

I suppose that's not a problem if we're disciplined. It's a different philosophy than I'm used to. My perspective might make more sense if we had a dedicated SP project and a higher volume to deal with.