feat: Add JIRA sync configuration file #489
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,28 @@ | ||
| settings: | ||
| jira_project_key: "DOCPR" | ||
| epic_key: "DOCPR-2376" | ||
| components: | ||
| - Starter Pack | ||
| labels: | ||
| - "bug" | ||
| - "documentation" | ||
| - "enhancement" | ||
| - "improvement" | ||
| - "question" | ||
|
Contributor
There was a problem hiding this comment. Should this be included as a trigger? I thought
Collaborator
Author
There was a problem hiding this comment. 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".
Contributor
There was a problem hiding this comment. Let's hash that out in the policies. I'm sure everyone will have ideas for label names and purposes. |
||
| status_mapping: | ||
| opened: Untriaged | ||
|
Contributor
There was a problem hiding this comment. It might be worth making this Alternatively, we could add a
Collaborator
Author
There was a problem hiding this comment. 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.
Contributor
There was a problem hiding this comment. 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. |
||
| closed: done | ||
| not_planned: rejected | ||
| # Adds a comment with the JIRA ID | ||
| add_gh_comment: true | ||
| # Reflect changes on JIRA | ||
| sync_description: true | ||
| # Comments are synced from Github to JIRA | ||
| # Nothing goes from JIRA to Github | ||
| sync_comments: true | ||
| label_mapping: | ||
| "bug": Bug | ||
| "documentation": Task | ||
| "enhancement": Task | ||
| "improvement": Task | ||
| "question": Spike | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you also add a brief description of intent for this to our working policies?