Jira: Different branch prefixes by task type?

[jwvanderbeck]

I know this is kind of against the "best practice" as seen in the blogs, but I find it a bit odd that I don't have the option to do this.  Knowing if a task is a bug fix, versus new feature, versus changes to existing features, is information I find very useful when it comes to integration ahead of a build as well as building release notes.  I've been looking into the more advanced features of Plastic such as attributes and conditional formatting to try and better visualize my branch information but I'm still struggling with the best way to have this information readily available at a glance.

I essentially have two different pieces of information that I want to visualize for a BRANCH and no easy way that I can see to do it with the tools available.  For a given branch I want to know 1) What is its status? In progress, Review and Merge, or Done and 2) What type of task was this work? Bug fix, new feature, or changed feature.

The problem is coloring the branch only lets me visualize one piece of information.  Anything else I have to click on the branch and open its attributes.  While this isn't the end of the world, it does mean I can't just look at the big picture and get an overview.

However, if I could change the branch prefix to be representative of the task type, that would give me two pieces of information in an overview.

Now, all that said, if there is a better way to manage this please let me know.  I'm open to suggestions.

[calbzam]

Hi,

There is a feature that not sure if you are aware:

https://www.plasticscm.com/documentation/extensions/plastic-scm-version-control-task-and-issue-tracking-guide#Fieldmapping

Quote

The JIRA extension allows to map the fields from the JIRA issue that will be displayed on the task information panel in the Branches or Changesets views in Plastic SCM.

If I properly understand, supporting multiple branch prefix values would be also useful for you? eg:

task_, fix_, new_

Regards,

Carlos.

[jwvanderbeck]

4 hours ago, calbzam said:

Hi,

There is a feature that not sure if you are aware:

https://www.plasticscm.com/documentation/extensions/plastic-scm-version-control-task-and-issue-tracking-guide#Fieldmapping

If I properly understand, supporting multiple branch prefix values would be also useful for you? eg:

task_, fix_, new_

Regards,

Carlos.

Yeah the problem I have with attributes, or the Jira properties panel, is the same.  You have to click on the branch or changeset to see that information.

Where as things like Labels, Colors, and Branch Names you can see ALL of them at once, at a glance, without having to click on any of them.

 

[calbzam]

We appreciate if you include your request in the following link:

https://plasticscm.uservoice.com

Regards,

Carlos.

 

[jwvanderbeck]

17 hours ago, calbzam said:

We appreciate if you include your request in the following link:

https://plasticscm.uservoice.com

Regards,

Carlos.

 

I was just thinking also if we could display branch attributes in the branch explorer window underneath the breanch directly in the view, that would actually solve the problem as well and be even better and more flexible.

 

Posted that to the user voice.

[David Yang]

@jwvanderbeck I do something similar with assigning branches a category and there's 2 ways I've found to have that show up in Branch Explorer without using colours:

• In the right hand pane where you can select Display Options, there's an option to 'Display branch task info' which displays the branch description (comment field) after the branch name. Eg, you could have a branch named 'task0001' with its description/comment as '[feature] implement cool new feature' and both will show up in Branch Explorer.

• Alternative option if you can't use the above, is to use a long branch name. Eg, you can name the branch something like the following. This works fine if you just use GUI/scripts, but not a great idea if you use 'cm' console command to do stuff with branches...

  task 0001 | [feature] implement cool new feature

[jwvanderbeck]

7 hours ago, David Yang said:

@jwvanderbeck I do something similar with assigning branches a category and there's 2 ways I've found to have that show up in Branch Explorer without using colours:

• In the right hand pane where you can select Display Options, there's an option to 'Display branch task info' which displays the branch description (comment field) after the branch name. Eg, you could have a branch named 'task0001' with its description/comment as '[feature] implement cool new feature' and both will show up in Branch Explorer.

• Alternative option if you can't use the above, is to use a long branch name. Eg, you can name the branch something like the following. This works fine if you just use GUI/scripts, but not a great idea if you use 'cm' console command to do stuff with branches...

  
  task 0001 | [feature] implement cool new feature

On Mac enabling show task info doesn't display anything from Jira (but it also doesn't show any of the Jira data which is something I forgot to mention and why I want another way).  On Windows it displays the Jira Task title but that is often long so doesn't fit very well in the display as most branches are shorter than the "info" lol.

As for your second option, I admit I'm not sure what you mean but "branch name" in this context.  Changing the branch name is exactly what we want to do, but the Jira plugin doesn't let you change the name of the branch.  It is always the fixed prefix plus the issue number.

[David Yang]

