Group level issue boards

mentioned in issue #929 (closed)

Why create group level issue lists on based on group level labels ... from a program management perspective... labels are useful at the project (repostitory) level... at the program (group) level, I will be more interested in an ageing board...

Older than 3 months
Last 3 months
This month
Last week
This week
Yesterday
Today
Closed

Additionally, I would also be interested in a clear indicator that shows re-opened issues, and the number of times it was re-opened

@harkirat what would the board actually show?

Group level issue boards allow you to do the same magic, but across an entire group.

Can you clarify the idea? Do you mean https://gitlab.com/group/board that look exactly like today's https://gitlab.com/group/project/board? If so, I'm 100% for it! Just like issues can be viewed across all projects in the group, the board should work the same.

@JobV it should show cards/issues from all repositories in the group that a user has access to. The card itself should show the issue, the repository it is in, the list it is in, and the last time it was moved.

My thought process is that at a group level you don't need to report issues or close issues or move cards. That should still happen inside each repository.

In case someone wants to report a group level issue, it is better to create an empty repository to track such issues. We're on Gitlab not Github where adding extra repositories would cost us extra money

EDIT: My apologies for the late response, as a matter of principle, I do not respond to emails or messages on weekends unless it directly relates to my weekend plans or it is a life and death situation.

mentioned in issue #911 (closed)

Hey, when the issue board was released, I asked on twitter if it supports issues from multiple repositories and I was pointed at this thread. First, thank you for going down that way, it's a great addition. I'd like to share my compagny's use case for this. As a disclaimer, please note that we don't use Gitlab for our main product, but as you can see, we are actively watching it, and the progress are amazing!

We are working on a product that is made of various applications working in a platform. All applications are in separate repositories, so is the platform, and other common modules (~70 active repositories). As an agile SCRUM organization, we are trying to have only one backlog in one place. The "apps team" basically works on 15-20 repositories, which makes it impractical to use repositories' issues as a source of truth. As a result, we setup a workflow by having Trello as a source of truth and importing issues from our versionning service, but we lose some of its features such as milestone and release management. We'd love to be able to say: this board shows the issues (maybe with a filter with tags) of those repos. That would allow us to only use one tool and have one backlog per team, ease follow up to the original requester and so on. Different views, different users, same data.

I think the proposal here addresses our needs, and we're excited to see what's coming next!

Sorry for the poor writing style, I am not a native english speaker.

Cheers!

@harkirat I strongly disagree. A lot of teams work across several repositories in a single development flow. I am Scrum Master for a team working on a single product spread across 10+ repositories. Doing user story / task / issue management and assignment inside each repository is not an option, we need a global view for it to be of any use to us.

Copied some content from this issue comment: https://gitlab.com/gitlab-org/gitlab-ce/issues/21660#note_14880834

Lists will be possible for group labels or shared labels (repo 1 has a label UX and repo 2 has a label UX).

Mockup:

An MVP could cut the need for group-level labels, and instead rely on labels being common between projects. I agree that group-level labels would be nice, but it doesn't need to be a hard-requirement.

Milestone changed to %8.13

Added ~360297 label

Added ~139512 label

Added ~481018 label

Mentioned in issue #911 (closed)

@JobV Is this shipping in 8.13?

Added ~874214 and removed ~481018 labels

Milestone changed to %8.14

Removed ~360297 label

Milestone changed to %Backlog

My company has been looking forward to this, I'm disappointed to see it relegated the backlog. Is there a current plan?

cc: @smcgivern https://gitlab.com/gitlab-org/gitlab-ee/issues/928#note_17330190

Added ~126459 label

@AaronHarun I have been told that there are some things needed still to have group level labels https://gitlab.com/gitlab-org/gitlab-ce/issues/19997 done properly before this can be addressed, I hope we can get this in %8.15 as I too am very eager to get this in!

@AaronHarun it's in the backlog because it's not in the next release. This is just because we need to be strict about what we work on in each release, as we have a tendency to overschedule (this was originally planned in 8.13, after all) and then fail to ship some awesome features because we just have too much in a milestone. The benefit of this new approach is that a milestone is more realistic; the downside is that there are more things in the backlog, but we'd rather not say we're going to deliver something if we don't think we can.

For 8.14, issue boards are getting some improvements, but aren't a major focus as they have been in previous releases: https://gitlab.com/gitlab-org/gitlab-ce/issues/22689

It's up to @JobV and @regisF, but I expect that we will probably schedule this in one of the two releases following 8.14, as it's a really great feature and we'd also love to have it for our own use

@AaronHarun we need to balance small and big improvements and developer capacity. This will ship in the near future, but just not yet.

@JobV My company has also been looking forward to this as it greatly affects our day-to-day workflow. Can we as your customers at least get an idea of what the thinking is right now, please? Thanks.

@gsmethells I'll leave it up to @victorwu going forward. Q1 2017 seems reasonable, but let's see. We typically don't plan for more than one month in advance to stay agile.

@gsmethells + @JobV : We're aiming to get a better direction of issue boards in the coming weeks. So I'll be able to better answer that question.

How are you using GitLab now? With multiple projects? How do you do issue management inside GitLab?

As far as terminology goes, a project for us is many repositories. Maybe 2-3 frontend repo and 1 backend repo. We're currently letting the UI repos drive our project. For example, if a new component is needed in the UI, it's not complete until any required work on the backend service is completed. Even with that workflow we really need one way to manage our UI repos as one project. I really appreciate all the effort you guys put in.

We are also looking forward to this feature as a way to migrate away from JIRA (and toward GitLab!)

@nicholastulach Same and I think the group level boards were the last big hurtle to looking at switching.

Added ~360295 ~360296 labels

Thanks @mkaatman. Victor mentioned to me the need of GitLab to move away from repository-centered and towards project-centered, with multiple projects. I hope that in 2017 we can make great strides towards making that happen.

Added ~897283 and removed ~360295 ~360296 labels

Similar to @mkaatman our projects are always multi-repo (creative, front end code, back end code etc.).

@JobV okay, will do.

@victorwu the Thanksgiving break caused my tardiness is replying, sorry! I am in the same boat as, I believe, others are who commented above: we have many repos (with disparate subject matter expert [SME] qualifications to be allowed to merge into those repos and different packaging/installation aspects) but each such repo works in concert with the group of repos as a single "project" to us. They are client or server or library oriented repos.

So, when using GitLab, we have multiple Projects inside one Group; therefore, Group is our preferred level of scope when peering into GitLab to monitor the progress of the single "project" as a whole.

Grooming Issue priority across Projects in the Group for those Issues in the Group's "Backlog" Milestone
Handling several Merge Requests for several repos regarding one Issue
Defining and using Label behavior across all projects where this Issue itself comes in.

We'd like to have Board stage Labels shown across repos because we Kanban through those stages as a group in a stand-up meeting and it's hard to see what is in "Design" vs "Development" vs "Testing" vs etc without this feature.

Thanks @gsmethells for the feedback. That makes a lot of sense and we'll definitely take that into consideration as we improve issue boards.

Since I have you here, would multiple repos within one project ever make sense to you? I'm not saying we are necessarily going to move in that direction. But just wanted to get your thoughts if you see any huge problems with that concept.

We have another grouping level above projects called Clients, so our organization is this:

Clients -> Project groups -> Projects -> Repos (mutliple repos per project)

Example:

Warner Bros -> web-sites -> b2bou.com -> Repo 1, Repo 2 ... Repo (n)
Warner Bros -> mobile-apps -> FindTheater -> Repo 1, Repo 2 ... Repo (n)

Maybe if we were able to create groups within groups and establish parent->child relationships, that would make it flexible enough to handle any type of organization.

@victorwu I think having a plurality of repos within a Project abstraction would make some sense. I think there are some users who would keep repo to Project 1-to-1 still, but offering many-to-1 repos to Project, I suspect, could conceivably be leveraged by power users who desire to organize that way. How that affects the other abstractions within a Project requires significantly more thought, of course, but it is probably an option that should be bantered about while looking to define a vision for this.

@dmoore1 yeah, I mentioned that to @JobV here and he felt it was more appropriate to punt the thought at the time, which you can see in his comment after mine. I believe @victorwu is doing some design work here trying to come up with a vision that will work.

@victorwu my two cents: I think it is probably easier to do a Group of Groups than a plurality of repos in a Project, but then I know I don't know the GitLab code base as well as you and others at GitLab, so I'll let you guys decide. Both seem plausible. As long as a wholistic view of the user's perspective of a "project" is achieved, then that's the goal, I suspect.

We're using repos for standalone components and apps on the UI side. It turns into a many-to-many relationship. Repo A might be a date picker component. Repo B might be a user management App. Projects 1 and 2 could end up using both repos. The organization I can envision that would be quite flexible is that for a given "project" concept in gitlab you can add as many repos from any group into it. Groups can be used for whatever organizational structure you need but really doesn't have any impact on a project. If there was a high level "project groups" concept that could be a nested set of other "project groups" that eventually contain projects that might be nice for organization. I would expect issue board and milestones would work at the project level.

Thanks @mkaatman + @gsmethells for the valuable feedback. We appreciate your enthusiasm and patience as we sort this out. We are working our best to ship quickly, and as correctly as possible.

You can follow along in our many issues here, and participate in the convos:

https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&state=all&utf8=✓&milestone_title=Backlog&label_name%5B%5D=Discussion&label_name%5B%5D=issue+boards https://gitlab.com/gitlab-org/gitlab-ee/issues?scope=all&state=all&utf8=✓&milestone_title=Backlog&label_name%5B%5D=Discussion&label_name%5B%5D=issue+boards https://gitlab.com/gitlab-org/gitlab-ee/issues/1295

Following this discussion I think even "group level issue boards" will not cover every use case. I.E. our company has two main groups with multiple projects in each. I am mostly interested in a global "who is working on which issue regardless of the group/project" view.

I believe issue boards should be considered as a standalone top level entry which integrates nicely with gitlab groups and projects. What about this approach.

An Issue board could be created by everybody with the proper permission.
The owner can assign projects, users and lists to the issue board.
Issue boards are shown as a link in the left "accross gitlab" menu bar.

This solution would allow group level and project level issue boards as well (an group level issue board would have all projects/users from that group assigned, a project level issue board only one project and it's users assigned). This would make the migration process easy.

GitLab could handle the details. The backlog is aggregated accross every project in the issue board. Let's say the manager created an issue board with 5 projects from two different groups assigned. If a user with only permission to two projects would look at this issue board, he would only see issues from these two projects. Dragging an issue to a list would automatically create the label in the issues project if it does not exist.

Removed ~897283 label

@victorwu Would you mind telling us why you removed the "coming soon" label and give us an idea about what the timeline is, now that it's not "soon" any more?

@pablo_uno : Thanks for your interest. We recognize the many problems and pain points discussed in this issue here. Feel free to add something additional if your scenario is different from any others here so that we capture as much feedback as possible.

We are currently designing our next iteration of issue boards, and I didn't want to presume just yet we would solve these specific problems here in our next release of it. Likely before the end of the year we should have a better direction and I'll be able to better comment on the timeline of solving the problems laid out here.

Waffle.io is closest to ideal I've seen for this type of setup.

I think the idea of @j-steinblock is the best solution so far.

Maybe it's possible to do it like Jira where a "board" just shows a list of stories that match to a customizable search-filter.

@virth maybe even that would not be sufficient. What about companies that have repos in a private gitlab instance, a public github repo and participate on different other repos or even non repository based issue trackers like zendesk.

For me as a lead developer the focus is on my team. I want to know what my team is working on, see the backlog and assign "planned / working on / done" In other words: every solution that is based on a project or a group or a gitlab instance and has not the "company" or "team" as its entry point in mind would not be sufficient and sooner or later everybody will stumble across this limitation.

The best solution would be to create a standalone tool with gitlab look and feel and bundle it with gitlab like mattermost or gitlab ci before it was bundled with gitlab. This tool could share the same database and architecture but comminicate with projects via an api.

As @danielrwoodward mentioned waffle.io does this for github

see https://gitlab.com/leanlabsio/kanban which goes into that direction already

@anti43 well, they are right now at almost the same level as the Gitlab Board Feature. They also lack a group-wide board.

I just tested their 'enterprise' version and allthough it doesnt work well at this stage they have some interesting approach: the allow to add any project to be added to any board by group/name reference.

@anti43 What you mention is kind of the approach i meant with "what Jira does". You could:

create a board and add whatever project you like.
create a board that shows issues that are assign to selected team members
create a board that shows issues with selected labels
create a board with a "and" or "or" combination of the first three

@j-steinblock I understand the need to focus on the team. And as you said earlier your team has multiple Gitlab Groups. It's the same with our team. We currently have two Gitlab Groups for one team. But if I could add every project, user or label to a board, I think I could handle this. I would just create a board with every project (no matter what Gitlab Group) that my team is working on and would have the needed board.

added ~1035182 ~113221 labels

@JobV @awhildy @dzaporozhets @smcgivern

Let's chat about how labels and issues and nested groups will all play nice together. Can you look at my proposal in the updated description and see if that makes sense with nested groups. I think that model is flexible enough to solve the team-centered collaboration problems, but not overly complex to maintain.

@tauriedavis as she has also been thinking about nested groups.

@victorwu: The proposal makes sense to me. I agree with limiting Group-level boards to group-level labels for lists. However, can I filter/search the issue board by project level entities (such as author, assignee, milestone, project label, etc.?)

@awhildy : I was only thinking about labels. I think the board should only care about group labels, both for lists and the filters, at least for the first iteration.

I didn't think about the other attributes for filtering. Could we start UX on this soon-ish to start hashing out these use cases and what's possible? I'd like to see if we can push this for 9.1.

For simplicity, I'm thinking that group boards can start out with:

No milestone associated with it. No filtering on milestone.
No project labels.
Only group labels.
Filtering by authors in the associated projects (per description of what are associated projects).
Filtering by assignees in the associated projects (per description of what are associated projects).

@cperessini - When you have some time, would you be able to help out with the UX for this?

@awhildy sure thing, I'll catch up to the current conversation

This will have the same place as within the project navigation: Issues -> board

With the changes from https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9309 taken in to account, it will look like:

I definitely need this to be included into gitlab or I am going to have to move to another system. Right now I have one group for my while app. Inside of that group I have different repositories for each different platform (i.e., web, iOS, android, and backend). I want to have a way to create issues that are not necessarily delegated to any specific platform, but the entire application as a whole. Right now I cannot find any way to do that. If you could implement this it would make gitlab much more appealing to me as it can be a more one-stop-shop for my company.

Thank you,

@Guardiannw , I totally agree with you. What we are trying to do as a workaround here, is to register all the issues in a "management" project. If we need to specify what are the submodules that will receive the updates, we tag the issue with the submodules involved.

But of course, that is not a definitive solution, only a workaround.

@bruno-eng-comp Same thing here, it's just a pain to do and we can't close issues straight from the commits since repos are not in the "mamagement" project.

@oliviermilla, I never tried, but can't you close the issue of another project using an reference to it like is showed here (eg. group/otherproject#22)?

https://docs.gitlab.com/ce/user/project/issues/automatic_issue_closing.html#default-closing-pattern-value

Hmm, nice, I didn't know. Thanks!

@bruno-eng-comp thank you; I had thought of doing that but it really seems like a hacky way of doing things. It may be the best thing in the meantime though until some more definitive solution comes around.

My only comment is: please don't make this enterprise only.

@victorwu @smcgivern here are some designs for this feature

Group board

A group board shows issues from all its projects and subgroups' projects. Lists can only be created from labels that belong to the current group, but the cards themselves show issue numbers, labels and assignees even if that information belongs to lower levels. In the same way, when filtering the board you will see options from all the subgroups and projects.

Cards show the project name next to the issue number. This requires that we also implement https://gitlab.com/gitlab-org/gitlab-ce/issues/27093 in 9.0. I will post this final card design in that issue too.

Sidebar

The sidebar for the group-level board adds the project name next to the issue number. The rest of the fields are the same ones as in the project-level board.

Filtering by project

We don't currently support this in the group-level issue tracker, but it'd be a good addition to allow users to filter their board by project.

Adding issues

When adding issues, the cards also show the project name. This would also be a good place to allow filtering by project

cc @awhildy @tauriedavis

@cperessini Great work to get the discussion going! We will confirm by EOW when we can get our first iteration in. 9.1 or later. A few thoughts in the meantime:

I don't want to add too many project level details in our first iteration. I want this to be a truly group level abstraction of issues first. Recall this will help the use cases of teams that have multiple repos/projects. If our users want the additional detail of projects in group boards, let's add that later.
So essentially can group boards serve as as "group issues"? I want to see that answered in the first iteration.
Can a user start a group in GitLab and just start using group boards right away, without caring too much about projects?
So let's leave out all the project level filtering at the beginning.
So I would like to focus on group labels as lists and not show project labels in the beginning.
I think we will have to show project names. But maybe the UI doesn't need to emphasize that too much.
I think the only missing in your design is how to add new issues to a board. What do you think is a good way to do that without exposing too much the project details? Maybe when you click the plus button on a list, it asks for a title and to select a project from the group? And it preselects one of the project for you? Preferably the design is still inline and not a modal, so it is the same existing design with project boards, but with just an additional pre-selected field. And of course when you submit, it associates the group label with the issue.

@cperessini @sarahod

One design decision here is making group boards include all issues of all projects and projects of all subgroups. This can be both confusing and very powerful. Do you think this is a good idea? Anyway to get some further verification? How can we make a very informed decision since this one is hard to ship incrementally?

If we make a decision here, and change it later, it would be extremely disruptive for existing users. So I want to get as close as possible the first time. Furthermore, I don't want to start creating too much UI and configuration to increase optionality here if all possible. I just want one canonical design.

@victorwu

Can a user start a group in GitLab and just start using group boards right away, without caring too much about projects?

I think this makes a lot of sense; it would allow users to have a generic issue tracking tool without having to worry about the fine grained control that Projects offer. I think that more often than not, projects will follow in this scenario anyway. Otherwise the user would have just created a project level issue tracker.

@cperessini:

We don't currently support this in the group-level issue tracker

The reason is that if it's a single select, it's redundant: just go the project's issue tracker. I agree that this would be nice in that design, though.

@victorwu:

One design decision here is making group boards include all issues of all projects and projects of all subgroups. This can be both confusing and very powerful. Do you think this is a good idea? Anyway to get some further verification? How can we make a very informed decision since this one is hard to ship incrementally?

I had the same question! I wonder if once we've released nested groups, the expectations around what a group's projects are will become clearer?

So essentially can group boards serve as as "group issues"? I want to see that answered in the first iteration.

Is the idea (also looking at the last point) that if you add an issue, and there are no projects, we create a default project (maybe 'issues'?) for the issue to go in?

One design decision here is making group boards include all issues of all projects and projects of all subgroups. This can be both confusing and very powerful. Do you think this is a good idea? Anyway to get some further verification? How can we make a very informed decision since this one is hard to ship incrementally?

I agree with @smcgivern on this one. By releasing nested groups first, users will begin restructuring their projects and I think it will naturally become clearer the type of overview they want on their issues. I think once nested groups has been released, we should ask users whether they could share with us how their projects are now organised and discuss with them what level of reporting/overview of issues they need on a group board.

This thread is hard to digest, but I hope nobody is suggesting "wait and see if multi-project boards are needed". Flipping between projects during morning standup is a nonstarter. Kanban teams need to see work items from many projects (server, client, mobile) on the same board. Could be done a few ways, but group-boards are a natural fit.

when you have a product/service with a few projects (iOS, android, BE etc.) you still want to be able to see the whole product together –how's everything going and so on...

For my purposes, repo != project. I've been treating group == project as a partial workaround, but I think now that this is not the appropriate abstraction.

I want to:

Be able to create/mange some issues at a level above a single repo.
Have a Wiki that aggregates information above the level of a single repo.

The current project == repo equivalence has been too stifling. I think group level issues is moving us towards a project == group equivalence that will also prove constraining.

Now that someone suggested nested projects, It seems clear to me that that is the logical path forward. From an implementation standpoint, it seems like it should not be difficult to create a project that references other projects with a "part-of" relationship. This would be my suggested first step.

As a later step, to make the distinction cleaner, I suggest making "project" a first level object that can have "has a" relationships with repo, wiki, issue tracker, and other projects. This concept has a nice simple symmetry to it.

Groups on the other hand would just continue to be an aggregate of users and would have an "associated with" relationship with projects to help manage permissions, but would have no "features".

My needs are similar to @dheater, I often have one project with few repositories per service, every project has own repo/wiki/issues but main project is level above and needs own wiki and issue tracker.

@sarahod : Ideally I would like to have something ready to start working on for 9.2. I know that's tight. But do you think it's possible for us to collect this feedback once we release nested groups this week (as RCs) to gitlab.com? Any way we can do this beyond just looking for feedback from gitlab.com issues? Thanks!

My $0.02: At @konduto we prefer to avoid switching tools the most, so we try to keep everything regarded to issue-tracking/project management to one single GitLab's group. On this group there is a project for every different system we work on and a few "non-code" projects for tracking non-technical issues. We have month long developing cycles - in a Kanban-like fashion - that involve multiple projects. As of today, we still need a separate tool for visually organising a cycle. Currently we use Trello for that.

We would profit a lot if we managed to keep of everything in a group-level board, pretty much like @cperessini's proposal.

added ~897283 label

mentioned in issue ux-research#2 (closed)

added ~333913 label

@JobV What does the EE Premium tag represent? Is there a Premium version of GitLab.com? Or will it be included in both .com and EE Premium?

I guess all the CE users will have to stick to external kanban management.

Wait... not in CE or EE Starter? Was that a mistake? Project boards for everyone, but $200/seat/year for group boards.

Adding my 2 cents: I understand it being an EE feature, however I think it should be in EE Starter.

Adding my 2 cents: I understand it being an EE feature, however I think it should be in EE Starter.

I'll second what @josh64 wrote. I can't see where group boards should be a difference of $16/month. I understand you need to sell seats, that's why we purchased EE already but IMHO this should definitely be a part of the EE Starter package.

This is far from an EE premium feature. Increasing cost per seat across an entire company that much to make the morning meetings for a few managers easier isn't a reasonable business proposition. Especially when seats are taken by contractors and clients for single projects and by office staff for gitlab SSO.

Especially coming out of the blue after months of feedback from users helping to plan out and direct the development direction.

@Guardiannw EE Premium features will also be available on GitLab.com.

To the rest of the comments above, I'll leave it up to @victorwu to make a decision on whether this should be in EE Starter or Premium, but considering no EE label was added yet, I chose one so this is properly reflected on our direction page.

I just wanted to chime in on the EE version. Knowing this feature was coming was a large factor in my team's motivation for purchasing Enterprise Edition last year. Not having this available in EE Starter would be very disappointing.

@victorwu @JobV any word on when this could be coming? Here is the problem we face:

Our entire stack is divided into multiple projects; We try to gather higher level stuff in a dedicated "Product" project, but then have to list all sub issues and reference them from the other projects; Basically we have no way to track easily what everyone is up to in one place and which stories are actually being worked on

@florian-monfort yes, within the next few releases. It's high on @victorwu's shortlist.

Oh. While understanding that that it might make sense from a business point of view to make this an Enterprise Premium feature, I very hope it won't be, given that I jut convinced his company to buy an enterprise subscription lately.

Please please make this a community edition feature !

Please please please ... can't wait to have this feature. Will it be available for my group in gitlab.com ?

We really looking forward to work with this feature, it's something we really can use within our organisation :)

Considering the cost of EE premium it should be nice to put this feature into EE Starter. The pricing of a EE Premium licence is a huge difference (39 -> 200). Converting licence to premium for this awesome feature is something I can not sell within our organisation. Hope you will consider to put it in EE Starter :) @JobV @victorwu

