I'm currently using GitLab Enterprise in a team project. I now want to build out a board-based roadmap similar to Pivotal Tracker, Aha or Trello. (For this view, each month would be a "list" or Aha "milestone". We could then drag roadmap items from one month to another and the whole team can see where we are and our Issue priorities visually.)
I'm hoping we can only use GitLab for this and not need to integrate yet another tool.
In the "Boards" section of GitLab, I see I can make lists from GitLab Labels. This is OK, but I'd really like to make lists from GitLab Milestones. (Otherwise, I'd need to make another Milestone just to capture everything in the label.)
Am I missing something? Or is that really the best way to approach this with GitLab?
There is a roadmap feature for GitLab (premium/ultimate only)
It has evolved with GitLab 14.8 (February 2022)
Additional display options for roadmaps
In this release, we have introduced additional progress tracking capabilities to roadmaps. You can now view the percentage of completed epics based on issue count instead of issue weight. This functionality is useful for organizations that are using Kanban or other methodologies that don’t require their teams to set a weight on issues.
You can now also customize the level of milestones to include in your roadmap, allowing you to tailor your view to meet the needs of your audience.
See Documentation and Issue.
Milestones weren't designed with this use case in mind. Generally, once an issue is assigned to a Milestone, it doesn't change.
A common use case for milestones is to track Sprints or Iterations as milestones. The milestone's start and due dates would be the sprint start/end date respectively. During planning. issues would be tied to the appropriate milestone based on the sprint. If the work isn't finished by the due date (within the sprint period) the milestone stays the same.
Another use case is to use a milestone to track a scheduled release. In this case the start date can be empty, and the due date would be the release date. With this, if the release is missed the milestone still stays the same (ie, the issues are still attached the same) but it's completed after the due date.
Milestones do give some useful views about the attached issues, but not a board to move issues between them. Like you mentioned the only way to do that is with Labels, but they should work fine. You can customize the Labels you want to show up on a Board, and they order they're in. The only annoying (to me) thing about boards is that you can't get rid of the Open/Close lists, you can only collapse them. Looking at this issue (https://gitlab.com/gitlab-org/gitlab-foss/-/issues/37747) I doubt it will ever happen.
If you use gitlab.com, https://gitboard.co/ has the milestone or epic board which could help your case. The auto sprint could create and close the regular scheduled milestone/sprint or whatever you call it.
Related
I have an issue on gitlab, #1. This issue when it was created it contained two tasks.
Is there a way to mention/reference/close one of the two tasks in a git commit ?
Not yet, but at least you can define tasks in an issue now.
This comes with GitLab 15.3 (Aug. 2022)
Create tasks in issues
Tasks provide a robust way to refine an issue into smaller, discrete work units.
Previously in GitLab, you could break down an issue into smaller parts using markdown checklists within the description.
However, these checklist items could not be easily assigned, labeled, or managed anywhere outside of the description field.
You can now create tasks within issues from the Child Items widget.
Then, you can open the task directly within the issue to quickly update the title, set the weight, or add a description.
Tasks break down work within projects for GitLab Free and increase the planning hierarchy for our GitLab Premium customers to three levels (epic, issue, and task).
In our next iteration, you will be able to add labels, milestones, and iterations to each task.
Tasks represent our first step toward evolving issues, epics, incidents, requirements, and test cases to work items.
If you have feedback or suggestions about tasks, please comment on this issue.
See Documentation and Epic.
We are currently in the process of upgrading from TFS 2008 to TFS 2012. When TFS 2008 was set up, the people involved didn't understand a lot of what the work item fields were for, and we ended up with very heavily customised templates and in fact lost a lot of default fields. As part of the upgrade to 2012 we are trying to return to the out of the box templates as much as possible to ensure we get to use as many of the features as possible, however there are a small number of custom fields that we need to include for reporting purposes.
Our product development process involves a roadmap for upcoming releases which includes new work as well as bug fixes. When a bug is assigned to be worked on by the developers we would like to be able to choose which release we're targeting the fix for - as far as I can see, Iteration is best suited for this. At the point the bug is closed though, we would also like to track what release it was actually fixed in, since things often get bumped from one release to the next if higher priority bugs or change requests come in, but this is where we come unstuck since I can't seem to assign Iteration to both fields such that the two show different values.
If possible we would prefer not to have global lists that have to be constantly updated with release numbers across our product range (we have around 8 different products which are constantly in development, each with their own release numbers), and leaving one of them as a text field leaves open the possibility that we will get inconsistencies in what people enter, eg 1.01 versus 1.1 which will show up in reporting as 2 different releases. As the fields are just looking up a set of values in the background, is there no way that the iteration list can be used twice? Or does someone have an alternative suggestion as to how we get round this?
What I think I'd suggest in this case is using a COPY rule on a state change event, so that when you move your work item into the Closed state, it would populate your custom field with the value currently in your Iteration field.
This would give you a snapshot of the value at the right point in time which then wouldn't be altered if the iteration was later changed, along with a history entry if it was opened & closed multiple times over its lifetime.
As iteration is time limited and release is perpetual there is an inherent mismatch of purpose with using iteration here. Iteration is for planning.
You would be better creating a release list with the version that you release.
If you are sprinting for example you may not know up front which release you will end up on before you start. If you are not sprinting then you are just kidding yourself that your know.
I've been a JIRA and Bugzilla admin in past jobs, and have quite often had users ask for the ability to have more than one assignee per issue.
I know this is possible in JIRA, but to my mind it never makes sense; an issue should represent a piece of work, and only one person can do a piece of work (at least in software, I've never used an issue tracker for a 2-man bobsled team ;-)) A large piece of work will obviously involve more than one person, but I think in that case it should be split into subtasks to allow for accurate status reporting.
Does anyone have any use cases where it's valid to have multiple assignees ?
The Assignee field means many things to many people. A better name might be "Responsible User". There are three cases I discuss with my clients:
A. number of assignees = 0
JIRA has an Allow Unassigned issues option but I discourage use of that because if a work item isn't owned by anyone it tends to be ignored by everyone.
B. number of assignees = 1
The default case
C. number of assignees > 1
Who is responsible for the work item represented by the issue? The best case I've seen for this is that when an issue can be handled by any one person in a team, so before triage the issue is assigned to everyone in that team. I think a better approach is to create a JIRA user with an email address that sends to the whole team, and assign it to that user. Then a member of the team can have the issue assigned to them in particular.
Changing the one assignee case has the history recorded in the History tab. Nothing is lost in that case.
I'll often have a story / feature that can be split across multiple developers. They will have individually assigned subtasks but it would make sense to assign the parent to all involved, unless there's a lead developer. I wasn't actually aware that I could do multiple assignments, so thanks for the tip!
The other case I can think of is pair programming.
I hit upon this question while looking for solutions to doing this. Since I want to do this, I'm guessing my use case counts as an answer to your question: I only really want one assignee in the sense of someone currently working on a problem, but I want to track the whole lifecycle of an issue. For us, that can mean:
A support person receives a report from a customer, creates an issue
An issue-wrangler reviews the issue to make sure it's valid, not duplicated, has all appropriate details, etc.
A developer implements/fixes the issue
A tester performs whatever tests are appropriate (in our case, mostly extending our automated testsuite to additionally test the feature/fix)
An operations person rolls out the new version to a test environment
A support person informs the customer, who does his own tests with the new version in the test environment
An operations person rolls out the new version to production
Not all issues necessarily go through all steps. Some issues have more steps (e.g. a code review between step 3 and 4). Many issues will also move backwards among the steps (developer needs more information, we go from step 3 to 1 or 2; tester spots a problem, we go from 4 to 3).
At each stage, only one person is actually responsible for whatever's got to be done. Nevertheless, there are a whole bunch of people who are associated with the issue. Tracking systems we've used are happy to offer easy changes to previous owners of the issue (shown as a list), but I'd ideally like to go a step further, with the owner automatically reverting to the correct prior owner depending on the issue's status. At step 6, the original support person from step 1 should ideally contact the customer. At step 7, the ops person from step 5 would ideally be the assignee.
In other words, while I don't want multiple assignees for a given step, I do want there to be a "support assignee", a "developer assignee", a "testing assignee", etc.
We can do this with subtasks and we can do it by manually selecting previous owners when changing statuses, but neither is ideal and I think the situation above is one where multiple assignees would make sense.
In my company, we have a similar workflow to Nikhil. We work in a scrum model, with developers, testers and a technical writer on each team.
The workflow of a development task is
Development -> Developer review -> QA testing -> PO Acceptance -> Done
The workflow of a QA task is
QA writes test case / automated test -> QA review -> Done
We had a tool which JIRA replaced that allowed us to assign multiple people to a task, which we found very useful for our workflow. On a QA task, I could easily see if the other tester on my team had already done work and I needed to do the next step.
Without this, I am finding it difficult to quickly identify tasks written by the other tester on my scrum team which are ready for me to review (versus the ones I wrote which they need to review).
So many people have asked for the ability to have multiple assignees since at least 2007. They have varying, valid use cases. I was disappointed that the JIRA development team unilaterally said they won't implement this and would ask them to reconsider.
https://jira.atlassian.com/browse/JRA-12841
While pair-group working (pair programming etc..) it would be nice to assign both persons to the issue.
Tasks move through different steps through development (example: Development, review, testing). Different persons can be responsible for each step. Even though the task may be in review or testing, the reviewer will have stuff fore the developer to fix. Having different roles to assign to would help organizing the work.
In our team we usually develop 1 or 2 persons together.
Then the code is reviewed by around 2-5 persons in individually or in pairs
Then it is tested by 1-2 persons initially, finally tested by the whole team.
Currently our system allows us to assign a single person at a given time. That limits our ability to follow who is working on what without looking through the log for the issue. The benifits of beeing able to assign multiple persons would be good for us.
What happens if John is assigned a task and cannot finish it, and it is moved to Jane's list because John was a slacker?
Are you OK with losing history of who it was originally assigned to, and the hours that were spent / billed on it?
In an e-Learning scenario, it makes sense to have an issue assigned to multiple users.
Here is what I want to do:
I have a storyboard which I want to assign to 3 people at the same time - the animators, the recording artists and the graphic designers. Once these people finish their tasks, they will pass it on to a common reviewer, who will review and close the issue.
Graphically it would look something like this:
Storyboard
/ | \
graphics animator recording
\ | /
reviewer
|
done
The three job roles depend only on one storyboard. The compilation of the three have to go to a reviewer. I'm racking my brains to get this working on redmine. Haven't found a solution yet.
Got this answer from an Atlassian partner https://www.isostech.com/solutions/
and then later from Atlassian
Objective:
Want to set who does the works for each step on an issue
Summary:
Use a plugin to copy values from custom fields into the assignee field whenever the issue transitions to a new step.
How:
1. Install the Suite Utilities plug-in:
This plug-in adds a bunch of new functionalities to workflows.
You will use the plug-in to copy the value of a custom field to the assignee:
Create a custom field as single user picker for each role i.e., dev, tester, reviewer to be assigned at different steps in the issue
Add these fields to the issue type's screen
Modify the post-function on the workflow transition between each step
Add a "Copy Value From Other Field" post function and set it to copy the value from the appropriate user custom field into the assignee field.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What should a good BugTracking tool be capable of?
Although there is a large set of features that a bug tracker can have I feel like it is a little overkill and was considering rolling out my own solution. With that being said I didn't want to remove any core functionality that might be used frequently with existing solutions.
The ones I can think of so far:
- creating bugs
- assigning bugs
- closing bugs
- adding description to the bug
Thanks!
Communication between the developer and the user.
Ability for the user to assign certain bits of information such as severity (how much that bug relates to them).
Ability for the developer to override that priority and, if possible, give a reason.
Ability to assign tasks to a developer.
Ability to sort between bug, enhancement, and feature request. The difference between an enhancement and feature request is very subtle but VERY important.
Ability to attach files (such as screen shots)
Ability to have custom fields (such as being able to select which OS, which service pack level, application version, etc).
Ability to have custom user profiles which also give detailed information about their hardware. It's also nice to be able to have the users phone number (if they are on your LAN) so you can ask questions, if needed.
Privacy. Some items, such as security exploits or information that deals with financial information, will need to be kept secret. Even OSS does this from time to time until they can get a patch ready. Everyone has their own rules.
Ability to show the changes between revisions so you can email out a Change Log so users know what you have and have not done.
Reminders about which items are left undone and are assigned to you / unassigned at all.
That's all I can think of...
A good search engine.
It's amazing how many bug tracking products that cost thousands of dollars get this horribly wrong.
Without a really decent search your bug tracking is more like a "bug logging" - log and forget - system which is pretty much useless.
create a bug
close a bug
this is sufficient for closure over the life-cycle of a 'bug' entity. Whether it is enough features for your purpose is another matter.
Take a look at the features of Mantis, choose the features that you need, calculate how long it would take you to write them, and then spend your time on something more useful unless you absolutely have to create your own. ;-)
For most systems like a bug tracking one, it's usually not the creation or editing of the data that makes the system useful. It all comes down to how easily you can navigate through the information to 'add-value' on top of just collecting the data.
Think about the people who will use the system, the programmers, managers, etc. For each group of people, what type of information will make it worth their while to come back to the system over and over again. How can you make it easier for them to get this information?
Collecting information is easy, adding value to it is the hard part.
Paul.
A bug tracker is nothing more than a list of things that need to be done.
It can be as simple as a text file in the software's directory to a fully fledged bug tracker with hundreds of users.
Start with what you need to work with, then expand as needed.
Use Jira, you'll be in good hands.
Here are some important features:
Assign priority to bug (e.g. critical, major, medium, minor, trivial)
Assign bug to a specific release in which it will be fixed
Watcher functionality (so you can be e-mailed when the status changes)
Workflow (i.e. who is working on it, what's the status)
Categorization, Prioritization, and Standardization.
And an easy way to query it so that you can reap the rewards of your hard work on the above three.
Also, make sure whatever you do is extensible! We always decide to add/edit our bug templates during the project depending on needs/fires.
There are a lot of great solutions out there, you probably don't need to roll your own.. But either way you're going to have to make the same decisions. We use a solution that allows us to roll our own templates, so at the beginning of every project we revisit this same discussion.
FWIW: When we rolled our own request tracking system, we built it around procmail and our existing internal web authentication system because we wanted it to be extremely unobtrusive to use: we just send e-mails to the developers (using group aliases if we want) and add a "[t]" to the subject to open a ticket. The recipients get a modified e-mail with the original request and an additional link to the web page that displays the ticket and allows them to close it with 1 mouse click. So the most common tasks are performed through the e-mail client (opening, requesting more information, replying, ...), although there is also a simple web interface for searching etc.
It took only a few hours to write and after more than 34000 request tickets in 7 years or so, I guess it's OK to claim that it has only the essential core features:
create a ticket (by e-mail with marked subject)
close a ticket (clicking on the link in the e-mail, then clicking on "done")
all communication goes over e-mail, not through a web interface(!)
people who were recipients or sender of the original e-mail (opening ticket) are notified about closed tickets ("Subject: <old subject> closed by <someone>" + link to ticket in the body, enough information for most people so they don't have to go look which ticket/bug that was etc.)
a simple web interface provides a search function for own/open/sent/team tickets
Notable absent features that might be needed for a bigger development team / more intense software development:
flexible status for the tickets (dupe, wontfix, reopened etc.)
priorities
reassigning tickets explicitly (in our dev team, the e-mail just gets resent to the unlucky guy who has to do it)
adding comments to the ticket that don't get sent to everyone
assigning the bug to a particular version of the software
YMMV, but it has worked very well for us so far, both for bugs and for simple requests that the sender wants to keep track of.
Define bug.
Thinking about that will most likely make you realize that you're gonna spend a lot of time "rolling your own".
This might be a little beyond what you had in mind, but for me, integration with source control is a must-have. To be able to view the diffs between versions associated with a bug/issue is very handy.
Please please please don;t spend much time "rolling your own". Your time is better spent researching and learning to use real tracking systems.
Some to look at
Trac, Bugzilla and FogBugz. The last one has free hosted solution for small (one or two man shops?) companies.
SO has lots of threads about this topic.
Try not to roll your own unless it is just a word doc or a spreadsheet. Any time you spend making your own is a TOTAL waste.
EDIT
Since you won't be dissuaded, then I'll maybe add some things others have not mentioned.
You need reporting functionality - users need to be able to run queries and they should be able to select the fields they want to "view".
Workflow/lifecycle of a defect is also a good feature. (basically a state machine of the states the defect will go through. ) In fact, this is a useful exercise for you to define all your use cases and functionality. Given that you are in college and did not start out as aa CS major, I doubt you will come up with many on your own. Take some time to browse the feature lists and demos of existing products.
Ability for emails to be sent to various interested parties.
Anonymous users able to see a SPECIFIC defect that they entered
Different access levels and authorities (admin, manager, developer, tester, end-user)
Our bug tracking system is one of the two essential links between my company and our customers ("live" product reviews where existing customers are encouraged to suggest improvements and user interface tweaks being the other).
A bug tracking system must, first and foremost, encourage trackable "dialogs" with your customers. It must answer the question "Have you fixed the problem (defined broadly) that I have been having yet?"
It must have (in no particular order):
A short description of the problem or feature request (the title)
Room for an extended description
The ability to attach files/images (screenshots)
The ability to prioritize bugs/features
The ability to categorize entries as bugs, features, inquiry, etc.
The ability to assign bugs/features to areas (UI, database, documentation, etc.)
he ability to assign bugs/features to products (we track bugs on five products)
The ability to assign bugs/features to releases ("to be fixed in version 5.1")
The ability to assign bugs/features to people (developers/writers)
The ability to assign bugs/features to customers (reporters)
The ability to re-assign to a different person (developer)
The ability to Resolve bugs/features (mark them as finished and ready for testing)
The ability to mark resolution status (fixed, won't fix, can't reproduce, etc.)
The ability to Close bugs/features (take them off list after resolution & testing)
The ability to Reopen bugs/features (restore to "Open" if testing fails)
The ability to inform customers the bug has been resolved (e.g. via email)
Date and Time stamp on every step (Open, Resolve, Close, Re-open)
The ability to report on the number of Open bugs! (how close to release are we?)
The ability to show bug reports versus resolutions
The ability to search on bugs/features by date, priority, product, person, etc.
The ability to list and sort bugs for easy scanning!
Those are the things that we typically use in our system (FogBugz). While this may seem like a long list, we really do use every feature that I've listed here!
On a particular project we're working with a total of 10 team members.
After about a year working on the project (and using Mantis as a bug-/feature-tracker eversince), the bugtracker gets more and more difficult to use, as no standard has been setup that explains how to create new tasks, how to comment tasks etc. This leads to multiple entries for the same bugs, inability to easily find bugs when searching for them etc.
How do you organize your bugtracker? Do you use a lot of (sub)categories for different portions of your application (GUI, Backend etc), do you use tags in the title of tasks (i.e. "[GUI][OptionPage] The error")?
Is anyone in your team allowed to introduce new tasks or is this step channeled through a single "Mantis-master" (who would then know whether a new report is a duplicate or an entirely new entry)?
Always link a version control system commit to an issue and back so that you know which commits were made do solve which issue and why a certain commit was done.
What we did is to introduce a role for approve entries to the bug tracker. This role can be shared by different people. The process is either to approve, to approve with a small edit, or to reject the entry with the request for further editing or clarification.
It is better for the general understanding if the role is not given to people working in the (core) team.
In a "large" mantis system on the open web, I've seen the rules go something like
New: Anyone can enter a bug.
Acknowledged: A select few people can upgrade it to this level. These people have seen every new bug for a while, and thus they'll know if it's a duplicate. Or they can pass it back to the reporter for clarification until they understand it well enough to do this job.
Confirmed: Set by decision makers who basically say "We will be doing this".
I don't actually remember where it was, and more importantly I don't know how well it worked.