victorwu

Thanks for the idea! We have the idea logged here: https://gitlab.com/gitlab-org/gitlab-ee/issues/1734. Feel free to add comments there. Thanks!

Sean already did a great job responding to each point here. Just want to add one more quick one. We are working on key-value labels right now, and we think it will solve many of the problems of custom fields. Feel free to take a look and add some comments. Thanks!

https://gitlab.com/gitlab-org/gitlab-ee/issues/9175

--- As a user, I want to be notified by todos that only have any pending actions on them ---

Can you explain further what you mean by "pending actions on them"? We are working to simplify and streamline our notifications and todos in GitLab. In particular, the current thinking is that they are very similar. A "notification" is an email, and a "todo" is a something that GitLab calls your attention to in the Web UI to take action on. So mechanically, they are very similar and we would like to harmonize them.

Our latest discussion is in https://gitlab.com/gitlab-org/gitlab-ce/issues/48787.

I’m not aware that we intentionally changed anything with the line wraps.

But if you go to User Settings > Preferences, you can select between Fixed vs Fluid layout width. Do you recall making any changes here recently?

Here’s an issue with some discussion on the design of fixed vs fluid options. https://gitlab.com/gitlab-org/gitlab-ce/issues/27347

If you have the Gold Plan (for a group) on GitLab.com, you will be able to use the Epics feature for that group. See [1].

If you have any other plan (including Free), you should not see that field (or at most you should see a dismissable upgrade UI). That doesn’t seem to be case currently. I’ve logged an issue to correct this. [2]

[1] https://docs.gitlab.com/ee/user/group/epics/

[2] https://gitlab.com/gitlab-org/gitlab-ce/issues/49484

In GitLab Starter, we have the export issues to CSV functionality, which includes two time tracking fields: time estimate and time spent. Is this the kind of reporting functionality you are looking for?

https://docs.gitlab.com/ee/user/project/issues/csv_export.ht...

Anything else that makes sense that we can log an issue for?

hitekker: See my edited comment above. We do not ship untested code. But any problems that users do find we definitely want them captured as soon as possible so that we can triage and fix.

Yep, GitLab releases on the 22nd of everyone month. Here’s a list of releases.

https://about.gitlab.com/releases/

If you could log a bug here with any details that would be great! https://gitlab.com/gitlab-org/gitlab-ce

Thanks!

Edit: I wanted to clarify that if you’ve observed any undesirable behavior, we welcome you to log it and we will address it as soon as we can. I see how my original comment made it seem like we ship untested code. That’s not the case as Sid mentioned below. That being said, there might be specific edge cases or scenarios we have not captured in our tests. So problems do appear from time to time. So I wanted to invite anybody to log any problem so that we can reproduce it as soon as we can and get it fixed.

Also as Sid mentioned, this feature was recently brought to Core so that more users now have access to it.

Is there any particular time tracking feature you are interested in?

In addition to [0], to version-track issue/mr descriptions that was already referenced earlier (within an epic), we also have [1] open, to do the same for comments. Please feel free to comment more there!

[0] https://gitlab.com/gitlab-org/gitlab-ce/issues/15597

[1] https://gitlab.com/gitlab-org/gitlab-ee/issues/3706

We are continuing to improve our issue tracking / project management at different tiers. You can take a look at these epics and issues to see much of the work that we have already planned. Most of these issues are in Core or Starter:

https://gitlab.com/groups/gitlab-org/-/epics/8

https://gitlab.com/groups/gitlab-org/-/epics/5

https://gitlab.com/groups/gitlab-org/-/epics/6

https://gitlab.com/groups/gitlab-org/-/epics/22

https://gitlab.com/groups/gitlab-org/-/epics/156

https://gitlab.com/gitlab-org/gitlab-ee/issues/3969

Highlights are bulk subscriptions of issues, better subgroup support for labels and milestones, and expanded issue weight support.

Thank you for the explanation. I've created an issue. Feel free to continue the discussion there.

https://gitlab.com/gitlab-org/gitlab-ce/issues/44553

Product manager at GitLab here. We welcome contributions!

See https://about.gitlab.com/contributing/ and https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBU...

Here's an example of a blame on a previous commit of a file.

https://gitlab.com/gitlab-org/gitlab-ce/blame/57ce7c655cc58e...

Did you have some particular feature request beyond this view?

These are exactly the type of features we are focused on this year.

Commenting on a block of code: https://gitlab.com/gitlab-org/gitlab-ce/issues/4143

Making a review session: https://gitlab.com/groups/gitlab-org/-/epics/23

And here’s a greater overview: https://about.gitlab.com/direction/#merge-requests-approvals...

Thanks for the feedback. Our goal of 10.0 was to release a version of group boards that serves the needs of large organizations. So we built the feature with multiple group boards in mind. We are considering bringing a version of group boards to CE as many of our users are telling us it makes sense for smaller organizations as well.

