In the future, have additional filtering / saving config. But for first iteration, show all issues with a due date.
We need further UX design to determine what should be in each issue entry in a given calendar day.
Original description
### Problem to solve
It is very hard to have a long-term overview of issues because there is only a list and the calendar exports lacks support for longer planning timeframes (also see gitlab-ce#54133).
Further details
I want to be able to have a calendar-based overview of all issues planned in the past and future. It would be nice to have this kind of overview both on a project and a group level.
Proposal
An alternative “calendar view” should be implemented in addition to issue boards. A nice way to do this has been implemented by Trello.
This would also make a lot of sense in combination with gitlab-ce#52542.
*This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.*
@victorwu yes, it does. This would support projects that mostly rely on due dates. From the top of my head, for a first iteration, we might add it as another type of view “Calendar”, after “Boards” in the side nav. This might not work that well for some reason, just sharing.
I think a horizontal timeline view would be a step forward, but wouldn't quite solve the challenge I, and my team, are running into. Within an issue, I have many checkbox items due by different people at different dates. If there was a way to map these to a calendar and allow filtering by assignee, that would give me what I need.
I think another challenge is that if we were to break out each checkbox into an issue (which I assume would be the next suggestion in relation to how GitLab currently functions), I'd be creating ~50 issues per event (multiply by sometimes as many as 30 events in a quarter) and creating/managing issues would be a full time job without considering the time to execute on the action items.
This (if a "filter by assignee" option is added) would also be one of the missing features to use gitlab for general task tracking so we could abandon tools like trello, asana or workboard - leading to an integrated tool for the whole company.
@jgragnola : Regarding https://gitlab.com/gitlab-org/gitlab-ce/issues/54134#note_129556976 you mentioned that creating a lot of issues (one per action item) is a lot of work. Can you talk about why doing the same thing with checkboxes (that’s what you are doing now right) is less burdensome? I wanted to understand where the difficultly is, especially since there seems to be a lot of details you are managing. Thanks!
@victorwu The checkboxes are all pre-loaded in my template. So I can create all of it in a minute or two.
There was conversation in the marketing team about epic templates. If we could have an epic template that pre-loaded certain issues that are common to every epic of the same nature, that would save time. Oddly enough I woke up today with a vision of how an interface would look to generate these... I'd lean on your expertise, but maybe doing a brief diagram would show what I mean.
a "subscribe to calendar" button for issues/milestones by project/global.
gantt diagram view to have roadmaps by project/global (this might require a start date beside to due date to be adapted with time tracking) (This might be a different issue though.)
Why do you want that? Do you care about the work that is being done? Do you care about people's availability? Which parts are you managing? Since we already have issues and a lot of data there (including due dates), we can surface that in calendar/timeline views. But we don't have much about people data and their availability right now. So that would be separate.
Here is a real world example of what David and I are struggling with:
I have a customer that wants someone from David's team to be on-site for 1 week some time between 4/3 and 4/23. David suggested Dan Peric as that person based on matching his skill set with the requirements of the job, but
neither of us have an easy way of determining what other engagements his team has going on around that time nor
do we know what Dan's calendar is like without involving Dan directly in the discussion or going outside of gitlab to his calendar (I realize that this part is a much more difficult thing to see)
If we had the first part we'd be more able to at least visually see the work David's team has and if we're able to see "assignees" on those things have a rough idea who else might be available or which week would be best for Dan going to my customer site.
I think having visibility of the work in a calendar view would be hugely helpful and then being able to filter down by assignee would help further...and we could adapt our use of that to make sure people's time is accounted for in the issues. (I could even envision people putting a PTO issue on the board to deal with that...an integration with our calendars would be amazing, but I realize that's unlikely...for now).
Thanks @cdmaurer13 for the example. Do you have any examples of how you are using GitLab issues in the first place? Could you paste a few so I could see? Does one issue correspond to one engagement (e.g. one 1-week visit?) Or are the issues being used to track specific work that could be done over multiple engagements?
It looks like most of the problem here is relation to availability and calendaring, but I'm guessing there's a unique aspect with tracking work and issues that we could take advantage of.
I just added you to a project and I'd like to carry the discussion offline for it because some of the data in that customer project is sensitive. I will contact you in slack.
@cdmaurer13 : I see from the example issues that you are entering time per user per issue. So does https://gitlab.com/gitlab-org/gitlab-ee/issues/10741 suffice for what you need? In particular, an issue could represent a customer or even a particular customer engagement. Is that enough that capture the time tracking granularity?
Yes, definitely. I think a first MVC of being able to report on the time spent split up by each individual works for me. We can continue to iterate on how we can visualize that after.
@victorwu I would like to add, we might have a project based on customer engagement. The project has milestones and schedules that are not connected to the member such as @cdmaurer13 said. This might be a kickoff date, other due dates such as Phase 1 implementation due date Phase 2 migration kickoff Phase 2 3 day onsite engagement.
We are not looking to recreate google calendar but have useful calendaring inside issues for many reasons including Engineer availability but also milestones in a project.
Agree with David. I know we're talking about issues and having time tracking features on that, but it would be useful to be able to abstract that time tracking up to the project (or even epic level). Thinking through some of the potential problem areas of what we're talking about...if you could set a Total estimation at Epic level (for example, but project level would be ok too) and then each of your issues' "spent" time roll up into that full time bucket...that would be really cool...and you could see burned hours across all of your issues.
I know I'm getting ahead of myself there, but we can iterate on these ideas! I like the direction this is going though!
Victor Wuchanged title from Implement calendar view for issues to Calendar showing issues on issue due dates
changed title from Implement calendar view for issues to Calendar showing issues on issue due dates
@victorwu for the most part yes. I'd be fine with less information (labels and weights removed, maybe) so it is more of a single line. I am imagining if you have 3-4 (or more) issues on a day how busy that might look. For me a title and who is assigned would be enough information...if I need more I could drill down on it.
@victorwu would this essentially show a board in calendar view? What I mean by that is, it's not all issues in a project - because like @cdmaurer13 pointed out, with the labels and weight, it could become overwhelming in a calendar view. But a good first iteration would be to show all issues with a due date - title and owner are most critical info to display as @cdmaurer13 said and drilling into the issue for more detail.
I think filtering by owner is essential. Probably would have to be a v2, but a hover to show the additional details (labels, weight, etc.) would be helpful.
Yes @jgragnola , it would be similar to a board in that the scope of all possible issues that could be sucked in and displayed is the same. But only issues with due dates would be shown on the display, and furthermore, upon further filtering, there would be less.
We'll work on a more specific UX design to figure out the how to display the issue cards and what info to put into them, so that it is not too overwhelming.
@victorwu thanks, makes sense! This is definitely beyond scope, but would it be possible to have a list of the issues without due dates in a column on the right/left of the calendar that you could drag and drop into the calendar? I think that would be helpful in setting timelines. Dragging functionality would be a game-changer!
This would work for PS on a first iteration as your description says. Eventually, it would be nice to make multiple calendars, not unlike the kanban board both at the group and project level.
Really really important feature. Even though I am a single user using Gitlab, I would even upgrade my plan for this if its not going to be provided in CE, if it supports Google Calendar integration. I use Google Calendar for scheduling all the work I do and having a Google Calendar-Gitlab sync would really help a lot. Can this be prioritized? Thanks in advance.
It would be great to use Google Calendar to plan due date for issues and even color code it according to the tag. The possibilities are endless.
Tracking coding issues is just one part of our business and we don't want a split brain so we track everything outside GitLab atm. Unfortunately. This feature would make it possible to move our complete project management to GitLab issues which would result in us buying premium.
I just re-read the description. What we would need is a calendender that shows issues from a selection of groups. Not having an overview over all projects does not make sense.
I've been there two years ago. We are an Ultimate customer from the beginning, but start to feel that the future with GitLab is not as bright as promised. GitLab's feature set becomes broader and broader, while the features become ever shallower. We have now moved issues and epics to TargetProcess and are investigating moving repos and build to GitHub. One reason to stay with GitLab has been the on premise option. Reading through the direction document and the OKRs - especially the CEO OKRs - makes me wonder if on prem will stay an option in the future. I simply cannot wait any longer for a miracle to happen. A calendar view - and no progress for two years. Giving the current state of the product and the execution speed, an integrated product that has reached feature parity with the market leaders is something i do not expect to arrive anytime soon. Maybe GitLabs execution reflects the planning quality that is achievable by using GitLab.
You can do this instance-wide via /dashboard/issues (needs additional filters, unless self-hosted), group-wide, project-wide, with any query options you want just by setting up an issue search and F5 the page (to update the button's iCal URL) and using the calendar feed URL in your calendar client.
If GitLab wishes to integrate this they could take off-the-shelf iCal-parsing table library and use existing iCal generation and just render that in the browser. For now you need an external iCal-capable client for viewing.
Also keep in the mind the above is read-only, changing due dates needs to happen on the issue itself.
Why interested: Their Scrum masters would like to be able to plan capacity and load according to planned absences. In this particular case, a number of different contractors are working on the same project, but do not share the same calendars. They'd like to centralize all this information in GitLab for planning purposes.