I think this should be a community edition feature

Mark Horn gitlab@mg.gitlab.com writes:

I think this should be a community edition feature

Yeah, I agree. It doesn't really make sense to make it an enterprise only feature.

I wonder what happens if the community decides to reimplement an ES/EE feature and add it to the community edition. Is that even possible?

@yorickpeterse this can help consolidate database related work between repos. Except that our work is split at a higher level in the namespace, with gitlab-ce being in gitlab-org and infrastructure being in gitlab-com.

@micah can it be an EE Starter or CE feature ? I dont see why it is limited to EE Prenium

Sam gitlab@mg.gitlab.com writes:

@micah can it be an EE Starter or CE feature ? I dont see why it is limited to EE Prenium

I think it should be a CE feature myself.

mentioned in issue #2508

changed milestone to %Next 2-3 months

changed milestone to %9.5

changed the description

@cperessini : Can you take a look at the updated description here. I think a group issue board should just be totally analogous to a project board in the first iteration. We just use group level things for everything that has a group level, i.e. labels and milestones. We can expand on in the future with subgroup functionality. Let me know what you think.

changed the description

@smcgivern @JobV : As we move into group features, I want to stay away from project associations (e.g. project labels and project milestones) as much as possible, at least for first iterations. This way, we simplify the features and encourage more group level feature adoptions. We should treat project <-> group features bleeding into each other as additional feature requests that we can work on separately after we release the group version initially.

@victorwu makes perfect sense to me!

@victorwu I think the proposal makes sense but I'm not sure about this point:

Project labels are not displayed in the cards and they are not displayed in the sidebar either.

I think this is a valid way to do it and we should do it like that in the first iteration, but I wonder if it'll feel like the board is missing information. Labels are an important part of an issue and of what makes them recognizable, so I wonder if we should include that information in the cards.

I'm not completely sure about that though, what do you think?

@cperessini : at least for us, I think if we release it without project labels, it'll force us all to use group labels, which is a good thing. and then we can gauge feedback from the community to see how important project labels are. my suspicion is that if you are using a group board, you care about group labels more anyways. we can simply create a separate issue to add project labels to group boards. and if there is clear demand, we put it in right away as the next iteration, or even a patch release if it's a clear problem that needs to be fixed right away (doubt that)

@victorwu in this group-level board, will it be clear which project each issue comes from? I don't see that specifically addressed in the new description or the recent discussion, but it seems essential; I suspect it's very common to write issue titles in a way that assumes the reader knows the project context.

@victorwu that makes total sense, thanks!

changed the description

@victorwu I added a mockup to the issue body.

As you mentioned in Slack, there will be almost no visual differences between this and the project version of the board. The fact that we don't show project labels in the cards, the filters or the Add list dropdown, for example, dos not have a visual impact and is simply a matter of which items the backend returns.

I included the old filters here because the new ones are not available yet in the group issue list.

The Add issues button has been removed because that functionality is out of scope.

I kept the Full Screen button and the ability to collapse and expand the backlog and closed lists because I assumed they would carry over from the project version.

mentioned in commit gitlab-design@d1180ea1

Thanks @cperessini : Let's see what engineering says when we start on it. We may be able to include the new filter bar. Everything else looks great for now.

mentioned in commit gitlab-design@49b587f0

I would like to upgrade from CE to EE starter for 50 user, if we get this feature in the EE starter plan.

added frontend label

added deliver label

removed deliver label

added Deliverable label

Hey is there any update regarding EE Premium or Starter? I also think it is more a starter feature than a premium feature. 200$ is far more than 40$ for things like this, which are needed by a huge part of the developers.

@cperessini is this issue UX Ready?

assigned to @felipe_artur and @psimyn

