It's not dataloss but it deletes text in the same line as wiki internal links. And what kind of wiki doesn't use lots of internal links. https://gitlab.com/gitlab-org/gitlab-ce/issues/67132 This basically makes the wiki unusable but it's marked as "backlog".

If you really do feel this way about the wiki then it should be clearly marked in your marketing. I read about your "integrated devops experience" and was onboard, but if your intent is as you say then you need to put parentheses next to the wiki feature item list that says "this is crap and we intend for it to stay crap" and we'll know to value it appropriately when choosing a provider.

I'm surprised that this wiki bug that two people here mention has only one upvote https://gitlab.com/gitlab-org/gitlab-ce/issues/48641 I'm not sure if the complaints are over multiple issues, if the wiki doesn't get a lot of usage, or something else is going on. The bug sounds legitimate.

Hi! I'm the current PM for our wiki's and I agree that the experience isn't up to par at the moment. As Sid mentioned, historically wiki's were not a priority as many users weren't coming to GitLab for those features. We're starting to see shifts in that thinking as we've penetrated deeper in to some markets so we're working to adjust accordingly.

> It's not dataloss but it deletes text in the same line as wiki internal links. And what kind of wiki doesn't use lots of internal links. https://gitlab.com/gitlab-org/gitlab-ce/issues/67132 This basically makes the wiki unusable but it's marked as "backlog".

That issue is interesting because it's a link mechanism that relies on the underlying wiki project that we use. (i.e. that's no common markdown syntax). Discoverability of things like that is limited to some power users who know that we're using Gollum underneath and know of some of the supported syntax. What we've seen is that most users don't use that functionality and instead just use absolute links in markdown. This likely explains why the upvotes are so low on the bug report as well.

For comparison, we've seen more demand to support linking to projects: https://gitlab.com/gitlab-org/gitlab-ce/issues/20726, than within the wiki itself.

As an FYI, I've also asked a couple of our engineers to take a look at that specific issue to see if it's something that can be relatively easy to fix. No guarantees on anything here, but we'll try to get a bit more relevant engineering information to assist in understanding scope.

> If you really do feel this way about the wiki then it should be clearly marked in your marketing.

That's a lot of what our maturity pages are trying to do. We're being honest with ourselves and with our users about where we think the functionality of certain features are. In fact, when I started we had the Wiki listed at a `Complete` maturity which I reduced to viable: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/...

If you take a look at the wiki strategy (https://about.gitlab.com/direction/create/wiki/) our next focus is going to be on making editing easier and improving navigation. We think these things will start to move the conversation forward for users and we'll see more adoption.

Even more, if you think we're not moving in the right direction with the Wiki's please be vocal on the issue tracker, or open an issue for the Wiki Strategy or even a merge request to change something. We're happy to have the feedback, and don't hesitate to tag me on wiki issues I'm @phikai on GitLab as well.

But anyway the double brackets is not a Gollum feature. It's a wiki thing, going back to wikipedia.

Since you're here I think this issue is also misprioritized: https://gitlab.com/gitlab-org/gitlab-ce/issues/66898 You should reconsider as a lot of integrations rely on webhooks and broken images make the whole thing impossible.

That's fair, the point was that it's syntax specific to the wiki system vs. the rest of our markdown filters.

> Since you're here I think this issue is also misprioritized: https://gitlab.com/gitlab-org/gitlab-ce/issues/66898 You should reconsider as a lot of integrations rely on webhooks and broken images make the whole thing impossible.

I'll take a look at this - it popped on to my radar recently but I need to dig in further to understand the use case and functionality here. Thanks for bringing it up.

I work for a GitLab shop, but we don't use the bugtracker (Jira) or wiki (Confluence), we mostly don't use the CI (Jenkins is just more flexible), and we definitely don't use the container stuff. We currently do use the review workflow but at various points have considered moving to a different tool for that as well.

So yeah, we would have been fine with a GitLab that did less— a lot less, and instead prioritized supplying first class integration points and supported plugins for other best-in-class tools.

If they did this I wouldn’t want to use it any more. The whole point of Gitlab is that it does everything. To prevent the need for any integrations.

Removing features and making them into extensions, would be a different thing.

GitLab then introduced another way of specifying dependencies using the keyword "needs" ("dependencies" was already taken by the half-baked implementation). This allows jobs from multiple stages to run concurrently, as you would expect. However, you are still required to shoehorn your jobs into stages, even though they should be completely deprecated by now. Worse, the restriction that jobs cannot depend on other jobs from the same stage still remains. On top of that, the visualization of a pipeline pretends that the new way of specifying dependencies does not exist, so all the arrows between the jobs are meaningless.

I would much rather have had a proper implementation of the simple, more general approach, than having to deal with the legacy of a hacky and half-baked solution.

The items you mention are scheduled for follow-ups in our epic https://gitlab.com/groups/gitlab-org/-/epics/1716. Your feedback on sequencing or how we are approaching the different improvements is more than welcome.

I would have loved for the feature to be useful for you too in the MVC iteration, and I'm sorry it wasn't. We are still working on it, though, and I hope that it does become valuable for you also. In the meantime you should still be able to use GitLab in the same way you always have - let me know if you're having trouble running pipelines without the DAG.

Also, this is just a single example that I pointed out to outline what I think is a problem with the whole development culture around GitLab, which puts too much focus on releasing early, and too little focus on quality assurance. Of course, you shouldn't spend years perfecting the next release, but you release too many features too early for my taste.

Releasing early to get feedback on issues is important to us but we can do better communicating around what's an early preview vs. a mature feature. The maturity page that's linked to in this discussion is actually part of how we are trying to improve our communication around that. This is more at the stage and category level, but features have a maturity level as well and it's worth us reflecting on how that can be made more clear.

In the DAG model (which really is just the model implemented by every sane build tool ever made), stages give you no extra expressive power, they only add arbitrary restrictions to that model and aren't useful at all.

As per your second point, and this is speaking personally and not really officially, I do think our feature goal has been historically a bit too ambitious (although hopefully transparently so: https://about.gitlab.com/company/strategy/#breadth-over-dept...) seeing as how we're barely out of the startup phase. But we have had a big hiring push this year and have almost tripled our headcount (which did introduce growing pains of it's own lol). Once we've stablilized a bit, we will be able to dedicate more resources solely on maturing features.

I hope this doesn't come across like making excuses, these are just my observations as a user-turned-employee. I will take your feedback about not being heard into consideration though so we can improve on that!

The point of the GP and others where that as of now there is nothing positive about the "unified experience for DevOps", it is very buggy and lacking, maybe someday.

Because _if_ I feel like the feature might be useful, I'm going to try to use it, and invest time in trying to use it, and only then find that it's not reliable or well-polished after all. The more such features there are, the more chance I'll spend at least some time being frustrated by at least one of them.

One of the joys of really well-polished software is that if the feature wasn't worth doing right (and not every feature is!), it simply isn't there at all, so if a feature is there I can count on it being well-thought-out and well-executed.

That may be because people who do care use a different product. Be careful you don't metric your way to extinction.