Related
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.
I have 2 custom entities ex: Building and Business in CRM on-premise. Building has multiple Units/Suite #'s and each Unit/Suite# is occupied by a Business. If a Building Unit/Suite is under renovation, then the Business has to be temporarily closed.
How can i automatically update Business Open/Close when Building Unit/Suite status changes? The update does not need to happen instantly. I need search around 20000 records to update the correct Business entity. Also there are fields in Business like start and end date which is retrieved from Building and Closure duration is updated with end(minus)start date.
Is Plugins the only way and how can i achieve it using plugins! How difficult would it be, impact on server and i am mid level C# dev. Please provide any links in the right direction. The env is 2011 on-prem
Thank you very much !!!
A straightforward solution can be built with a plugin. A synchronous plugin can update the status changes to the Business entity immediately and (in the PreOperation or PostOperation stage of the Update message) even within the same database transaction.
Generally speaking, with plugins you can build the most efficient and seamlessly integrated business logic possible.
However, often you can actually achieve pretty much the same using a workflow. Some advantages of building workflows:
Does not require a skilled software developer to build;
Workflows can be modified ('configured') quickly.
Execution of workflows can be postponed (e.g. until a condition is met or a date has passed).
Some downsides of workflows are:
In CRM 2011 your code always runs asynchronously, outside of the original database transaction;
Some time may pass until the action takes place; the user does not get immediate feedback;
Querying and selecting related data is limited to n:1 relationships (from the n-side to the 1-side, not vice versa);
Execution of workflows requires more resources than plugins;
Extensive use of workflows can easily lead to spaghetti systems that are really hard to maintain and perform bad.
In your scenario it looks like the requirements for selecting the appropriate Business record are too complex to handle in a workflow. In a workflow you basically can only navigate from one record to the other by following lookup references on the record at hand. This means you can only get from one record to the other when there is a n:1 relationship and when you navigate from the n-side to the 1-side.
In plugins you do not have this limitation; there you can write a QueryExpression or Linq-query to get the records you need. So, in your case a plugin seems to be the right choice to me.
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.
One of the basic tenets of CQRS, as I understand it, is that commands should be behaviour-centric, and have a value in the business or the UL, and not data-centric, ie., CRUD. Instead of focusing on updating a customer, we have commands like CustomerHasMoved. What if you have CRUD screens which are there to correct certain data. For example, we need to change the name of a customer which is misspelled. This doesn't really have much value in the business. Should this just be under the umbrella of an UpdateCustomer command?
I just want to put a comment on this quickly as it popped up.
It is important to note that some objects are actually CRUD and thats ok. I may not really care why a name is changing in my domain where I ship products to people and only need that data to print mailing labels. The trick is in making behavior the default and THEN reverting to a CRUD interface once you are sure you really don't care about the reasons as opposed to vice versa.
Greg
Actually, there could be various reasons to update the name of a customer. As you were saying, it could be misspelled or... you could get married and change your name to your husband's.
If you had only an UpdateCustomer command, you would loose the original intent and you would not be able to have different behaviours for each of them. If the name was misselled it could be as simple as updating the database, whereas if your customer got married you might need to notify the marketing departement so tthat they can offer a discount.
In the case that your entity is purely CRUD, that is there is no intent that you can associate with modifying the properties, then it's OK to have an UpdateEntityCommand. You can then transition slowly to something more task based
CustomerHasMoved is the event that is fired after you have updated the customers location. This event updates the read databases/cache databases. The command from the gui should be MoveCustomer or something like that. I think I would put the update of the customer name in a command like UpdateCustomer.
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.