john_cogs

The intent of the redesign is for the logo to reflect GitLab's place at the center of the DevOps infinity loop.

The GitLab logo/mascot is actually a tanuki, a Japanese racoon dog. It symbolizes our values as a smart animal that works in a group to achieve a common goal.

GitLab team member here.

You may want to check out (and sign up as a beta tester) for Cloud Seed, an open-source program led by GitLab Incubation Engineering in collaboration with Google Cloud: https://hello.cloudseed.app/

Hostile takeover is an investment term.

When you attempt to buy a company without the board’s consent, it is considered a hostile takeover.

In looking at the Founder Advisory board, I was surprised that all of these companies have dedicated roles/teams focused on climate/sustainability.

Very cool to see and hopefully a sign there will be more leadership on climate coming from the business community.

GitLab team member here. Thanks for sharing.

Assuming positive intent works well outside of professional settings, too.

Bringing this mindset to relationships with significant others, family members, friends, and people in my community has proven to improve those relationships.

Sorry to hear about this experience. I’d love to find out what happened and renew the license for your project. Feel free to email me jcoghlan at gitlab and I’ll be happy to help.

The requirements to join the GitLab for Open Source program can be found here: https://about.gitlab.com/solutions/open-source/join/#require...

They are:

- OSI-approved open source license: All of the code you host in this GitLab group must be published under OSI-approved open source licenses

- Not seeking profit: Your organization must not seek to make a profit through services or by charging for higher tiers. Accepting donations to sustain your efforts is ok. Read more about this requirement here: https://about.gitlab.com/handbook/marketing/community-relati...

- Publicly visible: Your GitLab.com group or self-managed instance and your source code must be publicly visible and publicly available.

GitLab's discretion means that we review applicants to ensure they meet these criteria and do not violate our CoC. The renewal helps us to ensure that our program members continue to meet these criteria.

GitLab team member here. Yes, you are correct.

We count the unique sum of users within a namespace which includes the users in the parent namespace (group), subgroups, and projects.

I created an MR to update the FAQ to make this more clear: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

Thanks for the feedback.

GitLab team member here.

Selecting our MVP this month was tough! In addition to the MVP winner, other great community contributions in this release include:

- A shortcut to open related issue

- Support for Java 17 in Dependency Scanning

- A new API to allow users to enable or disable the Security & Compliance menu

- Notifications for new PATs and email addresses

- Review previously merged commits in merge requests

- Create Persistent Volumes by specifying the persistence keyword in the configuration file

GitLab has an All-Remote Guide that might be helpful to you and your team: https://about.gitlab.com/company/culture/all-remote/guide/

Hey, GitLab team member here. In the post, the author mentions boring solutions. This is actually one of our subvalues at GitLab. You can read more about them here: https://about.gitlab.com/handbook/values/#boring-solutions

The color is green because GitLab.com is accessible again.

"Active Incident" remains because our team is still working towards full recovery.

"System Wide Outage" is the description of the incident at its onset.

Your impression is correct. We use GitLab.com and notice these incidents as they happen.

The delay in updating status is a result of our Incident Management process [0]. We have a Communications Manager on Call (CMOC) who leads communication throughout an incident. One of their responsibilities includes updating the status page. The slight delay between noticing the issue and updating the status page is a result of the time it takes for the CMOC to get alerted, assess the situation, and write the communication that is shared on the status page.

I'm not sure how the "updated a few seconds ago" messages are generated but I'll try to find out once the incident has been resolved.

0 - https://about.gitlab.com/handbook/engineering/infrastructure...

GitLab team member here. We're aware of the incident and the status page has been updated. We will provide further updates on the status page as they become available.

(Edited now that the status page has been updated).

Hey there, GitLab Dev Evangelist here. Thank you for flagging this and for the suggestion.

A change based on your comment was merged earlier today (with a link to your comment in the description): https://gitlab.com/gitlab-org/gitlab/-/merge_requests/78933

While we regularly discuss this as a team, it was not documented. You are right that it should be so I opened an MR (which also links back to and quotes your comment): https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

Thanks for the great feedback.

Thanks for your interest.

Given we are so transparent, it seems that most folks who conduct interviews at GitLab expect candidates to have done a fair bit of research in advance of the interviews. So if you're looking to join the Developer Evangelism team, brushing up on our handbook and familiarizing yourself with what we do would be a good idea. That will allow you to come to the interview prepared to frame your experience and abilities through the lens of how we work and the results we aim to deliver to GitLab and our community.

We share details on the process in our handbook: https://about.gitlab.com/handbook/hiring/interviewing

Your point about timing is a good one (and was also something Dan mentioned in his presentation yesterday) so I created an MR to add it to the page: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

Thanks for the suggestion. I created an MR to add a slightly edited version to the "Best Practices" section of the page: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

Good point. MR to add the offical HN links: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

To reach there, your comment must include either "gitlab" or "devops platform".

On it: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

Thanks, I’ve shared this feedback with members of our support team.

Good suggestion. Thanks. I documented it here: https://gitlab.com/gitlab-com/marketing/corporate_marketing/...

There is: https://about.gitlab.com/handbook/marketing/inbound-marketin...

blog.gitLab.com will redirect you to the GitLab blog.

Definitely not.

Thanks.

Many of the posts that reach the front page are simply posts that contain GitLab in the URL (ex: a link to an issue from an open source project hosted on GitLab). Others are only relevant to specific teams. My team handles directing the posts to the right folks to avoid unnecessary distractions from “false positives”.