Yes, Adam James
That aligns with several "best practice" methods. But the root cause
culprit is the label name . . . "Fix Versions" which may (but shouldn't)
be interpreted to mean; "Which version needs the fix?"
*1. Suggestions to cure: *
- *(should be easy) Field Description:*
- Modify the "Fix Version" field description within Jira. Make it
explicit and unambiguous.
- Example: "Issue Resolved Version"
- *(also easy, if your can find it) Help Text/Tooltips:*
- Use Jira's built-in help text or tooltips to provide more detailed
instructions when a user hovers over the "Issue Resolved Version" field;
- such as: This field is completed AFTER the fix is available to
users and shows release / version has the fix in it."
- *(more complicated and often has unintended consequences) Enty Rules:*
- If allowed with subscription, create rule(s) preventing editing
until the issue reaches X stage.
On Fri, Mar 14, 2025 at 11:41 AM Ádám Sághy <adamsa...@gmail.com> wrote:
> Hi
>
> I just wanted to have a mail about something similar…as at the moment I am
> removing the “fix version” from stories that are 2-3 years old and no
> activity on them!
>
> I think your definition is the correct one!
>
> I like the idea to not assign any fix version when story is created, it
> should be assigned only when story is done (PR got merged)!
>
> Regards,
> Adam
>
> > On 2025. Mar 14., at 16:33, James Dailey <jamespdai...@gmail.com> wrote:
> >
> > I wonder if we are on the same page?
> >
> > My definition for the field in Jira tickets called "Fix version/s:" is
> that it represents either:
> > - 1) the planned release version (where it fits on the roadmap)
> > or - 2) the actual release in which the ticket was resolved.
> >
> > (it does not represent the version that you are Fixing, but the version
> in which something is fixed)
> >
> > While we should aim for (1) we are actually only doing (2) for now.
> >
> > Thus, the way for us to manage this would be,
> > * when creating a ticket, do not assign a planned release "fix version",
> leave it as "none". You don't know. We don't know if/when someone will
> work on it.
> > * when working on the ticket resolution, check the current release and
> increment by one. Thus, if the current release is 1.11.0, then assume that
> your fix will go into 1.12.0 (check the listserv to see if there is any
> planned release coming up)
> >
> > A couple of implications:
> > - When doing the release of a patch, we can then filter on 1.12 and
> status = done and include the changeset.
> > - When doing a full release, we can then pull those that are !done (not
> done) and 1.12.0 in this field and then interrogate whether they are fully
> done or need to be moved to the next release or to "none".
> >
> > Are we in agreement ?
>
>
--
--
Paul
