Can you provide a few examples of problematic Jiras and/or commit messages? Recently I started putting most (if not all) of the details for the change in the commit message itself rather than in the Jira. These details are added to the Jira implicitly as comments when the code is merged. However, if the details are in the Jira only then when one is browsing the code it is often required to open the related Jira to get the details for the change.
Justin On Thu, Mar 24, 2022 at 3:34 PM Christopher Shannon < christopher.l.shan...@gmail.com> wrote: > As I brought up in the Artemis 2.21.0 vote thread I have noticed a pattern > of Jiras that have almost no information in them which makes it very > difficult to follow along with bug fixes and new features. This made > reviewing the current release more difficult. Some issues are trivial but > most issues should have a good description to document the change. > > I am proposing that going forward we come up with a template/guide or > checklist of some sort for Jiras for people to follow, kind of like coding > standards or a checklist for reviewing pull requests. > > It doesn't have to be super strict, but some guidelines might be nice. Off > the top of my head here are a few things: > > New Features: > 1) What's the motivation of the feature? Why is it needed? > 2) A high level description on the plan to implement the feature > 2) Maybe some details on how testing will be done > > Bug Fixes: > 1) How was the issue discovered? > 2) How to reproduce and what versions are affected? > 3) whats the proposed fix? > > My main motivation here is Jiras but we could also have guidelines for > commit messages if we want too. > > Thoughts? >