Please see below the ongoing discussion:

https://gitlab.com/gitlab-org/gitlab-ee/issues/928#note_4132...

https://gitlab.com/gitlab-org/gitlab-ce/issues/38337

Thank you for the feedback.

As of GitLab 9.4, you are able to use both JIRA integration together with native GitLab issues. If JIRA integration is configured inside your GitLab project, the issues menu item in the navigation still goes to native GitLab issues, and you can use GitLab issues as usual.

Inline editing is important design direction we are heading toward. The benefit is that you don't have to reload the entire page. And of course you can do single tasks, like updating labels / milestones / titles / descriptions all independently and separately, providing a more web-app-like experience, instead of a website experience. Ultimately, it's more usable and efficient.

In particular for the issue / merge request description areas, we want to get to a more collaborative design in the future when you can see other users making changes in super near-real-time, almost like Google docs. Currently, our issue descriptions already are updated in real-time, but it takes a few seconds for you to see updates. So we are working hard in this direction and we appreciate the validation that inline editing makes sense.

In particular, we've introduced a number of real-time features for issues in the past few releases. We are working to bring these to merge requests soon to get consistency.

https://gitlab.com/gitlab-org/gitlab-ce/issues/29978 https://gitlab.com/gitlab-org/gitlab-ce/issues/31631 https://gitlab.com/gitlab-org/gitlab-ce/issues/31630

Thank you for the feedback. We're tracking how we can improve this functionality in this issue. Our design team is working hard on the merge request (the widget and the entire page) in general, and we are aiming to improve this part as part of that change.

https://gitlab.com/gitlab-org/gitlab-ce/issues/32885

Thanks for the feedback regarding editing merge requests. In this release, we brought inline editing to issues. (So you don't have to do a full page load, like you mentioned.) So we will definitely bring this concept to merge requests at a later release.

Regarding searching by approvers, we definitely recognize it's a common flow. And we've documented it in an issue. https://gitlab.com/gitlab-org/gitlab-ee/issues/1951. We hope to work on it soon.

Thanks for the feedback. Indeed we recognize the inconsistencies in the UI from search to other areas. Rather than overhaul entire GitLab with each new improvement, we typically apply the change to one area first, and incrementally bring it to other areas as we get more feedback. This also allows us to move quickly and make tweaks. Thanks!

Thank you for the feedback regarding commenting on merge requests. The diff view is indeed very important for collaboration. In the upcoming 9.2 release (slated for May 22nd), we are adding the ability to comment on older versions of the code and diff between versions.

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10388

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10572

You are referring to this one right? https://gitlab.com/gitlab-org/gitlab-ee/issues/1906. Yes, it is currently marked as an EE feature. And Sid linked to the dependent issues feature below.

Both of these features are not scheduled for development yet. We scope work out month to month, so we can't promise anything regarding those at this time. But we are discussing them as you see in the issues and considering how they would fit into our product as we recognize they are important features for many teams.

For relations between issues, we are considering various designs, such as: https://gitlab.com/gitlab-org/gitlab-ee/issues/1941 and https://gitlab.com/gitlab-org/gitlab-ce/issues/29444.

Thanks. Feel free to add feedback to the ongoing discussion here: https://gitlab.com/gitlab-org/gitlab-ce/issues/29835.

We also have a new research panel, which includes usability texting. Anyone is welcome to join to provide further feedback, which will significantly impact our product development.

https://about.gitlab.com/researchpanel/

Thanks for the feedback! In this iteration, we think recovering more space helps users focus on content, and allows them to see more content at once. Definitely we recognize the tradeoff of additional clicks and discoverability as a result.

We are definitely focused on usability, and navigation in general. We don't claim to know all the right answers all the time. So we are iterating with each release, and working hard doing user research as well to inform our decisions. You can see some of our recent work regarding nav here: https://gitlab.com/gitlab-org/ux-research/issues/3. Thanks.

Thank you for the feedback. The sidebar is indeed oft-discussed. And we don't claim we have all the right answers. We work hard every iteration to make the best decision, ship updates, and get feedback.

This is the issue where we discussed the sidebar change. Feel free to see what contributed to the decision. https://gitlab.com/gitlab-org/gitlab-ce/issues/26200

This is the ongoing issue to discuss the change and any future iterations: https://gitlab.com/gitlab-org/gitlab-ce/issues/29835

We are working hard to improve UX and navigation specifically at GitLab. Our UX team is focused on design and user research. Here's some work on the research end: https://gitlab.com/gitlab-org/ux-research/issues/3.

We originally built GitLab with that use case of a single repo in mind. Create a GitLab project, and you have a single repository for code. We know this is an important use case for many teams, because of it's straightforward, simple scenario. It's something that's important to us, even as we expand to other use cases of multi-repo teams (groups/subgroups housing of projects). Thanks for the comment.