Ah, sorry I missed the part about the Jira plugin (I'm not familiar with the plugin, sorry - I played around with the plugins when I first started but soon found it easier just to manually name the branch and copy the description, etc).

I think Option 1 could still work for Windows, but you'd need to make sure Jira task titles contain the relevant prefix going forward.

 

10 hours ago, jwvanderbeck said:

On Windows it displays the Jira Task title but that is often long so doesn't fit very well in the display as most branches are shorter than the "info" lol.

Are you working solo or with a very small team? I've had this same issue before, but that was on a solo project where each task was fairly short and I didn't have concurrent checkins from other people to "lengthen" my task branches.

This is the approach I came up, which might work for you as well if you only have a few people working concurrently:

1. When creating a new task branch, immediately create a new checkin adding a plain text file called 'task-info.txt' or something. This file can contain all the info that you would put in the bug tracker. You can also do a checklist style approach, eg:

   <Title>
   <Description>
   
   Requirements:
   - [ ] requirements or sub-tasks needed to complete the task
   - [ ] ...
   
   Review:
   - [ ] things to self-check/test at the end before merging or submitting for peer review
   - [ ] …

2. When a requirement or sub-task is completed, mark it as complete in 'task-info.txt' and checkin together with the relevant code changes. Eg, while working on a task, if I've finished requirements 1 and 3, I would also update 'task-info.txt' and check that in as well:

   Requirements:
   - [x] requirement 1
   - [ ] requirement 2
   - [x] requirement 3
   - [ ] requirement 4
   - [ ] requirement 5

3. After completing the task, go through each self-check items and mark as complete in 'task-info.txt' as you go. When all self-checks are complete, checkin the completed 'task-info.txt' as the final checkin before merging or submitting for peer review.
    
4. Finally, when ready to merge back into main, delete 'task-info.txt' (after processing the merge but before checking in the merge). Pending Changes view won't let you delete the file, but you can delete it normally from File Explorer and it will let you checkin on the second attempt. This way, the task info is preserved on the task branch, but doesn't pollute main branch.

 

What I liked about this approach:

• Keeps everything together in one place and saves on setting up  / maintaining a separate bug tracker (if you have a very small team and don't need a lot of coordination).
   
• Easy to check that you've done everything you need to, and helps prevent some basic errors that I found I kept repeating (if I found I kept making similar mistakes, I'd add it to self-check list going forward).
   
• Easy to update a task with additional requirements, etc 'mid-task'. Simply update 'task-info.txt' and checkin. It's impossible then to forget about these requirement changes as you'll see them before making the final checkin. With the new ability to colour code changeset/labels by attribute/etc, it's also easy to distinguish actual changesets from task info changes
   
• Branches are at minimum 3 changesets long (two for the initial and completed 'task-info.txt', and at least one with the actual content), which I found long enough for most task descriptions to show up.

[jwvanderbeck]

Yes I am working solo at the moment. To some it may seem silly to use tools like Jira and Plastic when all alone but I appreciate the structure it gives me, plus it lets me expand easier later in a project if necessary.

Thanks for the detailed post, clearly you put some thought into it and I shall take some time to digest it

[David Yang]

3 hours ago, jwvanderbeck said:

Yes I am working solo at the moment. To some it may seem silly to use tools like Jira and Plastic when all alone but I appreciate the structure it gives me, plus it lets me expand easier later in a project if necessary.

Haha yep, pretty much same as me so I totally get where you're coming from .

At the start, I spent a lot of time trying different issue trackers too, including Jira, YouTrack, HacknPlan, Azure DevOps, etc. But the self-hosted versions all had pretty high system requirements (no chance of running on a free/cheap AWS server so that I could access from home and office), and with the cloud-hosted versions I didn't like the idea of locking myself and my data into another product subscription.

(I was happy to pay for Plastic SCM because I liked it so much more than Git and its diff tools are quite helpful even for checking own work, but I was less keen to pay the same or more for essentially a glorified todo list!)

So that's how I ended up with the approach I describe above. It also keeps everything in one place so I don't have to worry about having my data stuck behind different product subscriptions. Definitely good enough for solo dev, but should also be workable for small teams as well.

In case you or others are interested, @psantosl and I actually had quite a long discussion about Plastic, issue trackers and keeping track of the bigger picture (see forum thread below). In the second last post, Pablo makes a good points about why he prefers simply mapping out big features in a cheap list "in a text file, an excel, whatever". It's actually what got me to ditch using an external issue tracker - if I'm going to use a text file / spreadsheet anyway, why not just keep it inside the repo and track task progress there!

 

 

Anyway, hope some of that helps. And if you come up with something different that you think works well, I'd be interested to hear about it too!