@sarrahvesselov It is. The only thing that could change is the filters, which as @victorwu said depends on engineering (https://gitlab.com/gitlab-org/gitlab-ee/issues/928#note_33153768)

added UX ready and removed UX labels

assigned to @cperessini

Thanks @cperessini. I added you back as an assignee per our new UX guidelines.

hi @sarrahvesselov, please don't make this an enterprise edition feature only, I would love to see this coming to the community edition too

We hear you @jcvtieck, I don't believe there has been a final decision on this one yet. @victorwu and @JobV would have more insight into where this will end up.

Just wanted to voice my concern about this being an EE feature only. Having multiple repos as part of a single project is not an enterprise thing in my eyes.

created branch 928-group-level-issue-boards

mentioned in merge request !2458 (closed)

You can create/edit/delete multiple boards.

You can edit the name of a board.

@cperessini Are these meant to say "list" instead of "board"? Not sure when the name of a board goes.

Also, in the screenshot the nav shows "Boards" - I assume it is "Board" (singular)?

@psimyn I think those are correct. In CE you can only have one board, which doesn't have a name, but on EE you can have more than one.

The dropdown menu to the left of search allows you to switch between boards, create and delete them, or edit the current one's name and milestone (another EE feature).

mentioned in merge request !2467 (merged)

FWIW, this feature would let me make a serious pitch for buying enough licenses to move towards GitLab and away from Jira... But I am very concerned that it would be a non-starter at the the EE Premium price point and that would make me sad.

Same goes for my group. We dropped Stash/Bamboo a long while ago in favor of GitLab, and would absolutely love to drop JIRA in favor of the GitLab version. After discussing it a bit internally, there are other features from JIRA that are really important and those are the project management tools such as epics/components/etc that are heavily used by "non software" people. I would love to see those features integrated in as well. Really some of it's already in there with the Milestones, they would just need to be transferred to the group level board.

project management tools such as epics/components/etc that are heavily used by "non software" people. I would love to see those features integrated in as well. Really some of it's already in there with the Milestones, they would just need to be transferred to the group level board.

Can you elaborate a bit more on this @jlack? We are working hard to consider the needs of our non-developer user base. Any insight into what would help them be more productive is welcome!

+1 on @jlack 's feedback. Gitlab is getting close to be the 1-stop shop for us too. It works great for developers, but as soon as you ask project managers, scrum masters and software testers in the mix, they'll ask for a lot more features that are not available in Gitlab issues.

@sarrahvesselov please let me know if I should just open a new feature request ticket with the items below. I'm just using the opportunity since we have your attention. :)

Nesting issues

Add the ability to nest issues instead of just linking them by adding a # reference. SCRUM Epics linking to issues and issues linking to sub-tasks is a common pattern in JIRA for example. We try to mimic it with labels, but then we get overwhelmed with the number of labels we have to create/manage.

Issues Navigation with filters

Could we add a filter to list issues and then navigate between the issues on that filter (previous/next)? Currently the project managers complain of having to filter and then open issues in a new tab, instead of just keep navigating between the issues on the filter already applied (another JIRA productivity pattern).

Time reporting

The burndown chart is against completed tasks. Would be great to have it against time spent on each task.
Look at the time spent by a user on a particular milestone. What did "team-member-1" spent their time on this particular milestone/project? I imagine we could get some of it from cycle analytics, but the reporting seems task-centric rather than user-centric.
How much time is allocated to each project member for the milestone? How much time has the project member spent doing their tasks?

Board view

Can we see the issue weight in the board for each issue?
Can we see some indication of time spent/estimate in the board for each issue?

Thanks @gomesp for elaborating! But yeah there are lots of features for project management that are really the only things shackling us to an Atlassian product at this point. I'll list a few that I can think of and maybe our dev-ops wiz will weigh in as well(cc @Ensley)

The ability for a ticket to have subtasks
Longer term goals. JIRA offers these as components/epics
It would be nice to be able to detach the ticket board(s) from code. For example our hardware designers use JIRA to manage their workflow as well. Our IT person(s) use JIRA to process tickets, etc
Iteration(or sprints depending on what you call them) planning.
Retrospective tools

Glad the GitLab group is considering tackling this issue. We have fallen in love with the GitLab product and can't wait to see where you go with this one!

Gitlab smokes bitbucket already but I need the JIRA replacement also. It shouldn't be a hard sell considering how slow JIRA is when you try to scale up.

I'll just add we've weighted the options and for the time being we decided to go with an external tooling as it provides integration from project management (crafting epics, stories, personas, themes all the way down to bugs and tasks).

Tough decision as we've integrated gitlab in our entire development process otherwise.

For us this is a must have. We are a company with 5+ employees. We need a Board to get an overall overview for all our projects. In our opinion this should be a CE Feature since it's also helpfull/a must have for small companies.

@psimyn @felipe_artur @cperessini : What happens when you use the + button in a list? What project does it create the issue in? The simplest thing I can think of is that GitLab just picks any project. Probably should be the same one each time. But I think it can be an implicit non-requirement. And in the future, we can think of something more specific, similar to: https://gitlab.com/gitlab-org/gitlab-ce/issues/34411

@victorwu i would hope, for whatever my opinion is worth, that a project selector would accompany the text field for the issue title to allow the user to select a project. The data will already be on the page since it's in the drop down right above. Otherwise this will lead to a lot of senseless moving of issues between projects and no one likes senseless moving of issues.

One critical problem with the current issue board within GitLab is that it's anchored to repos(I know that's the name of the issue here, just stick with me). This means that every issue created is associated with a single project, but a lot of groups distribute software into lots of smaller repos that each do a small number of things instead of a small number of repos that do a large number of things. For groups that develop like this, GitLab issue board is not an option, so we are unfortunately forced to JIRA.

Just noticed @victorwu commented above with "what project does it create the issue in?" and I think creating a group level issue board with this type of behavior wouldn't be an attractive implementation for groups that distribute software. Not sure if others feel the same way, but I know for lots of the groups I have worked with, as long as issues are attached to repos/projects then unfortunately we won't be able to drop JIRA.

@victorwu I had assumed the + button on lists would not be visible (though it is in mock). I'll update issue description to explicitly mention this

The Add issues modal is not in scope for this first iteration. Users can still move issues "into" the board because there is an existing Backlog column that they can leverage.

@psimyn : The Add issues modal I was referring to the button you click that pops up a modal and you have a lot of UI to add existing issues into the board. The + button is at the top of each list, and creates a new issue. The lists are all group label lists right? So it's not immediately clear which project the issue would be created in.

So do you think it's feasible/reasonable to just have GitLab pick one default project in the group to create issues when you click the + button? Or do you think it's better to leave it out altogether for this iteration?

I think once we release https://gitlab.com/gitlab-org/gitlab-ce/issues/34411, we will learn how effective it is, and we may be able to borrow that concept. But the UI needs some work if we port that concept to boards here.

@psimyn : This is the add issues modal I was talking about. That's not in scope for sure.

@victorwu being able to create issues would be good. Frontend for that is certainly feasible - I'm not sure about it defaulting to a project (and that not being configurable). For a user that might seem a bit odd, might be ok if either doc'd or our method of picking a default was good :)

I'm not sure either about choosing a project for the user and not letting them change it. I can't think of a 'smart' way of doing it that would let us correctly guess a good default project.

I thought about making this a setting, but that seems like complicating it more than we need to. I think @jamemackson has an interesting proposal, where you can change the destination project on the fly. We can remember the last one the user chose with a cookie.

What do you think @victorwu @psimyn?

Thank you for the awesome feedback @gomesp! Please open separate issues and ping me, I don't want to clog up the discussion here

@psimyn : I think @cperessini 's proposal in https://gitlab.com/gitlab-org/gitlab-ee/issues/928#note_35969967 (which is really https://gitlab.com/gitlab-org/gitlab-ee/issues/928#note_35903595 @jamemackson's idea) is really good. Could we squeeze that in here? At a minimum, having the dropdown to select the project is perfect. We can do the cookie storing part in a future issue if we can't get that in now. But having that dropdown is great!

In our start-up we are currently evaluating to migrate from Redmine to GitLab Starter before we will hire new employees in the very near future. Our software is build in very small modules (i.e. git repositories i.e. GitLab projects). The main things we are missing compared to Redmine are

the group level issue boards (planned for 9.5 Premium): Each developer works on a lot of modules (GitLab projects), but we rather would use a GitLab group for a project.
sub-issues (planned for 9.6 Premium): We have a central issue list for all features and bugs. Since these must be dealt with in several modules (and therefore GitLab projects, e.g. three modules for client, API, server) almost every time, we create sub-issues (tasks) in the modules (GitLab project). This works very well because we have the overview in the bug and feature list connected to the sub-tasks (in Redmine even adding up the estimations and the time spent) and the developers can concentrate on the smaller sub-tasks where the real work is done.

Is there any chance that these two features could make it into the Starter Edition? We are also supported by some external developers working only a few hours per month. Adding all of them as GitLab users the premium edition would add up to real numbers and would be to expensive for us.

I can only support what @olaf.kortluke said. Having group level milestones and group level labels in the starter edition but not a group level issue board is incomprehensible to me. Personally I assume the group level board as a basic workflow feature required by enterprises and it's not some advanced workflow feature. Already with 10 projects (which is really not a lot for an enterprise) each having its own issue board things are getting quite complicated and you're wasting time jumping between the issue boards.

I disagree @subesokun I'd say this is not an enterprise-only feature at all. The fewer developers, the higher the chances that people are working in sprints across projects. The bigger an enterprise the higher the chance developers work in groups on single projects.

@subesokun I use starter edition at home for my personal projects the same way I use gitlab at work for my professional projects. Is it really that incomprehensible?

