Every software system used at Gitlab(about.gitlab.com) |
Every software system used at Gitlab(about.gitlab.com) |
It has kanban, issues, epics, portfolios etc and they use comments for capturing knowledge e.g. similar to Confluence.
You can watch how they use it here: https://www.youtube.com/watch?v=wpvaqtJjXd0
GitLab, here is my proposal: remove 80~90% of this. Keep the essential. Prove that you are a really innovative company. Stop following analytics. Engage with your users.
Prove that you can control entropy and recover your agility rather than going the bureaucratic enterprise software way, just waiting for a more hungry and foolish player to cut the grass under your feet.
>I once saw Gitlab do this thing.
>Hey, Bob from Gitlab thing here. We are really trying to make thing great for our customers . Our next release of thing will do foo which we hope will fix this. Here is a link to a marketing post comparing us to GitHub. Hope that helps. Please don't mention us in a comment, or I have to do this. It hurts to live.
Can we all agree to just talk about the interesting thing that was posted, and skip the one-off customer stuff? (I predict: no.)
The billing accounts system seems to be completely disconnected from user accounts. A notification banner was spammed to users in the GitLab.com user interface, saying that our account was going to be cancelled becuase we didn't have auto-renew. The users who got the banner didn't have permission to act on it in the billing system. The billing system said that we _were_ on track to renew, which disagreed with the banner. Eventually it transpired that the end-of-year "truing up" meant that our account was on hold, but we weren't notified of this.
And when we _did_ pay the bill we get a banner saying "you've been downgraded to the free plan" when the gitlab.com interface says we hadn't.
It really undermined confidence in how well these systems are connected.
On the flip side, the fact that everything is open meant that you can see customer support reps raising internal bugs about this stuff. The principle of open-everything makes it more pallatable, but it doesn't make up for lost confidence.
* Making Gitlab.com aware of who the payment owner is so we can more accurately target the renewal banner - https://gitlab.com/gitlab-org/growth/product/-/issues/1551
* Updating the renewal banner copy for group owners that aren't payment owners so they don't attempt to renew if they do not have the right permissions - https://gitlab.com/gitlab-org/growth/product/-/issues/1553
* Moving the renewal behavior from the customers portal into Gitlab.com so payment owners can more easily manage their subscription and renewal - https://gitlab.com/gitlab-org/growth/product/-/issues/1528
* Adjusting how we do "true-ups" so they are done quarterly and pro-rated to the end of the subscription instead of in arrears - https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/...
I would love to chat with you to learn more about the challenges you experienced and to review some of our plans to make things better if you're up for it. You can reach me directly at mkarampalas[at]gitlab.com
0. https://gitlab.com/gitlab-org/gitlab/-/issues/3320#note_3351... 1. https://about.gitlab.com/handbook/ceo/pricing/#reporter-user...
But that said, I do wholeheartedly agree! The top-tier account type allows free reporter-level users. But for every other tier (e.g. silver), you have to pay for them. I think that's big mistake, as the cost-benefit of paying 200 USD per year for each member leads to work-arounds, which compromises the user experience.
I suppose they're not particularly top secret but there could be a version that has some more sensitive data and this is a safe derivative for example. Similarly, such an asset register would likely have non-technical assets as well while this just seems to be tangible, technical things?
I figure any large company with a risk management function will already have/need such a spreadsheet (or document), complete with some sort of data classifications to exist for auditing reasons so the interesting step is maintaining it out in the public.
Kudos to Gitlab for having the culture to allow this sort of stuff :)
I’m seeing if we can move the sheet to the handbook and integrate the app into GitLab itself.
Once you choose your infrastructure, you might as well go all in. Just look at their dependence on SalesForce.
If you're looking for a shiny pretty interface for all your users, then Gitea can serve the same purpose. Personally, I find cgit to look fine too. I think GitLab simply tries to do too much, and they've built their entire app on a poorly scalable and bloated tech stack.
I think SourceHut probably provides the best platform for teaching developers a more native way to use Git that provides most of the same features as GitLab. For CI/CD there are so many better options outside of GitLab that integrate into Kubernetes and you won't regret it.
And surely customers should be the centre of everyone's business.
Its a bit hard to imagine, just like SAP software (for me), since all your experience is on industries far from that world.
I know there's the whole build-vs-buy debate, but with the cost of Salesforce, might it not be better to just stick everything in a database and throw a MySQL WYSIWYG tool like phpmyadmin in front in order to let non-engineers see the schema and build forms?
I suppose if you're earning money hand over fist (or keep getting VC funds) then the cost of your Salesforce license doesn't matter. But I bet that hurts. And unlike a lot of the other software in use, Salesforce comes with steep lock-in.
What I’d struggle to give up is the ease of reporting. Xero’s report designer is right in my sweet spot for usability, flexibility, and domain-specific correctness, probably my favourite reporting tool in three decades of shaking down business software.
We listened to the lesson and the architecture we designed ended up not having Salesforce as a dependency for any critical or money producing customer facing functionality.
We used Alteryx as a ETL tool to keep Salesforce in sync in almost real time. The customer facing sites and services ran off their independent databases. This also meant that the developers working on that didn't need to know the details about how Salesforce worked, we just mapped Salesforce data to their database.
Does anybody know some other companies that have their business stack available?
This is very valuable to me as a Linux user in a Microsoft Platinum partner org because I can't run Visio natively.
And adding a new system is a pretty big deal at a large company so keeping it up to date isn't that difficult.
It’s a basic text only structure so it actually diffs pretty well so I can see a merge request with a new node or new relationship.
Those with kids, I know that it can be even more challenging or exhausting. so in some ways "unaffected" in others "feeling it". Pretty much like everyone else.
I can't comment specifics on finances, but I do count my lucky stars that GitLab raised when it did as it personally gives me a little more reassurance that we may be less affected. That said, obvs anything can happen to me or GitLab.
And it's because (a) most developers aren't exposed to non-Engineering parts of the company so they have no understanding of what problem to solve and (b) it is incredibly lucrative to build a proprietary SaaS solution.
There is https://erpnext.com/ which is completely FOSS built on Frappe framework. If anything, it is rather higher quality than most SASS solutions out there.
Thanks for the comment.
Indeed that is something we've had in our minds for a long time. Over the past months/years, we have been shipping out incremental improvements in the way we handle and render large MR diffs.
Recently we made the loading happen in batches which resulted in a significant improvement in how fast we start showing the diffs. https://gitlab.com/groups/gitlab-org/-/epics/1816
We plan to continue improving the performance of the MR page, lowering memory footprint this Q2 as well as providing other ways to enhance the experience.
Some examples:
* Commit navigation, to help commit by commit review: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28596
* File by file mode of reviewing MRs, including the concept of "unread diffs": https://gitlab.com/groups/gitlab-org/-/epics/516
We're constantly looking to improve and learn more about the struggles of our users. If you have further thoughts, please drop a comment in one of the issues and epics above and tag me (@andr3).
If some of your problems are not covered by these, feel free to open an issue (https://gitlab.com/gitlab-org/gitlab) and tag me as well.
Again, thanks for the feedback.
OH MY GOD this so much. This one specific anti-feature has no doubt caused countless bugs to be missed during code review. I can quote the issue thread by memory at this point i've revisited it so many times the last year(s?)
For goodness sake, if the trade off is between 'seeing all of the changes during the review' vs 'having the page load quickly', the only people who choose 'quickly' are those who haven't been burned by human error missing a collapsed diff. Gitlab made the wrong trade off here in good/fast/cheap triangle.
document.querySelectorAll('.js-file-title').forEach(t => t.click());
document.querySelectorAll('.diff-content').forEach(d => d.style.display="block");
document.querySelectorAll('.nothing-here-block').forEach(d => d.style.display="none");Such large PRs would also probably benefit from live discussions over video (or in the good old days -- in person).
Personally, I would kill for a one click to step review interface in IntelliJ that synced comments back to the review.
I still think the merge request UI is great. Its main problems are its slowness and the fact that files with a long diff are collapsed. As the full merge request is quite slow, I will usually open the diff of each commit one by one, then put review comments as a "per commit" basis.
I've left a few replies in this thread already with more detail of work we have done, is currently in flight and work that is planned to keep improving the overall situation.
As to the "per commit" review, we're working on something to make this navigation easier and easier and shipping it very soon. https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28596
As to the collapsed, unfortunately if we loaded all diff lines expanded, the large changesets would make the browser unusable. We're working to lower the memory footprint and have better ways to deal with these large MRs.
One example I can leave you with that we're trying to figure out a way to make this useful as an additional option, is this: * File by file mode of reviewing MRs, including the concept of "unread diffs": https://gitlab.com/groups/gitlab-org/-/epics/516
We're aware of several of the pain points (we use GitLab to build GitLab ;) ), but if you have further feedback, please leave a comment in the issues and epics I've left here (or create new ones) and feel free to tag me @andr3.
Thanks!
For leaving comments, pretty much every system I’ve used has issues. At work we use phabricator; the default settings are atrocious but they can be tuned to something workable.
I sometimes wonder how hard it would be to get diff reviews to be a first (or even second) class citizen of the git ecosystem. That way you can finally get the bliss of leaving review comments in the IDE. They already have “notes” which are vaguely similar, maybe it’s something they’re considering?
This is on our horizon. We have an Epic to track an overall revamp and adding an option to review file-by-file which will include developing something like what you just described.
Epic: https://gitlab.com/groups/gitlab-org/-/epics/516
Issue for the checking of file seen (including the concept of "unread diffs"): https://gitlab.com/gitlab-org/gitlab/-/issues/24629
If you could please add your thoughts in that issue, we could use that feedback while we develop the feature.
Thanks a bunch for caring and voicing your concerns. It helps us get better.
You also get to a point in hiring where the field of sales/ops people judge you & your maturity based on whether you use a commercial tool like Salesforce/HubSpot vs build your own.
Can you imagine joining a tech org and they have a half baked phpadmin wysiwyg as a standin for github + code reviews?
While yes, you could calculate out how much the subscription is vs development time to build a simple CRM, the maintenance & mental overload is righteously terrible. Better to spend that effort integrating your foos to your bars than building a sales crm.
While I don't work on the product (directly) or speak in any official capacity, I can definitely route your pain points and compliments to the respective teams internally :)
They might have some good conceptual ideas, but the implementation is horrific, their ops/delivery infrastructure a shitshow if even there's one, bugs all over the place and a product management that basically says yes to everything and finishes nothing.
They are in part victims of their own success, but just look at their Github issues page.
https://www.acquia.com/about-us/newsroom/press-releases/acqu...
If you're referring to git-notes, they are ... kinda special. They are objects in their own namespace that reference the repository objects the notes themselves are attached to.
Sure enough, you can attach a note to any git-object. And you can view them either directly or from the git-log view. But the discoverability is lacking, and the UI of doing pretty much anything with git-notes is absolutely atrocious. Because they are in their own namespace, you don't automatically get them when you do a pull or fetch, which can get pretty confusing.
For the curious ones, the magic invocation needed to pull in updates to notes from the remote repo is:
git fetch origin +refs/notes/*:refs/notes/*
So from where I'm looking at things, git-notes are not suitable for plumbing in a code review flow.
I was meaning to point out that we've developed plumbing for objects with "weaker" guarantees than source code, which can still be attached to refs. To me, this is indicative that the maintainers are willing to accept patches on things that are outside the "core mission" of versioning source code, and might mean that they're open to the idea of accepting a well-architected code review feature.
Although, you're also right, in that there's still a lot of plumbing to make sure that authors can only edit their own comments, and that sort of thing. The more I think about it, there's a lot of work to be done and it isn't easy.
But, if you made a proposal, I think git-notes is precedent for them accepting your contributions. :)
If you mean the "collapsing" feature, this is really not equivalent, since the state does not persist between multiple review sessions.