[nisa]

They just don't seem to care. You research something - after hours you'll end up at their bugtracker, where you can read the desperation of others (often some issues are not fixed in 10+ years). I don't understand their priorities. There is to date still no way to restrict visibility of work-logs on issues - a usecase basically every smaller shop has because the client is often participating directly in the JIRA. Service Desk solves that problem but it's quite expensive and you can't mix software projects with service desk projects. So you have to create linked-issues and have yet another layer of indirection :/

We end up syncing projects with another plugin on the same instance :/

Confluence lacking some robust text-only markup (like markdown or asciidoc or whatever) is also more than lame. It shouldn't be that hard because most macros can be configured by text attributes anyway... Expose that Wiki in a readable markdown format and have me let git... like github gist would be more than enough. I despise using Confluence at the moment...

Gitlab could eat their lunch but they also seem to have their priorities off

[sytse]

You mean we're not going after Confluence or JIRA?

Wikis are certainly not a priority for us. I think if you don't separate the proposer from the person who accepts the proposal the wiki tends to grow stale. So we're betting on static websites with GitLab Pages.

There is a large market for wikis but you would have to use something easier than markdown, which is hard for us to get away from.

We're going after JIRA. In GitLab you can have a service desk on a project with an issue tracker. Do we solve the work-log issue too?

[nisa]

Ohh, I really have to stop making snarky comments here :)

So I actually looked at migrating to Gitlab due our JIRA pains but it's not really possible if you have some already grown setup (it's not exactly easy to solve so no blame to Gitlab here)

- no JIRA import (it's possible with some REST-API fighting), but something easy would be nice: https://gitlab.com/gitlab-org/gitlab-ee/issues/2780

- The work-log issue is not solved as far as I understood the documentation, it's possible to have external users to hide internal projects but once you are on a project time-tracking information is visible.

- From a quick glance over the docs it looks like reporting on tracked time is also not possible out of the box - and probably not across projects - we use Tempo Timesheets on JIRA for that, the slash commands /spend /estimate are probably okay for devs but we also have other users that can deal with the fields in JIRA.

- It looks like the whole custom fields on issues is still in the works (we use that quite heavily) and there is no concept of workflows (we also have some custom setup there)

- Servicedesk looks neat through.

Don't get me wrong - this reads like: I want all JIRA features in Gitlab - maybe that's a stupid idea, for a new project I'd probably just use Gitlab and see how are I come.

[victorwu]

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

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

[smcg-gitlab]

Hello! I'm an engineering manager working on the Plan stage at GitLab, which covers all the areas you're mentioning here.

> if you have some already grown setup (it's not exactly easy to solve so no blame to Gitlab here)

Thanks :-) We do intend to offer a good solution here, so these are valuable points.

> - no JIRA import (it's possible with some REST-API fighting), but something easy would be nice: https://gitlab.com/gitlab-org/gitlab-ee/issues/2780

We added a very basic issues import from a CSV file recently (https://docs.gitlab.com/ee/user/project/issues/csv_import.ht...), as a sort of basic MVC of this.

I've asked the product manager in the issue you linked if we're considering this in the medium term.

> - The work-log issue is not solved as far as I understood the documentation, it's possible to have external users to hide internal projects but once you are on a project time-tracking information is visible.

That's correct. We have https://gitlab.com/gitlab-org/gitlab-ce/issues/27204 open for this if you'd like to contribute there, or even just add a thumbs-up emoji.

> - From a quick glance over the docs it looks like reporting on tracked time is also not possible out of the box - and probably not across projects - we use Tempo Timesheets on JIRA for that, the slash commands /spend /estimate are probably okay for devs but we also have other users that can deal with the fields in JIRA.

Also correct! We have https://gitlab.com/gitlab-org/gitlab-ce/issues/54118 and https://gitlab.com/gitlab-org/gitlab-ee/issues/3803 open for this, but I'm not sure if either exactly meets your needs. Feel free to open a new issue and ping me (@smcgivern on GitLab) if they don't.

> - It looks like the whole custom fields on issues is still in the works (we use that quite heavily) and there is no concept of workflows (we also have some custom setup there)

For workflows you can see https://gitlab.com/gitlab-org/gitlab-ee/issues/2059 and specifically https://gitlab.com/gitlab-org/gitlab-ee/issues/2059#note_148.... We do intend to cover this area, we're just quite there yet.

[jbergstroem]

At my clients, they swear by jira workflows (that's the name, right?). The mindset of "customize everything" seems to be impossible to impact. A strong second is managerial heaven plugins with unlimited ways of clicking and visualizing other peoples clicks. Not sure how to compete with that; it's basically disagreeing about the curvature of the earth.

[applecrazy]

The service desk feature is nice, but maybe having a form for people to fill out to file a support request would be even better. That way, people can file requests without directly opening their email client.

Just a small thought :)

[victorwu]

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

[mansilladev]

Jira Service Desk does come with a portal and forms to create requests (in addition to supporting email).

[applecrazy]

I was talking about Gitlab Service Desk.

[jedberg]

> Confluence lacking some robust text-only markup (like markdown or asciidoc or whatever)

The really irony here is that it used to have that! That was the only way I edited Confluence docs back in 2012 (and before) until they took the feature away. For a while you could dig into it, but pretty much any change you made not using the WYSIWYG editor broke the whole page.

[keithnz]

I think the real irony for me is a company that promotes software development tools and agile software development seems to not do it. Things that were working break in production, so clearly no intergration/regression testing (if this happened as an oops! once in a while I wouldn't mind so much ), and they are not working at a sustainble pace. Very hard for them to keep their product rock solid, then intoduce new things, and keep it all rocksolid, and they seem to not mind.... my guess is some kind of classic management probem where given 2 of the following 3 choices :- quality, time, features.... manamgent choose features and time but pay lip service that they should maintain quality, it's not a first class concept at a management level, just a detail that the devs somehow have to deal with because they really want features by a certain time.

[dillera]

I still run the Confluence 3.5 version (off the open net). The WYSIWYG runined Confy. It's an awesome, easy, fast wiki if you just stay at 3.5. And you edit it all in text.

[naringas]

> I don't understand their priorities.

enterprise sales contracts

[rmk2]

There is a "suggestion" somewhere that asked them to implement service accounts for API access. They essentially replied with "this is a good idea and we should do this". That post was from 2012 or so, and we still don't have service accounts.

[emmelaich]

I'm not sure whether you'd prefer the alternative -- to not publish feature and bugfix requests. Like many other companies do.

Atlassian should be congratulated for being open!