@mackevision

I dont think that any logic is appliable to all cases these days, with all the DevOps movement going around.

Yet, at the end of the day, Gitlab developers have to draw the line somewhere. It seems fair to assume that some of the features can be useful for CE users, while still making them available to EE users only. After all the starter edition has a fair pricing, especially when using it in a business.

(Nevertheless I'm still in favor on making those features available in the community edition, but well ...)

@aptituz That makes sense. We are in a very special boat sadly that prohibits even starter edition even though being a business (we have "few" developers compared to the amount of total users needed). I guess we are a very special case that is not really accounted for in any of the pricing models i saw so far.

This is the one thing that will most likely lead to us not adopting gitlab for issue tracking and stay with Jira. Which kinda makes me sad heh.

Sorry for the off topic, i shall resist from now on and voice these only indirectly related concerns elsewhere.

Ah, don't let me voicing my opinion stop you from voicing your's. :)

I'm just a random user like anyone else. I totally understand your position/situation, I'm just stating that b/c I think that the development of such a great product like Gitlab requires some money.

IMO, the money comes from when those of us using CE/starter get our companies to convert from bitbucket to gitlab enterprise.

If the devs never have a chance to use the feature they can't pipe up when someone says, "Why does bitbucket suck so bad and what can we replace it with?"

changed the description

mentioned in issue #3047

mentioned in issue #3048

@mackevision @mkaatman I just said that having it as EE Premium only feature is incomprehensible to me. Having it also in the CE edition would be perfectly fine for me :)

mentioned in issue #3064

changed milestone to %10.0

Was looking forward to this (and hopefully the possibility of EE Starter inclusion) this month.. Is it being pushed back further? Seems like a critical feature.

changed the description

The only thing that keeps my company from moving away from GitLab CE + Jira to GitLab EE is this feature. But we will never switch if this is restricted to EE Premium subscriptions, we are a small team and we simply can't drop 200$/seat/year for just one feature, as we don't need any of the other EE Premium features at all...

added In dev label

I'm in the same boat as @matistaken. This feels like a crippleware situation, where the missing feature puzzle pieces are locked behind a paywall. I know this isn't exactly the place to discuss this matter, but I will say that it would be better if EES/EEP features were completely distinct from the CE features, rather than being enhanced parts of them, thus making CE an incomplete product.

added In review and removed In dev labels

Great feature suggestion! Would this be made available for groups hosted on gitlab.org?

@joelostblom : This issue is labeled EE Premium. So that means for self-hosted GitLab, it will be in the EEP tier (https://about.gitlab.com/products/). For GitLab.com, it will be available in the Silver Plan (and thus the Gold Plan too). https://about.gitlab.com/gitlab-com/

@victorwu: OK, so it is going to be a feature only for the Silver Plans after all. Quite useless then, that is. Silver Plans are almost five time as expensive as Bronze Plans, so they're absolutely out of question for small teams such as us who'd have wanted this feature to simply track multiple parallel projects and have no need for the other Silver Plan features.

@victorwu Thanks! I wasn't sure how the self-hosted plans compared to plans hosted by GitLab. Is it a general rule that EEP premium features will be in the silver and gold plans, or is this decided on a feature by feature basis?

To echo the sentiments above, this feature is a key pitch to my small development team, but we don't have the budget to spend top dollar on git hosting when the same features are available from the competition at much lower prices or even free.

I agree with most of the comments, I'm really lacking a general issue board, why would I want to pay much more for something that I can do with trello for free?

@joelostblom the general rule moving forward is

Bronze = EES features Silver+Gold = EEP features

All existing users & groups will be put onto a 1 year free plan that includes all existing EES+EEP features. We'll be making an additional announcement on this very soon, but you can see our previous announcement here: https://about.gitlab.com/2017/04/11/introducing-subscriptions-on-gitlab-dot-com/

@victorwu how settled is the EES vs. EEP decision? I'm working on budgets for next year and I need to decide if we're continuing with our EES subscription or if we're dropping back to CE so we can spend the money on a different tool for issue management.

@masonjm : This issue is currently labeled as EE Premium and there are currently no plans to change that. If we were to change it, we'll definitely re-label it accordingly. Thanks!

Thanks @victorwu!

Regarding this part of the description:

Only issues in immediate child projects of the group are available in the group board. Issues in further descendent subgroups are not shown in the group board.

I have a setup where the top level group is the company group, and the subgroups are departments. I think this is a common arrangement. According to there's no way for the company to get an overview of their milestones or issues across subgroups

@victorwu

@masonjm : This issue is currently labeled as EE Premium and there are currently no plans to change that. If we were to change it, we'll definitely re-label it accordingly. Thanks!

Sad to hear that this feature will be EE Premium only as this means that our team will stick to Jira and won't use the GitLab issues as we've too many projects -> too many issue boards to use and maintain

We're not a distributed team which needs those expensive EEP features and won't upgrade to EEP just because of this feature.

Without this we will stick with the CE version. Could have been the selling point to upgrade and move away from jira.

putting this in EEP makes the upgrade from EES more costly than paying for Jira which has a far more complete issue management, I don't get the point.

@MattDelmarter @dedsm @matistaken Based on this link (https://about.gitlab.com/direction/#100), it looks like competent issue tracking is going to be EEP/EEU only. If GitLab already had a kick-ass issue tracking system built in, and they had the fancier features on EES, then I'd definitely pay for it. I will not, however, pay top dollar for what comes standard on many free or cheap issue tracking systems, especially when I don't even know if these features will be implemented as such or will be implemented effectively. It's unfortunate, because I think GitLab has a lot of good things going for it, but their policies around what is CE vs what is not are not well thought out, and it's making me question ever going to a paid plan or using GitLab as an all-in-one solution.

@JoelFeiner Thanks for linking this up. A quick glance confirms to me that GitLab is very lost with what's considered an expensive feature and what's basic. I mean, blocking issues and subissues on the highest paid plan only? I'm not even talking about the planned Ultimate version (super-expensive, I'm guessing) which will give you powers to... lock issue description ;) I mean... come on!

I was hoping to move a bigger part of our workflow to GitLab, but I'm getting scared of their direction. I guess I'll stick to the basics (CE) for now, and see how it develops.

I think making this part of EEP is not a good strategy. I talked a lot with PMO people about what GitLab has to offer to them and I realized that they like JIRA a lot. If you add to that the thousands dollars more a company will have to pay to get “on par” features for project/product management. I will not be able to sell the switch.

What would be easier to sell is a base fee of 3.25$ for EES, then for that feature, an extra 1$ (or whatever you see fit).

@darekrusin It's very unfortunate too, because I think with a little reconsideration of how they split up EES/EEP/EEU vs CE, they could have a great product that would be compelling to pay for and yet still usable for free. The razor they use now -- whether the feature would be useful on teams of 100 or more -- is way too vague and seems to take no feedback from the community (i.e. people on such teams or smaller). They also do it on a per-feature basis instead of on a per-module or functional area basis, or based on usage. It's insulting to customers or potential customers to say that you can have issue tracking, but if you want to add a link to another issue, you have to pay $100 a month. I'd expect that from some free to play mobile game, but not from serious software like GitLab. Either make issue tracking a paid feature entirely, or don't. Same with boards. But don't put half of a functional area behind a paywall. It's a big turn off.

Believe it or not, this is a significant problem for our small team too. If group level issue board doesn't make it to GitLab CE I think there's a good chance we'll move to GitHub + Waffle.io.

As a small team, we're in a similar situtation. We've been using GitLab EES together with JIRA for a while, with the only major issue blocking us from migrating away from JIRA to GitLab for project management as well being the lack of group level issue boards. We'd miss a few JIRA features, but the convenience factor of just having one tool would more than cancel that out.

However, the price jump from $39 p.a. for EES to $199 p.a. per user for EEP, when none of the other EEP features are of particular interest to us, is simply too hard to justify.

Like @nap, I think an à la carte pricing model for features could be a great way to bridge the gap between EES and EEP. And while I understand that it isn't just something you implement from one day to the next, I hope it is something you will consider in the future.

I agree with the above. It doesn't make sense to make this EEP. The need for this feature is not only among large teams. As soon as you have more than one project for a product (e.g. web, mobile, sdk), you need this. You could have a team of 2 and still need this. It's just a matter of working well. And to push it off to EEP only sends the message that you care more about landing larger customers than you do about helping developers work more effectively.

Software development using components (e.g. web components) and microservices (e.g. AWS lambda) is very popular today esp. among small teams and startups. We have dozens of repos across numerous subgroups for one app, and we need to manage them all in a sensible way. I'd prefer not to switch to Jira, but I'm concerned that if my team doesn't find a good solution, the switch may be inevitable.

mentioned in issue #3317

I maintain my stance that this is a good candidate for EES with the current pricing structure. But I also strongly agree with direct points made by @JoelFeiner and @nap and implied by others such as @mikkel2, @darekrusin, and @matistaken (sorry for anybody I missed!) that the general pricing structure needs improvements that allow for more appropriate price boundaries between features.

