What is the "Follow-up" button in the Gerrit Review is doing? And when should it be used?
I am using Gerrit 2.13.8.
I saw this feature mentioned here and also played around with it a bit as I was curious myself.
...allows us to create a Follow-Up change. The Follow-Up changes are
changes that are based on existing changes. This gives you an
opportunity to create a chain of related changes.
The "follow-up" feature allows you to create change-sets very quickly.
The parent commit of these change-sets will be the change-set that they were created from (the change-set where the "follow-up" button was used).
This feature could be useful for when you are wrapping up a change but a few additional bugs or tweaks were found that you don't want to include in the current change-set.
You can create change-sets for those follow-up items rather than having to create the change-sets manually.
The text that is typed into the popup box after you click the follow-up button becomes the commit message for the new change-set.
Related
I am running Azure DevOps 2019 RC1 with an Inheritance Collection and a new Agile project.
I have a requirement that when a user creates a work item (task/issue), they must automatically be added as a follower of this work item. How can I achieve this? I have look in the rules for the work item under process customisation but it doesn't appear to be possible this way.
We are using the tickets to track issues. Whoever discovers the issue raises the ticket. The basic requirement is that anyone who raises a ticket should be automatically notified of its progress, even though they are not responsible for the development or testing.
Currently the work around is telling the user that when they create an issue they must click the Follow button, but it is easy for them to forget and then lose their updates. It seems like a very simple customisation so maybe I'm missing the obvious.
Thanks
I think you can't auto follow things currently, but you can add notification setting that will send automatically emails when work item is updated. To do this, go to Project Settings > Notifications page and create new subscription. Select "Work/A work item is changed" and put "Members of ... team by role" in Deliver to selection. Set roles to "Created by" and untick the "Skip initiator".
Your problem would be addressed precisely with the feature requested in the official Azure DevOps' feedback platform here:
479189 - Automatically follow work items I interact with
(That page also mentions workarounds, including per-team one answered here, and a per-person alternative. See this comment. The shortcoming of both is that they don't allow to you to unsubscribe for selected tickets.)
We are migrating from an in-house tool to Jira for managing our scrum board, and we have concerns that I have been unable to resolve by searching the Internet. But you folks are smart, right? ;-)
Our current scrum board shows the usual swim lanes across state columns (for todo, progress, review, done). Each swim lane represents a user story, and has a link to (and a snippet of) the user story description in Jira. It also has a number of 'tickets' (these would be subtasks in Jira lingo) that start in 'todo' and move across to eventually end up in 'done'.
So far, Jira can do all of this, too (although creating sub-tasks is rather a lot more work in Jira than in our in-house tool). However:
When we commit code, we include a ticket ID in the commit message, and thus each ticket displays a list of commits that were done to complete that particular ticket / partial story. I haven't been able to find out how to do this in Jira -- if it's possible at all. Instead, it seems one must open a sub-task to see if there are any commits on it?
Each commit also shows its review state, which gives us an excellent overview of how close to done a ticket really is. I haven't been able to find out how to do this in Jira -- if it's possible at all. Instead, it seems one must open the sub-task, and drill down further into Fisheye(?) in order to see the review state?
In total, our tool provides a one-screen overview of the state of each user story, ticket, commit, and review state; and it's very lightweight to pull in new stories (from Jira) and add tickets. We fear that Jira is not able to provide such a one-screen overview, forcing us to open Fisheye in order to know whether a given commit has passed review.
Is it really true that Jira must be this cumbersome?
For reference, here is what a single ticket (subtask) looks like in our system:
And if you look at the whole scrum board, it's actually quite easy to get a feel for the number of commits on individual user stories and tickets, and the ratio of pending/passed/failed code reviews:
I agree with your fears when you say
We fear that Jira is not able to provide such a one-screen overview
In my experience (7+ years with Jira/Agile) I've not seen a such condensed view of information about a sigle user story even on a swimlane with relative cards.
Also in the Atlassian marketplace there seems to be no good plugin to solve your issue, even partially.
To make such move from your in-house tool to Jira retaining all you have there, I fear you should develop a custom Plug-in using Jira SDK to integrate with the agile boards.
It may be enough to start by developing a custom field to show what you need from a "ticket" (ie sub-issue) and trying to insert it into one of the three "slots" available for cards (I mean Rapidboard card layout configuration screen).
If you wanna try, start from here.
Another option to create a new custom field would be the Adaptavist Scriptrunner plugin. It will ease the building of custom fields: your new field can be written also in Groovy rather than plain Java. I've used it to build an extended status custom field (just to give the user an immediate big picture of it) that informs him in plain english and with stylish css colors why an issue is blocked or anything else relevant, getting data from other fields or linked issues that are not immediately visible to the user. IMHO, it is very similar to your problem.
I wrote a plugin that saves and updates a certain numeric field which is part of the layout of a workitem in the TFS.
The problem is, a lot of updates \ changes are done in the backend on this field, and when someone reviews the history tab of the workitem, they can see a lot of these changes documented, when they have no real added value being documented, and simply clutter the history view.
is there a way to configure the TFS \ save a workitem in the backend and have that change excluded from the history logging?
That is currently not possible, nor have we any plans to avoid adding it to the history. Any change to a work item creates a new revision, and we want to keep that for auditing purposes. However we are working to improve the history control and one of the future improvements will be to visually filter out changes made by the system.
This is great info as we are designing the next version of the history control on the work item form.
I'm looking to reproduce the Jira watch functionality in TFS 2013. In Jira, you can click a link to watch an item and thereafter you will be notified when anything on that item changes.
I know on TFS you can:
be emailed if anyone changes a bug you are assigned to
manually email a bug to anyone at any time
Create a custom report and pin it to your home page to notify yourself of things (like this maybe?)
I can imagine creating a new field that will accept multiple users and creating a custom email notification to notify everyone in that list if the work item changes. But that seem like a whole lot of work and I'm not sure were to start if that is the way do do this.
What's the easiest way to get functionality like watching a work item? If it's easy and similar to the Jira functionality that is better for me than exactly the same and hard to do.
Sure, you can setup email alerts based on many different criteria, including what you asked for.
You need to go to the Alerts section, and create a new custom alert, and you can put in the ID of whatever work item you want to "watch". By default it includes the clause AuthorizedAs <> [Me] which will make sure it doesn't email you for changes that you make, but you can remove that clause if you'd like.
We are trying to impose couple of rules on our project , can you tell us if it is possible to do? and if yes where should I start on this?
One of the example rule is
Deliverable can’t be closed with non-closed children.
This means that even in resolved state a child item would block closing the deliverable.
This should apply to parent child link types only
This would only apply to deliverable parent and any type of valid child
There are two ways you can do this.
Server-side:
You can add a plugin to tfs, that changes workitems. A good example would be TFSAggregator. It won't have the solution for your specific problem, but I can show you how to change work items on the server side. Shouldn't be a big problem to add your case.
The problem with this solution is, that it only changes a workitem after it has been saved. So user will still be able to close the child, but the server will re-open it.
Client-side:
The second solution would be a custom control, which can be implemented in the WITD of your work item. It can be just an invisible control, that adds some validation. You can find some examples here.
The downside of this solution? You have to install the custom control on every single client that uses Visual Studio and you may have to develop a specific version for web-access.