Is there some kind of an app/widget which helps you track your work items? We have an issue when working on multiple projects, people keep forgetting to set work items as active and DevOps doesn't calculate hours spent on work correctly
Would be useful to see which of my work items are active or paused in one list
Yes, there is a method.
State paused for example.
First, set up a query and save it.
Second, go to the Dashboards of Overview.
After that, just share the Dashboards page to others and everybody of your team can easily know how many work items are in 'paused' state and everyone can easily click in to check what are the work items are in 'paused' state(Do not forget to click 'Done editing' at the end).
By this method, you can manage other states of workitems.
I saw people add many graphs, analytics, badges and many more things in their github profile. But how do they do this? See the attached picture and tell me about the process please.someone's github profile
you seem to be new here to Stackoverflow. Stackoverflow is a site where programmers help one another solve problems or issues that they are having with their code, environment, etc. Generally a question such as this would be closed, well at least from my experience. When asking a question you should probably ask something related to code or an issue (never ask how to do something with no existing code because people don't like that, coming from experience). Really only ask a question if there's an issue and a solution.
Back to your question, you can get all that stuff in that screenshot under stats here and you can add the tech stack stuff with any old github readme badge like this one. Just add what they tell you to your profiles markdown file, if you don't know how to do that look here.
I still didn't get it.
Where do complete backlog stays if we have to plan for new sprint and pick items from backlog. Like I can see stories/features but what about all bugs/issues, where they can be seen?
I don't want to search for all items in queries/work items. How can I bring all work items in backlog?
Sounds like you're using the Agile template, which doesn't put everything on the product backlog by default. You can edit the backlog settings to put the bug workitem on the backlog. You can find this setting in the Backlog customization screen, as long as Bug is configured to show up as a requirement, it should show up on the product backlog:
Since issues follow a completely different workflow, they cannot be placed on the product backlog. I would guess that they're being used as something else than what they were meant for. But you'd have to help me with additional information. The Issue work item type is the scrum equivalent of an Impediment. Anything that is blocking the team from progressing effectively. These aren't part of the work that goes into the product and are not managed on the same list.
If you're using the Issue work item as a different kind of Bug/Defect then I recommend either creating a custom field on bug to signal the bug type or create a new work item type that is a copy of bug to start with, that way it starts out with all the fields required for it to show up on the backlog.
I'm working on an app which includes the Jira API (and agile API).
I need a list of projects (this is no problem), I use :
https://example.com/rest/api/latest/project?projectKey=TA
and then I need to be able to click on a project and give me a list of sprints + issues for each sprint. Here I am stuck. I have found another related question (JQL: Get list of sprints), which gives me a list of sprints based on a projectkey, by using :
https://example.com/rest/greenhopper/1.0/integration/teamcalendars/sprint/list?jql=project+%3D+TA”
However, I don't know how to get the issues for said sprint.
I also know how to get the issues for a sprint directly from the agile API : https://example.com/rest/agile/latest/board/5/sprint/4/issue
but I can't seem to link the board to the projectkey.
I have found a similar topics on the atlassian site itself, but they usually mention there is no REST endpoint to do what I want. Although I'm sure it should be possible (?).
The answers I find elsewhere, I don't really understand (filter on rapidId's or something similar) so I really need a noob-explanation of what to do.
Having a similar issue, but I have found a way to get the board and sprint id(s) needed to get the sprint details. I'd like to improve this as it depends on string matching the board name (which you may not have) to the project.
You can get all the rapidview ids here:
https://example.com/rest/greenhopper/1.0/rapidview
Assuming you have a standard naming convention for boards this will work, buts its a big If.
https://example.com/rest/greenhopper/1.0/sprintquery/
will give you the sprints.
Interested to see if anyone else have found a better way to do this!
In Perforce (atleast the GUI) a check-in/commit comment is required. (I don't believe they are required in Git or Subversion.) Most developers that work with me just fill it in with latest/updated/etc. I used to write meaningful descriptions, but at about 20 comments a day with stuff like 'replace an image.' 'Changed spelling of 'franhcise' gets really annoying. Furthermore most changes can be quickly seen in a Diff.
At first I thought I was just being lazy, but I tend not to even look at them when reviewing other peoples code. I'd rather go right to the Diff. Am I alone? Are required comments a good idea?
You should always leave good comments. Not necessarily describing what you changed, unless it is a large changeset with too many distracting little details... but always, always, describe why you made the change (maybe link to a bug tracker item if there is one).
When i'm looking at your diff a year later, after realizing that it introduced a subtle bug, i need to know why the change was made - if i can't find a good reason, i'm just going to roll it back and curse your lazy ways... ;-)
Meaningful comments serve several purposes:
If you're looking for a particular change in a version history, they let you quickly scan through the file's history (eg: "Hey, I know we fixed a bug about the flicker of this widget sometime in March last year. Do you remember what was the fix for that?").
They encourage you to make atomized commits. If you end up making check-ins with generic comments, that probably means you're doing too many things at once.
As mentioned earlier, they let you know why things changes. Sure, a diff can tell you, for instance, how the tax computation changed for item such and such. But it won't tell you that it's because law XYZ for taxation changed.
They make it easier to write release notes, or equivalent documentation.
Perhaps a bit of a different perspective:
If you want to review ALL the changes for a year or since the last release - do you want to look at all the diffs, or would you like to see a good commit comment and a link to a defect/issue item?
If you're making 20 check-ins per day, you're probably checking in too frequently. Group all the minor typo fixes into a single checkin with a comment of "fixed various typos".
Writing a meaningful comment takes about 30 seconds, so just get over it and do it.
As has been discussed in the comments to Shog9's answer, enforcing the comment on the tool level does not necessarily help keep the lazy people in line, because the requirement is too easy to circumvent (as was already mentioned in the question: just type "latest"/"updated"/etc, or even "sfakjs;d", which is probably more harmful than an empty line).
However, the fact that the tool requires it may serve as a reminder for a normally diligent developer who is accidentally going to commit without any explanation. If it does this even once, then we are on the plus side (i.e., the requirement is beneficial), because normally the functionality does not make any difference – the good guys write the comments anyway, whereas the bad gals can always get around the requirement, no matter what technical barriers you set up. (Whether you want to keep them employed is another question, of course.)
Mostly because they are not meant to be used for making commits after changing a css attribute etc., but rather after making a more meaningful change/bugfix. But comments are very useful anyways.