In hope of keeping the broader pricing conversation focused and preventing it from simultaneously cluttering this thread and getting buried in this thread, I have created a related proposal (#3317).

I personally feel like it is appropriate for those of us who have constructive arguments for why this feature belongs in EES under the existing pricing model to continue posting in this thread since it is directly related to this feature. For those who have constructive thoughts about how to improve the pricing model in a way that allows us to continue to financially show our for Gitlab, I encourage you to contribute to #3317 instead of posting here about it.

mentioned in issue #3318

Over the coming months, we will continue to add new features to our paid Bronze, Silver, and Gold plans—these features will not be available on the Early Adopter or Free plans.

@victorwu - please confirm but it seems safe to assume that even though gitlab "value's us as early adopters" and have given us 1 year access to the early adopter plan, based on the content (above snippet) of the recent of the email many of us received after our plan was updated, that this feature will NOT be included in what we will have access to?

Assuming the above is correct, it seems that this (and probably many other features) are being used as bait to still force us into switching to a paid plan despite being valued as early adopters.

Like the many other voices above, I am seriously disappointed in the decisions gitlab has been making about the licensing decisions around the product and am seriously considering whether I can keep my teams on gitlab or not. This feature is really a make or break deal for me and obviously many others. I'm happy to become a paid user again but can't justify the prices you're asking just to get this feature. (especially when I am a 2 dev team with about a dozen additional people who only need access to issues)

Between the new licensing structure and the stability of gitlab.com itself, advocating for and continued support of gitlab is getting harder and harder to justify. I implore you to reconsider what appear to me to be very disingenuous licensing decisions around this feature and for gitlab.com generally.

A few people have mentioned the micro-services architecture as providing a strong use-case for this since it tends to create a high repo:developer ratio. Perhaps more so if those services cross different languages. I think that use-case is worth reiterating.

Although GitHub pricing has changed, the fact that they priced per repo was one of the strongest drivers that led us towards GitLab. I would guess that their price-change and your original pricing decision, was a result of the growing trend towards a single-responsibility, micro-service, design.

I don't know if GitLab itself operates within that micro-service world since GitLab is deployed as an all-in-one application (no way to know what private repos you have... so maybe you do) but many of us very much do. And that high ratio makes it really hard to manage issues across them all. I think that is why many have shown a lot of passion over the placement of this behind the highest available pay-gate -- even those on smaller, lower budget teams.

I would like to add a comment that describes my experience with GitLab as a part of the team that is using micro services a lot.

First of all, I would like to mention that we are really enjoying GitLab. Especially it's CI/CD features - that's awesome. In the same time, I see a huge issue in the way GitLab is moving.

We are a small team of 15 people but our business is growing fast and by the end of the year we expect 100+ team members that will use our on-premises GitLab EES installation. Our product is 100% based on micro services - we have 100 repositories right now and adding a couple more every week.

I'm a person who recommended GitLab to the team and who manages our GitLab installation right now. And I can't say that I'm 100% satisfied.

Issues. They simply don't work when your project uses tons of micro service repositories that are owned by multiple teams. We are not interested in Issue Boards for a single repository and even Issue Boards for a group - it solves the problem only partially. What we are waiting for is something similar to ZenHub that is able to work with all our repositories at once.

Yes, for a team project manager, it's great to see issues from his team. But what if I have sub teams in sub groups? What if I want to see issues from two groups (frontend-team/product-name, backend-team/product-name)? What if, as a CTO, I want to see issues from all projects in my company and declare a new milestone for the entire company?

What I want to say is that for now, GitLab is useless for us as an issue tracking software. Guys you are doing great work, and we see a move in the direction we want GitLab to reach, but there is still a lot that needs to be done and we are not willing to pay $200 per seat for "moving in the direction".

Right now we are paying $39/year per seat for code repository and CI/CD system. When adequate issue management will arrive to GitLab we will be happy to pay another $10-20/year per seat. For a 100 person company, it's $5k-$7k per year - not that bad (considering we are hosting everything on our own). But sorry, we are not ready to spend $20k/year just for issue management (since we don't need other features of EEP).

I consider this issue to be a good test for GitLab and its community. As a customer, I want to be heard: "Not only enterprise companies have a need in issue management". If Group Level Issue Boards will go to EEP, this will mean for me that GitLab marketing team is not interested in companies like mine and that I can not trust GitLab to be a central hub for my company development anymore...

Only issues in immediate child projects of the group are available in the group board. Issues in further descendent subgroups are not shown in the group board.

Mh didn't notice this until now, but this makes this feature anyhow kind of useless for us. We've created several subgroups for our projects and they have also some nested groups reflecting our team structure. Having several boards for the different projects we could manage somehow with some overhead but having several group-level boards within a single project due to the nested groups is simply not practicable and makes this feature sadly useless for us.

Is it planned to optionally show also descendent projects in the group level board at some point?

@subesokun I agree wholeheartedly that the single depth is pretty big ~~deficiency~~ limitation. I am a fan of simple-first, enhance later... so I too would like to know if that is a planned feature.

Frankly, I'm on the fence between wanting multi-depth or more of a build-your-own board feature like what waffle.io seems to offer. But the need to do that might just be a smell that projects are not organized correctly. Of course, reorganizing projects (e.g. rearranging subgroups) is kind of painful since all the references to the repos also need to be updated. Hmm...

@victorwu Are there plans to widen the visibility scope of boards? Is this worth discussing in a spin-off topic?

_edit: deficiency is the wrong word.

@victorwu - please confirm but it seems safe to assume that even though gitlab "value's us as early adopters" and have given us 1 year access to the early adopter plan, based on the content (above snippet) of the recent of the email many of us received after our plan was updated, that this feature will NOT be included in what we will have access to?

@jamemackson : Regarding (https://gitlab.com/gitlab-org/gitlab-ee/issues/928#note_39168639), yes you are correct. This feature here (group-level issue boards) will not be included in what you have access to. It will be in the Gold Plan for GitLab.com and EE Premium for self-hosted GitLab.

@subesokun @crussell52 : Yes, indeed that is a natural extension regarding subgroups. It seems like a natural feature to me. But with all features developed in GitLab, we welcome ongoing discussion. So let's indeed have a separate discussion here: https://gitlab.com/gitlab-org/gitlab-ee/issues/3342.

marked this issue as related to #3342

mentioned in issue #3342

Is this live on GitLab.com?

closed via merge request !2467 (merged)

mentioned in commit 192ae505

For all of the smaller organizations such as mine that would really love to have this feature built-in but won't be getting it because it is slated for EEP what is the best alternative?

In my case we have self-hosted EES and it just doesn't make sense for our company to pay 5x the price for this one feature for every user, many of which are very infrequent users or just reporters. None of the other EEP features are intriguing for us because we aren't a large company and we are gladly paying for the EES for the features it provides and to support the development. However, we definitely would like to manage our projects at a higher level than per-project so it is disappointing that now we know our only option that doesn't cost thousands of dollars more is to integrate some third-party solution...

Has anyone tried http://kanban.leanlabs.io/?

We are considering to use the EES version to manager all our repos. This feature is the only deal breaker. We have repositories that are small modules and our teams need to work on multiple repositories at the same time. Also, we cannot justify paying for the EEP as we don't need any of the other features.

In my case we have self-hosted EES and it just doesn't make sense for our company to pay 5x the price for this one feature for every user, many of which are very infrequent users or just reporters.

@colinmollenhour We're right there in the same boat. Currently self-hosted EES customers. About half of our users are either external or guest/reporter. As much as we want this feature, we will not be upgrading to EEP for it. IMO while this is justifiably not a free-tier feature, it is not an EEP-level feature. It's also quite disheartening to see this feedback continue to go unacknowledged by Gitlab.

Colin, Tim, Samir,

We're on the same boat. I mentioned previously we explored several solutions (non meeting our requirements as of yet), it was suggested that we try to integrate our Project Managment Tool craft.io to obtain the squad based overview of multiple projects.

One of their architects mentioned that they were working on a gitlab integration, I'll forward him this thread.

The functionality is so basic I would trade it even for Merge Requests (not to mention environments, docker registry, LDAP integration and so on). If GitLab's long term plan was to disrupt issue tracker space I can't comprehend how hiding such core feature behind EEP paywall helps the cause. Forcing every user to pay 10$+ for one of most desired CE features (and lack of response to current thread) kind of killed my trust in the product.

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

@victorwu After reading the enterprise edition tiers sections in the GitLab product handbook it's still very unclear to me why the decision EE Premium was made.

EE Premium features are more relevant for organizations that have more than 750 potential users.

I.e. this feature is only relevant if you've at least 750 potential users on your instance which are using this feature. Honestly, if you've already 10 potential users this feature will be relevant (if you're not developing a single repo monolith...). Or should "smaller" (less than 750 users) organizations be encouraged to work with the EES edition only with a single GitLab project/repo per product ?

Or has the rule "In doubt, make it a Premium feature" been applied? As said above it's very unclear on which basis the decision EE Premium was made. Maybe you could give some more information on why this decision was made.

We build systems using yocto which is much more geared toward many small repos. The absence of this feature means we must drive our projects using some other board/issue system :( sadly.

We are less than 30 developers. This feature has nothing to do with such a large scale enterprise.

Good point @subesokun, maybe there is a misunderstanding about how many organization are using GitLab? In my instance for example we currently have almost double the number of "projects" than users. Many of these "projects" are just mirrors of other repositories or exist only because we need separate repositories or separate CI pipelines, but many of these projects are also very closely related with each other such that managing the Boards for each project separately is basically pointless because of the lack of a higher level context. Indeed, my organization is not using issue boards at all because of a lack of group-level boards.

Most development is modular. Take GitLab as an example, there are separate repos for CE, EE, Omnibus, Gitaly, Gitlab Runner, GitLab Markup, GitLab Shell, Influx DB integration, etc. etc. etc.. It doesn't make sense to have all code for a project in one repo unless the product is extremely simple. Even with only a handful of full-stack developers working on all of these pieces together the benefits of a group-level issue board are very clear.

I definitely share everyone else's disappointment about this feature being EEP-only, though I want to add that my team is currently working around the absence of group-level issue boards by having all of our issues in a single meta-project we call "Team," instead of on the individual repos themselves. It does require the need to manually associate issues with the project they apply to (via a prefix in the title or using labels, for example), but it does allow us to see all of our work on a single board. I do consider this a workaround for missing functionality, though - not a standard use case of GitLab.

@chriseskow

It does require the need to manually associate issues with the project they apply to (via a prefix in the title or using labels, for example), but it does allow us to see all of our work on a single board. I do consider this a workaround for missing functionality, though - not a standard use case of GitLab.

Wouldn't that break mr creation from an issue?

Wouldn't that break mr creation from an issue?

Yes, it does make the green "create a merge request" button on the issue page useless. But we typically push new branches from the command line and use the create-new-merge-request-for-this-branch link that it provides in the output.

We can still reference MRs from issues and vice versa via the <repo>#<issue-id> or <repo>!<mr-id> syntax, though the editor doesn't provide auto-completion for references from different projects, unfortunately...

I'd like to add to the chorus here. My company also has a small development team (about 10). My primary reservation when we purchased EES was the lack of group issue boards, but I saw that this issue was well under way and it had not yet been tagged EEP. It was unfathomable to me at the time (and still is) that such a fundamental feature could be added to the EEP tier, because that tier is very clearly targeting large enterprise companies.

I'm very disappointed by the decision, not just because we purchased gitlab based on the notion that we'd have access to this badly needed feature, but also for what it implies about gitlab's future direction. Will the future strategy be to put a crippled version of each feature in the EES version, so that users will give up in frustration and pay for the working version in EEP?

I would really like an honest answer about the logic behind feature placement moving forward, because as others have alluded, the current decision seems to be a break from the past guidelines, and I can only assume that it is intentional.

I would really like an honest answer about the logic behind feature placement moving forward, because as others have alluded, the current decision seems to be a break from the past guidelines, and I can only assume that it is intentional.

$$$. They're viewing this as a feature that enterprise users would pay for. What's funny is, I'm pushing my enterprise towards using them but I want this feature on a personal level for my two personal projects I host locally on CE. I wouldn't even know about Gitlab if it hadn't been for the awesome CE version that they put out.

Adding another voice to the chorus. In my opinion this is MORE needed for smaller teams than larger teams even. As stated before, the smaller the team the more likely they work across different projects.

And i also wanted to add my voice that this is not only a let down but also raises doubts about where gitlab as a product and company is headed. I would also really like to get an official statement on the reasoning behind this decision and addressing the concerns voiced here.

We're currently on self-hosted, but would love to switch to GitLab.com paid plans. We're a small team, just as the others above, and group issue boards are critical to how we work (cloud native / micro-services).

Another vote for this feature on GitLab Bronze

Crickets from gitlab on this product version issue, still... Really disappointing to see zero consideration of overwhelming community feedback.

@trsmith: we have gotten some commentary, which is basically that they aren't going to change anything as it is in line with their EES/EEP policies. It's unfortunate, but understandable. Perhaps they are doing some consideration of the policies and how to adjust them without pissing off even more people. It's a tough line to walk when you have a free product and a paid product.

@JoelFeiner I can appreciate it's a challenge to segment product features, but in this case I think it's pretty clear they're making a mistake based on their current product-line stratifications. To be clear, I'm not advocating that the feature should be available at the free tier. However, there's little justification for this to be an EEP+ feature. Basic PM capabilities such as these are needed in teams of all sizes, not just teams of 500+. Looking at the roadmap, it's apparent that more basic PM capabilities will be EEP+ as well. We are an EES customer, and this direction has led us to look elsewhere for PM tools that close the feature gap more adequately and are less expensive than the jump from EES to EEP.

I've been reviewing all the plans these last few days, trying to work out what we're going to do when our current licence runs out and I'm so confused by your new options.

Silver - 19USD per user per month Gold - 99USD per user per month

The only difference? 40k extra hours of CI time ... not per user.

For our team, that's 400USD per month, per user; totalling at 4800USD per annum ... for 480k build minutes per annum.

I can spin up a DigitalOcean Droplet (3GB RAM / 2 Dedicated vCPUs or 4GB RAM / 2 Shared vCPUs), skipping your shared runners, for 480k build minutes per annum for 480USD.

Now, we're a small team. This problem gets exponentially worse for larger teams.

As September 22nd approaches and we get closer to the one feature over 300 people are waiting for, I respectfully ask that GitLab reflects on their new pricing structure and their commitment to the Cloud Native landscape and starts to appreciate that how teams work is not met by the new disparity of features and pricing.

Surprised to see this at the corporate pricing - this is really for EES, not EEP.

Don't try to look at "EES" as "folks who should upgrade to EEP", but a separate target group. If you do, please revise your plans asap.

(what is this silver and gold thing? I'm extra confused now)

At this point, it's exceedingly clear that the EEP-EES issue was decided with profit as the main motive and not the actual usefulness of the software: it shows a total lack of understanding on how software is developed outside of monolithic apps.

Or, more likely, it's just proof that VC money causes more harm than good.

I'm super ambivalent about how GitLab has handled this feature. On the one hand, I think it's a mistake to criticize a company for trying to make money. This is not a core feature for the this class of software, and they've stated this is their most requested feature. This seems like a perfect opportunity to upsell customers. Additionally, GitLab being a successful company is good for everybody. More money means more features and better support for the future, no matter which plan or license you're using.

At the same time, I work for a non-profit. Judicious allocation of resources is critical for us and the people who support us. We've used GitLab for a long time (almost since the beginning, I think). Last year we decided to upgrade to EE (now EES) for two reasons: 1) We wanted to support an open source company that had been a long-term technology partner, and 2) We knew we were going to need this feature, and it was slated to be part of EE (the version we licensed).

In the aftermath of this feature being released, I'm left feeling like I fell for a bait-and-switch.

I'm also concerned that GitLab doesn't seem to be listening to (or maybe just hearing) their community. There has been no attempt to explain what they're doing and why, or how it benefits them and their community. That's a huge warning sign for any company, but it's especially bad for an open source project. Any company that just ignores their customers/community is not headed toward a healthy place.

I'm not certain of anything right now, but I'm concerned that GitLab's focus as a company may have shifted far enough that I can no longer count on them as a technology partner.

This is nothing... Did you know that Epics #3255 (closed) are coming with a brand new EE Ultimate version? One could wonder what will the price be there and how that is going to affect EES. I don't know, the whole "Direction" document is very discouraging.

This is inline with the current roadmap which diverges hard from the way it used to be with GitLab. GitLab is going all Oracle on the licensing, and seem to go into the same false logic as them (you need 500 devs for this feature and by then you don't look at the cost).

Even though I work at a small company we still need "advanced" features. At my company only 20% of the users we currently license are actually developers that use these features.

Looking at the roadmap we need to go with Premium/Ultimate and reduce the number of users by 80%. At that point it's a specialized tool for a few select and not the hub of the organization.

Reading the roadmap was an eye-opener to me and we will apply the brakes on GitLab adoption here - which is a big personal defeat for me.

@tyldum I agree. I sadly agree.

Is there a good place to discuss the licensing strategy ? As a customer I would to participate but I don't think that this feature issue tracker is the right place

Thank you for all the comments, it's good to see such excitement for the things we build. I'm happy to address our choice for making this Enterprise Edition Premium and not Starter or CE.

As we say in our our product handbook (which is linked from our stewardship page):

EE Premium features are more relevant for organizations that have more than 750 potential users.

Many of our customers work well with large teams and many projects. Once a team is of a certain size or a certain complexity the need for group level issue boards goes from nice to have to can't live without. In this case, we felt this was more the case (hence, 'more relevant') for teams that are of potentially 750 or more people than it was 100+ people.

Now, I'm sure some of you feel that just upgrading to Enterprise Edition Premium for issue boards seems too much, when you already get so much in EES and even CE. This is where we, GitLab Inc., will have to convince you and have to continue to build great things. Because I don't believe anyone would disagree with the statement that $16.59 a month (pricing of EEP per user) for a mission-critical tool is outrageous. Ultimately, building very cool things that you think are worth paying for is what makes this boat float.

So to recap: EEP because it's more relevant for teams of potentially 750 or more people. We'll continue to build things you really want.

That all said, and as I always say: this is not unchangeable. We have and continue to persist in that we will never bring features that are free today into a paid version of GitLab, but we have a long history of doing the opposite, where we bring features tiers down or even open source them.

We will certainly continue to evaluate the case for Group level issue boards as well. Of course, we're also always listening to your feedback.

As a last point, Group level issue boards are of course free to use on public groups on GitLab.com.

@JobV, I think that a lot of posts actually advocated that this feature is more than just nice to have. From my point of view, as soon as you work with a team on more than one project this feature is a can't live without feature. Overview is lost otherwise soon. This feature, IMO, doesn't have to do anything with actual team or user size... it can help every team to build great things.

A group level issue board is relevant for any team size!

For me, the real translation to the enterprise model you're wanting is to look at this feature different. What aspect of this feature makes it actually about team size and makes it EEP worthy? My suggestion for the answer would be: the number of boards.

This could make sense to make. Smaller teams who use EES possibly won't need more than 1 to 5 global issue boards. Groups with 750+ users (and thus potential EEP users) potentially do.

I agree with above, I'm in a team of two working on a microservice architecture, this feature is a can't live without if I want to use Gitlab Issues, and it's the main reason we have to go elsewhere.

We are currently not using the issues and boards because they are on repository level, while we need to organize on a team/group level. I would argue that this feature is very relevant for the small companies and less relevant for the big ones.

The real discussion, for me, is about the future of the GitLab licensing and it might not be suited here.

As we say in our our product handbook (which is linked from our stewardship page):

EE Premium features are more relevant for organizations that have more than 750 potential users.

Many of our customers work well with large teams and many projects. Once a team is of a certain size or a certain complexity the need for group level issue boards goes from nice to have to can't live without. In this case, we felt this was more the case (hence, 'more relevant') for teams that are of potentially 750 or more people than it was 100+ people.

The cost increase of moving from Starter to Premium is extreme
There was only Community and Enterprise editions when we acquired our first license, now there is Premium and a soon to be Ultimate. And then what? This is not what we signed up for.
We have a 50 user license, but only 5 of those are developers taking full advantage of the capabilities

We use GitLab as a hub for information, not just the hardcore development. If we need to go for Premium or Ultimate we would cut our license from 50 down to 5, at which point GitLab will no longer be a hub within the organization.

I could agree to the initial split between Starter and Premium, when a larger organization needs high availability and rapid support. It was also easy to understand that the level of support we initially got for the price was not sustainable. But this is an entirely different direction.

I agree with Jogchum, this feature has more to do with the number of projects a team has rather than the number of people in the team. It would make more sense to limit the number of boards available in EES rather than omit the feature.

Licensing should not be based on feature, but more on size or usage, support etc. To my opinion there are 3 mistakes in this licensing:

Group-level Issue Boards
Environment-specific secret variables
Multi-project pipeline graphs

Why are all these 3 features bound to the highest license? Most products are seperated in a minimum of two projects (front and back). You can still be a small team or a startup company working with only 2 team members on this product.

Every product needs an overview on product (group level).
Every product has more than 1 build environment and needs secrect variables per environment
Everybody is encouraged to build micro-services and so they need the multi-project pipelines graphs

Stop putting features that everyones needs to have to the highest licensing plan, just to force them to buy that license. Rather make sure that licensing grows as the company grows. Like you do with shared runners and the minutes attached to it (that makes sense).

I agree with Jogchum, this feature has more to do with the number of projects a team has rather than the number of people in the team. It would make more sense to limit the number of boards available in EES rather than omit the feature.

We will consider this!

Thank you for the discussion and the feedback. I apologize that we cannot respond to every comment in detail, but we do seek to do our best in listening and explaining how we work as GitLab and our product strategy. If you haven't already done so, feel free to look at how we think about our separate tiers here:

One of our priorities in 10.0 was to get group-level issue boards released since it has been a feature that was highly requested (as of course all the feedback here shows). We aimed specifically to build a feature for organizations with over 750 people, as @JobV mentioned above (https://gitlab.com/gitlab-org/gitlab-ee/issues/928#note_41303556), in making this EEP. To that point, we built this feature to support multiple group boards per group, and are working now in 10.1 to even bring in saved configurations (https://gitlab.com/gitlab-org/gitlab-ee/issues/2518) to continue to serve those large organizational needs.

As many of you have noted, even smaller organizations need to view them across projects together. So we are now considering bringing a single group board per group to CE. We think this might make sense for CE users as many of you have already stated. I encourage folks to continue the conversation in this issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/38337.

Recently I am checking out Microsoft VSTS.

It seems that they provide similar feature to group level issue board as one project can have multiple git repo.

Most importantly, it's free for 5 users.

I don't want to move away from gitlab but it seems Microsoft do provide it to small team for free.

@JobV and @victorwu - we appreciate the feedback and consideration on this.

I've 'liked' a few comments, but may as well give my two cents in writing.

My small team uses a microservice architecture and EES. Group Milestones were, at first, kind of exciting - but they lack the burndown chart and issue boards that Project Milestones have. Group Milestones in their current form do not make it any easier for us to manage our product development, so we're still using an external tool.

Group Milestone burndown charts are slated to be released in EEP . This feature is in EEP. So why did Group Milestones even end up in EES in the first place? The arguments for EES vs EEP from GitLab seems to be a 'few users' vs 'many users' one. What makes Group Milestones naturally fit with 'few users', and not those other features?

Job van der Voort gitlab@mg.gitlab.com writes:

EE Premium features are more relevant for organizations that have more than 750 potential users.

Many of our customers work well with large teams and many projects. Once a team is of a certain size or a certain complexity the need for group level issue boards goes from nice to have to can't live without. In this case, we felt this was more the case (hence, 'more relevant') for teams that are of potentially 750 or more people than it was 100+ people.

So to recap: EEP because it's more relevant for teams of potentially 750 or more people. We'll continue to build things you really want.

Sorry, but this feature is 'cannot live without' for teams as small as 5 people.

If you read the comments in this issue, you will see plenty of people saying that this price structure, specifically around this particular feature, is either keeping them in another tool, or actively pushing them to another tool. I do not think that is the desired result.

@darekrusin

This is nothing... Did you know that Epics #3255 (closed) are coming with a brand new EE Ultimate version?

There is also a meta issue related to that, see #3254. It shows a roadmap to implement Portfolio Management (Scrum and advanced project planning) and it will be offered only in EEU (to be fair, advanced project planning is definitely not a EES feature). Seems for me like newly implemented group level features (Group Boards, Group Milestones, Group Burndown Charts, ...) that are part of the Portfolio Management roadmap are more likely to be heading towards EEU. Not sure how expensive EEU will be as compared to EEP but I'd love to have an option like EES + Portfolio Management as paid opt-in as we don't need most of the EEP features. But that is now going a bit too far offtopic...

@victorwu Thank you! I think that's very reasonable compromise. I know for our team, we'd be happy with one board per group (as is already the case with project-level issue boards).

I would still like to register this concern: please do not lock portions of features behind a big paywall. If you are going to have issue boards in CE or EES, then include ALL of them. Don't put arbitrary restrictions on them. And if you feel that number of users is relevant, then limit the number of boards/projects/issues/whatever based on pricing tier, rather than core functionality. While I'm happy to hear that this particular feature might come to EES, if we don't see a change to general policy, and more and more "missing puzzle pieces" get locked behind the EEP/EEU paywall, then we will take our money elsewhere. We are a small team and we don't have a lot of money to spend on a mediocre issue tracker whose main benefit is being integrated with Git hosting and CI/CD. We will look elsewhere.

@JobV I completely agree with @joggienl comment. This is a can't live without feature for us and we're an EES customer with a team of ~20.

You should stratify your paid levels based on scale/usage. As an enterprise customer, I'd expect to have access to most, if not all, of the enterprise features just at a different scale than an EEP+ customer. Give us limits if you need the up-sell levers, but still give us the tools we need to be successful and grow and we'll grow into the higher service levels.

@steissier I'm not sure if it is what you are looking for but I created #3317 as a discussion about current EE cost barriers.

/cc @charleetm @hnasarat

@JoelFeiner - Out of curiosity: What other tools exists out there that have compared functionality, same price as EES (or CE = free), and are on premise (not cloud)?

@asaf-mesika Upon considering gitlab CE for issue tracking and Kanban, my team eventually settled on using Redmine with the RedmineUp agile plugin. A bit less elegantly designed, but much more functional than the limited gitlab issue tracker.

Lack of multi-project issue boards was a major reason for discrediting gitlab for our use-case.

I understand it's hard to sustain cashflow, but treating your Free Software version as nothing more than demoware isn't great because it will anger and alienate potential customers which come as users from Free Software you create. Not sure about any specific recommendations, but I'm sure there's a better solution than what has been decided currently.

@JobV / @victorwu thank you for responding and engaging on this! I'm encouraged :).

Just weighing in on this - we are currently a tiny development team / startup looking for a lightweight agile/kanban solution that ties into our ramp up process - the lack of this feature is a DEALBREAKER for us - we maintain multiple projects and issues could tie to 1 or many of them. No telling when we will have the cashflow to afford Enterprise Premium, we could probably fit enterprise Starter into our budget now; however most of the Enterprise features we won't need or use for quite awhile, so there's no pull to do so.

So now we have to go find another tool, and should the day come when we can afford Premium, we'll probably be deep in that tool; so at least from us / teams like us you're losing money by making group issue boards premium

Just saw the @victorwu comment above, that's a perfectly good compromise! One board is all we need at this time, and I suspect we'd be ready for Premium before needing more.

Group level issue boards

Resources

Problem

Design

Designs

Child items ...

Activity

Group board

Sidebar

Filtering by project

Adding issues

Nesting issues

Issues Navigation with filters

Time reporting

Board view

Admin message

Admin message

Group level issue boards

Resources

Problem

Design

Relates to

Activity

Group board

Sidebar

Filtering by project

Adding issues

Nesting issues

Issues Navigation with filters

Time reporting

Board view