[{"data":1,"prerenderedAt":1853},["ShallowReactive",2],{"/en-us/blog/tags/contributors/":3,"navigation-en-us":19,"banner-en-us":437,"footer-en-us":452,"contributors-tag-page-en-us":663},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"content":8,"config":10,"_id":12,"_type":13,"title":14,"_source":15,"_file":16,"_stem":17,"_extension":18},"/en-us/blog/tags/contributors","tags",false,"",{"tag":9,"tagSlug":9},"contributors",{"template":11},"BlogTag","content:en-us:blog:tags:contributors.yml","yaml","Contributors","content","en-us/blog/tags/contributors.yml","en-us/blog/tags/contributors","yml",{"_path":20,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"data":22,"_id":433,"_type":13,"title":434,"_source":15,"_file":435,"_stem":436,"_extension":18},"/shared/en-us/main-navigation","en-us",{"logo":23,"freeTrial":28,"sales":33,"login":38,"items":43,"search":374,"minimal":405,"duo":424},{"config":24},{"href":25,"dataGaName":26,"dataGaLocation":27},"/","gitlab logo","header",{"text":29,"config":30},"Get free trial",{"href":31,"dataGaName":32,"dataGaLocation":27},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":34,"config":35},"Talk to sales",{"href":36,"dataGaName":37,"dataGaLocation":27},"/sales/","sales",{"text":39,"config":40},"Sign in",{"href":41,"dataGaName":42,"dataGaLocation":27},"https://gitlab.com/users/sign_in/","sign in",[44,88,184,189,295,355],{"text":45,"config":46,"cards":48,"footer":71},"Platform",{"dataNavLevelOne":47},"platform",[49,55,63],{"title":45,"description":50,"link":51},"The most comprehensive AI-powered DevSecOps Platform",{"text":52,"config":53},"Explore our Platform",{"href":54,"dataGaName":47,"dataGaLocation":27},"/platform/",{"title":56,"description":57,"link":58},"GitLab Duo (AI)","Build software faster with AI at every stage of development",{"text":59,"config":60},"Meet GitLab Duo",{"href":61,"dataGaName":62,"dataGaLocation":27},"/gitlab-duo/","gitlab duo ai",{"title":64,"description":65,"link":66},"Why GitLab","10 reasons why Enterprises choose GitLab",{"text":67,"config":68},"Learn more",{"href":69,"dataGaName":70,"dataGaLocation":27},"/why-gitlab/","why gitlab",{"title":72,"items":73},"Get started with",[74,79,84],{"text":75,"config":76},"Platform Engineering",{"href":77,"dataGaName":78,"dataGaLocation":27},"/solutions/platform-engineering/","platform engineering",{"text":80,"config":81},"Developer Experience",{"href":82,"dataGaName":83,"dataGaLocation":27},"/developer-experience/","Developer experience",{"text":85,"config":86},"MLOps",{"href":87,"dataGaName":85,"dataGaLocation":27},"/topics/devops/the-role-of-ai-in-devops/",{"text":89,"left":90,"config":91,"link":93,"lists":97,"footer":166},"Product",true,{"dataNavLevelOne":92},"solutions",{"text":94,"config":95},"View all Solutions",{"href":96,"dataGaName":92,"dataGaLocation":27},"/solutions/",[98,123,145],{"title":99,"description":100,"link":101,"items":106},"Automation","CI/CD and automation to accelerate deployment",{"config":102},{"icon":103,"href":104,"dataGaName":105,"dataGaLocation":27},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[107,111,115,119],{"text":108,"config":109},"CI/CD",{"href":110,"dataGaLocation":27,"dataGaName":108},"/solutions/continuous-integration/",{"text":112,"config":113},"AI-Assisted Development",{"href":61,"dataGaLocation":27,"dataGaName":114},"AI assisted development",{"text":116,"config":117},"Source Code Management",{"href":118,"dataGaLocation":27,"dataGaName":116},"/solutions/source-code-management/",{"text":120,"config":121},"Automated Software Delivery",{"href":104,"dataGaLocation":27,"dataGaName":122},"Automated software delivery",{"title":124,"description":125,"link":126,"items":131},"Security","Deliver code faster without compromising security",{"config":127},{"href":128,"dataGaName":129,"dataGaLocation":27,"icon":130},"/solutions/security-compliance/","security and compliance","ShieldCheckLight",[132,135,140],{"text":133,"config":134},"Security & Compliance",{"href":128,"dataGaLocation":27,"dataGaName":133},{"text":136,"config":137},"Software Supply Chain Security",{"href":138,"dataGaLocation":27,"dataGaName":139},"/solutions/supply-chain/","Software supply chain security",{"text":141,"config":142},"Compliance & Governance",{"href":143,"dataGaLocation":27,"dataGaName":144},"/solutions/continuous-software-compliance/","Compliance and governance",{"title":146,"link":147,"items":152},"Measurement",{"config":148},{"icon":149,"href":150,"dataGaName":151,"dataGaLocation":27},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[153,157,161],{"text":154,"config":155},"Visibility & Measurement",{"href":150,"dataGaLocation":27,"dataGaName":156},"Visibility and Measurement",{"text":158,"config":159},"Value Stream Management",{"href":160,"dataGaLocation":27,"dataGaName":158},"/solutions/value-stream-management/",{"text":162,"config":163},"Analytics & Insights",{"href":164,"dataGaLocation":27,"dataGaName":165},"/solutions/analytics-and-insights/","Analytics and insights",{"title":167,"items":168},"GitLab for",[169,174,179],{"text":170,"config":171},"Enterprise",{"href":172,"dataGaLocation":27,"dataGaName":173},"/enterprise/","enterprise",{"text":175,"config":176},"Small Business",{"href":177,"dataGaLocation":27,"dataGaName":178},"/small-business/","small business",{"text":180,"config":181},"Public Sector",{"href":182,"dataGaLocation":27,"dataGaName":183},"/solutions/public-sector/","public sector",{"text":185,"config":186},"Pricing",{"href":187,"dataGaName":188,"dataGaLocation":27,"dataNavLevelOne":188},"/pricing/","pricing",{"text":190,"config":191,"link":193,"lists":197,"feature":282},"Resources",{"dataNavLevelOne":192},"resources",{"text":194,"config":195},"View all resources",{"href":196,"dataGaName":192,"dataGaLocation":27},"/resources/",[198,231,254],{"title":199,"items":200},"Getting started",[201,206,211,216,221,226],{"text":202,"config":203},"Install",{"href":204,"dataGaName":205,"dataGaLocation":27},"/install/","install",{"text":207,"config":208},"Quick start guides",{"href":209,"dataGaName":210,"dataGaLocation":27},"/get-started/","quick setup checklists",{"text":212,"config":213},"Learn",{"href":214,"dataGaLocation":27,"dataGaName":215},"https://university.gitlab.com/","learn",{"text":217,"config":218},"Product documentation",{"href":219,"dataGaName":220,"dataGaLocation":27},"https://docs.gitlab.com/","product documentation",{"text":222,"config":223},"Best practice videos",{"href":224,"dataGaName":225,"dataGaLocation":27},"/getting-started-videos/","best practice videos",{"text":227,"config":228},"Integrations",{"href":229,"dataGaName":230,"dataGaLocation":27},"/integrations/","integrations",{"title":232,"items":233},"Discover",[234,239,244,249],{"text":235,"config":236},"Customer success stories",{"href":237,"dataGaName":238,"dataGaLocation":27},"/customers/","customer success stories",{"text":240,"config":241},"Blog",{"href":242,"dataGaName":243,"dataGaLocation":27},"/blog/","blog",{"text":245,"config":246},"Remote",{"href":247,"dataGaName":248,"dataGaLocation":27},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":250,"config":251},"TeamOps",{"href":252,"dataGaName":253,"dataGaLocation":27},"/teamops/","teamops",{"title":255,"items":256},"Connect",[257,262,267,272,277],{"text":258,"config":259},"GitLab Services",{"href":260,"dataGaName":261,"dataGaLocation":27},"/services/","services",{"text":263,"config":264},"Community",{"href":265,"dataGaName":266,"dataGaLocation":27},"/community/","community",{"text":268,"config":269},"Forum",{"href":270,"dataGaName":271,"dataGaLocation":27},"https://forum.gitlab.com/","forum",{"text":273,"config":274},"Events",{"href":275,"dataGaName":276,"dataGaLocation":27},"/events/","events",{"text":278,"config":279},"Partners",{"href":280,"dataGaName":281,"dataGaLocation":27},"/partners/","partners",{"backgroundColor":283,"textColor":284,"text":285,"image":286,"link":290},"#2f2a6b","#fff","Insights for the future of software development",{"altText":287,"config":288},"the source promo card",{"src":289},"/images/navigation/the-source-promo-card.svg",{"text":291,"config":292},"Read the latest",{"href":293,"dataGaName":294,"dataGaLocation":27},"/the-source/","the source",{"text":296,"config":297,"lists":299},"Company",{"dataNavLevelOne":298},"company",[300],{"items":301},[302,307,313,315,320,325,330,335,340,345,350],{"text":303,"config":304},"About",{"href":305,"dataGaName":306,"dataGaLocation":27},"/company/","about",{"text":308,"config":309,"footerGa":312},"Jobs",{"href":310,"dataGaName":311,"dataGaLocation":27},"/jobs/","jobs",{"dataGaName":311},{"text":273,"config":314},{"href":275,"dataGaName":276,"dataGaLocation":27},{"text":316,"config":317},"Leadership",{"href":318,"dataGaName":319,"dataGaLocation":27},"/company/team/e-group/","leadership",{"text":321,"config":322},"Team",{"href":323,"dataGaName":324,"dataGaLocation":27},"/company/team/","team",{"text":326,"config":327},"Handbook",{"href":328,"dataGaName":329,"dataGaLocation":27},"https://handbook.gitlab.com/","handbook",{"text":331,"config":332},"Investor relations",{"href":333,"dataGaName":334,"dataGaLocation":27},"https://ir.gitlab.com/","investor relations",{"text":336,"config":337},"Trust Center",{"href":338,"dataGaName":339,"dataGaLocation":27},"/security/","trust center",{"text":341,"config":342},"AI Transparency Center",{"href":343,"dataGaName":344,"dataGaLocation":27},"/ai-transparency-center/","ai transparency center",{"text":346,"config":347},"Newsletter",{"href":348,"dataGaName":349,"dataGaLocation":27},"/company/contact/","newsletter",{"text":351,"config":352},"Press",{"href":353,"dataGaName":354,"dataGaLocation":27},"/press/","press",{"text":356,"config":357,"lists":358},"Contact us",{"dataNavLevelOne":298},[359],{"items":360},[361,364,369],{"text":34,"config":362},{"href":36,"dataGaName":363,"dataGaLocation":27},"talk to sales",{"text":365,"config":366},"Get help",{"href":367,"dataGaName":368,"dataGaLocation":27},"/support/","get help",{"text":370,"config":371},"Customer portal",{"href":372,"dataGaName":373,"dataGaLocation":27},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":375,"login":376,"suggestions":383},"Close",{"text":377,"link":378},"To search repositories and projects, login to",{"text":379,"config":380},"gitlab.com",{"href":41,"dataGaName":381,"dataGaLocation":382},"search login","search",{"text":384,"default":385},"Suggestions",[386,388,392,394,398,402],{"text":56,"config":387},{"href":61,"dataGaName":56,"dataGaLocation":382},{"text":389,"config":390},"Code Suggestions (AI)",{"href":391,"dataGaName":389,"dataGaLocation":382},"/solutions/code-suggestions/",{"text":108,"config":393},{"href":110,"dataGaName":108,"dataGaLocation":382},{"text":395,"config":396},"GitLab on AWS",{"href":397,"dataGaName":395,"dataGaLocation":382},"/partners/technology-partners/aws/",{"text":399,"config":400},"GitLab on Google Cloud",{"href":401,"dataGaName":399,"dataGaLocation":382},"/partners/technology-partners/google-cloud-platform/",{"text":403,"config":404},"Why GitLab?",{"href":69,"dataGaName":403,"dataGaLocation":382},{"freeTrial":406,"mobileIcon":411,"desktopIcon":416,"secondaryButton":419},{"text":407,"config":408},"Start free trial",{"href":409,"dataGaName":32,"dataGaLocation":410},"https://gitlab.com/-/trials/new/","nav",{"altText":412,"config":413},"Gitlab Icon",{"src":414,"dataGaName":415,"dataGaLocation":410},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":412,"config":417},{"src":418,"dataGaName":415,"dataGaLocation":410},"/images/brand/gitlab-logo-type.svg",{"text":420,"config":421},"Get Started",{"href":422,"dataGaName":423,"dataGaLocation":410},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/compare/gitlab-vs-github/","get started",{"freeTrial":425,"mobileIcon":429,"desktopIcon":431},{"text":426,"config":427},"Learn more about GitLab Duo",{"href":61,"dataGaName":428,"dataGaLocation":410},"gitlab duo",{"altText":412,"config":430},{"src":414,"dataGaName":415,"dataGaLocation":410},{"altText":412,"config":432},{"src":418,"dataGaName":415,"dataGaLocation":410},"content:shared:en-us:main-navigation.yml","Main Navigation","shared/en-us/main-navigation.yml","shared/en-us/main-navigation",{"_path":438,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"title":439,"button":440,"image":444,"config":447,"_id":449,"_type":13,"_source":15,"_file":450,"_stem":451,"_extension":18},"/shared/en-us/banner","is now in public beta!",{"text":67,"config":441},{"href":442,"dataGaName":443,"dataGaLocation":27},"/gitlab-duo/agent-platform/","duo banner",{"config":445},{"src":446},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1753720689/somrf9zaunk0xlt7ne4x.svg",{"layout":448},"release","content:shared:en-us:banner.yml","shared/en-us/banner.yml","shared/en-us/banner",{"_path":453,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"data":454,"_id":659,"_type":13,"title":660,"_source":15,"_file":661,"_stem":662,"_extension":18},"/shared/en-us/main-footer",{"text":455,"source":456,"edit":462,"contribute":467,"config":472,"items":477,"minimal":651},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":457,"config":458},"View page source",{"href":459,"dataGaName":460,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":463,"config":464},"Edit this page",{"href":465,"dataGaName":466,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":468,"config":469},"Please contribute",{"href":470,"dataGaName":471,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":473,"facebook":474,"youtube":475,"linkedin":476},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[478,501,558,587,621],{"title":45,"links":479,"subMenu":484},[480],{"text":481,"config":482},"DevSecOps platform",{"href":54,"dataGaName":483,"dataGaLocation":461},"devsecops platform",[485],{"title":185,"links":486},[487,491,496],{"text":488,"config":489},"View plans",{"href":187,"dataGaName":490,"dataGaLocation":461},"view plans",{"text":492,"config":493},"Why Premium?",{"href":494,"dataGaName":495,"dataGaLocation":461},"/pricing/premium/","why premium",{"text":497,"config":498},"Why Ultimate?",{"href":499,"dataGaName":500,"dataGaLocation":461},"/pricing/ultimate/","why ultimate",{"title":502,"links":503},"Solutions",[504,509,512,514,519,524,528,531,535,540,542,545,548,553],{"text":505,"config":506},"Digital transformation",{"href":507,"dataGaName":508,"dataGaLocation":461},"/topics/digital-transformation/","digital transformation",{"text":133,"config":510},{"href":128,"dataGaName":511,"dataGaLocation":461},"security & compliance",{"text":122,"config":513},{"href":104,"dataGaName":105,"dataGaLocation":461},{"text":515,"config":516},"Agile development",{"href":517,"dataGaName":518,"dataGaLocation":461},"/solutions/agile-delivery/","agile delivery",{"text":520,"config":521},"Cloud transformation",{"href":522,"dataGaName":523,"dataGaLocation":461},"/topics/cloud-native/","cloud transformation",{"text":525,"config":526},"SCM",{"href":118,"dataGaName":527,"dataGaLocation":461},"source code management",{"text":108,"config":529},{"href":110,"dataGaName":530,"dataGaLocation":461},"continuous integration & delivery",{"text":532,"config":533},"Value stream management",{"href":160,"dataGaName":534,"dataGaLocation":461},"value stream management",{"text":536,"config":537},"GitOps",{"href":538,"dataGaName":539,"dataGaLocation":461},"/solutions/gitops/","gitops",{"text":170,"config":541},{"href":172,"dataGaName":173,"dataGaLocation":461},{"text":543,"config":544},"Small business",{"href":177,"dataGaName":178,"dataGaLocation":461},{"text":546,"config":547},"Public sector",{"href":182,"dataGaName":183,"dataGaLocation":461},{"text":549,"config":550},"Education",{"href":551,"dataGaName":552,"dataGaLocation":461},"/solutions/education/","education",{"text":554,"config":555},"Financial services",{"href":556,"dataGaName":557,"dataGaLocation":461},"/solutions/finance/","financial services",{"title":190,"links":559},[560,562,564,566,569,571,573,575,577,579,581,583,585],{"text":202,"config":561},{"href":204,"dataGaName":205,"dataGaLocation":461},{"text":207,"config":563},{"href":209,"dataGaName":210,"dataGaLocation":461},{"text":212,"config":565},{"href":214,"dataGaName":215,"dataGaLocation":461},{"text":217,"config":567},{"href":219,"dataGaName":568,"dataGaLocation":461},"docs",{"text":240,"config":570},{"href":242,"dataGaName":243,"dataGaLocation":461},{"text":235,"config":572},{"href":237,"dataGaName":238,"dataGaLocation":461},{"text":245,"config":574},{"href":247,"dataGaName":248,"dataGaLocation":461},{"text":258,"config":576},{"href":260,"dataGaName":261,"dataGaLocation":461},{"text":250,"config":578},{"href":252,"dataGaName":253,"dataGaLocation":461},{"text":263,"config":580},{"href":265,"dataGaName":266,"dataGaLocation":461},{"text":268,"config":582},{"href":270,"dataGaName":271,"dataGaLocation":461},{"text":273,"config":584},{"href":275,"dataGaName":276,"dataGaLocation":461},{"text":278,"config":586},{"href":280,"dataGaName":281,"dataGaLocation":461},{"title":296,"links":588},[589,591,593,595,597,599,601,605,610,612,614,616],{"text":303,"config":590},{"href":305,"dataGaName":298,"dataGaLocation":461},{"text":308,"config":592},{"href":310,"dataGaName":311,"dataGaLocation":461},{"text":316,"config":594},{"href":318,"dataGaName":319,"dataGaLocation":461},{"text":321,"config":596},{"href":323,"dataGaName":324,"dataGaLocation":461},{"text":326,"config":598},{"href":328,"dataGaName":329,"dataGaLocation":461},{"text":331,"config":600},{"href":333,"dataGaName":334,"dataGaLocation":461},{"text":602,"config":603},"Sustainability",{"href":604,"dataGaName":602,"dataGaLocation":461},"/sustainability/",{"text":606,"config":607},"Diversity, inclusion and belonging (DIB)",{"href":608,"dataGaName":609,"dataGaLocation":461},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":336,"config":611},{"href":338,"dataGaName":339,"dataGaLocation":461},{"text":346,"config":613},{"href":348,"dataGaName":349,"dataGaLocation":461},{"text":351,"config":615},{"href":353,"dataGaName":354,"dataGaLocation":461},{"text":617,"config":618},"Modern Slavery Transparency Statement",{"href":619,"dataGaName":620,"dataGaLocation":461},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":622,"links":623},"Contact Us",[624,627,629,631,636,641,646],{"text":625,"config":626},"Contact an expert",{"href":36,"dataGaName":37,"dataGaLocation":461},{"text":365,"config":628},{"href":367,"dataGaName":368,"dataGaLocation":461},{"text":370,"config":630},{"href":372,"dataGaName":373,"dataGaLocation":461},{"text":632,"config":633},"Status",{"href":634,"dataGaName":635,"dataGaLocation":461},"https://status.gitlab.com/","status",{"text":637,"config":638},"Terms of use",{"href":639,"dataGaName":640,"dataGaLocation":461},"/terms/","terms of use",{"text":642,"config":643},"Privacy statement",{"href":644,"dataGaName":645,"dataGaLocation":461},"/privacy/","privacy statement",{"text":647,"config":648},"Cookie preferences",{"dataGaName":649,"dataGaLocation":461,"id":650,"isOneTrustButton":90},"cookie preferences","ot-sdk-btn",{"items":652},[653,655,657],{"text":637,"config":654},{"href":639,"dataGaName":640,"dataGaLocation":461},{"text":642,"config":656},{"href":644,"dataGaName":645,"dataGaLocation":461},{"text":647,"config":658},{"dataGaName":649,"dataGaLocation":461,"id":650,"isOneTrustButton":90},"content:shared:en-us:main-footer.yml","Main Footer","shared/en-us/main-footer.yml","shared/en-us/main-footer",{"allPosts":664,"featuredPost":1830,"totalPagesCount":1851,"initialPosts":1852},[665,690,712,735,759,782,804,824,844,868,886,904,922,940,958,977,998,1019,1041,1063,1084,1104,1124,1143,1165,1184,1205,1227,1247,1269,1291,1312,1332,1352,1373,1394,1414,1434,1452,1472,1490,1510,1531,1553,1573,1594,1612,1633,1652,1672,1692,1711,1730,1750,1772,1791,1810],{"_path":666,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":667,"content":675,"config":683,"_id":686,"_type":13,"title":687,"_source":15,"_file":688,"_stem":689,"_extension":18},"/en-us/blog/3000-contributors-post",{"title":668,"description":669,"ogTitle":668,"ogDescription":669,"noIndex":6,"ogImage":670,"ogUrl":671,"ogSiteName":672,"ogType":673,"canonicalUrls":671,"schema":674},"Celebrating 3,000 wider community contributors","We've reached an important contributor milestone and added two new members to the Core Team.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678450/Blog/Hero%20Images/blog-header-3000-contributors.png","https://about.gitlab.com/blog/3000-contributors-post","https://about.gitlab.com","article","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Celebrating 3,000 wider community contributors\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2020-06-23\",\n }",{"title":668,"description":669,"authors":676,"heroImage":670,"date":678,"body":679,"category":680,"tags":681},[677],"Ray Paik","2020-06-23","\nLike many open source projects, we have a [community dashboard](https://contributors.gitlab.com) at GitLab and one of the metrics that a few of us were occasionally checking on was the number of **Contributors**. This is the number of wider community members who had merge requests (MRs) merged with the `Community contribution` label across all projects at GitLab. There were some virtual high fives a few weeks ago when the number crossed the 3,000 threshold. There is probably a tendency to place oversized importance on nice round numbers, because if you really think about it the GitLab community wasn't any different at 2,999 vs. 3,000 contributors. However, it was a great occasion to celebrate the continued growth of the wider GitLab community. \n\n![Community dashboard screenshot](https://about.gitlab.com/images/blogimages/3000-contributors/dashboard-screenshot.png){: .shadow.medium.center}\nCommunity dashboard screenshot from April 23, 2020\n{: .note.text-center}\n\nThe past few months have been a challenging time due to Covid-19, and there was talk in open source circles about the pandemic's potential impact on contributions to open source projects. As people were trying to sort out many new challenges in life, it was reasonable to expect that open source contributions might fall lower on the list of priorities. We actually did see a decline in wider community contributions during the last few weeks of March (125 MRs submitted) compared to the previous two weeks (143 MRs submitted). However, the GitLab community seemed to roar back relatively quickly, and the best evidence of that is from our most recent [Hackathon](/community/hackathon/) when my inbox got innundated with [240 MRs submitted](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/-/issues/35#merge-request-list) over two days. \n\nFirst and foremost, I'm very glad most of the wider community members are doing ok and adjusting to the strange new normal. Moreover, I am grateful that new people are continuing to join and helping to grow the GitLab community with their contributions and enthusiasm even during these challenging times. \n\nWhat all these contributors bring are not just MRs but more importantly valuable feeback and insight that help us improve our product and the community. Some of you may have seen our latest [2020 Global DevSecOps Survey results](/developer-survey/), and one figure that caught my attention was that more than 17% of the respondents actually contribute to GitLab. I hope to see that trend continue.\n\n## Exciting additions to the Core Team\n\nMany of you may already be familar with the [GitLab Core Team](/community/core-team/), but if not, Core Team members are community members who made sustained contribution to GitLab over the years and serve as representatives of the wider contributor community. In keeping with the growth in contributor numbers, I'm happy to report that we are also adding to the GitLab Core Team. \n\nFrom the wider community, I'm excited to introduce [Lee Tickett](https://gitlab.com/leetickett) as a new Core Team member. If you ever posted a question in the [Contributors room on Gitter](https://gitter.im/gitlab/contributors), Lee may have been one of the first to help with your question. Lee has also been very active with [code contributions](https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=all&utf8=%E2%9C%93&state=all&author_username=leetickett) and participating in [issues](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=all&author_username=leetickett). Lee's contribution to GitLab as someone who's been using GitLab for his own company since 2017 has been extremely valuable. When Lee isn't working, contributing, sleeping or eating, you'll likely find him spending time with his family or kicking back in his home bar with some Pac-Man, a game of pool and an ice cold pint.\n\nThe Core Team also includes up to two GitLab team members, and I'm very happy to have [Natalia Tepluhina](/company/team/#ntepluhina) joining as the first female member in the history of the GitLab Core Team. If you submitted frontend related MRs, there's a good chance that Natalia [reviewed and merged your MRs](https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name[]=Community%20contribution&assignee_username=ntepluhina). Natalia is also a Core Team member in the Vue.js community and brings a wealth of experience from other open source projects. If you want to meet Natalia in person, she is a frequent speaker at Vue.js events around the world and other Javascript conferences such as [JSHeroes](https://jsheroes.io/) and [JSNation](https://jsnation.com/). \n\n![Core Team pictures](https://about.gitlab.com/images/blogimages/3000-contributors/Core-team-pictures.png){: .shadow.medium.center}\nWelcome Lee and Natalia to the Core Team!\n{: .note.text-center}\n\n## Interested in learning how you can contribute?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can\nlearn how you can contribute to GitLab's code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to [email me](mailto:rpaik@gitlab.com).\n\n**Read more about our GitLab contributors:**\n\n[New tools make contributing to GitLab easier](/blog/13-0-contributor-experience-update/)\n\n[Community contributions in 2019](/blog/community-update-for-2019/)\n\n[What's a GitLab Hackathon _really_ like?](/blog/q4-hackathon-recap/)\n","open-source",[266,682,9],"open source",{"slug":684,"featured":6,"template":685},"3000-contributors-post","BlogPost","content:en-us:blog:3000-contributors-post.yml","3000 Contributors Post","en-us/blog/3000-contributors-post.yml","en-us/blog/3000-contributors-post",{"_path":691,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":692,"content":698,"config":706,"_id":708,"_type":13,"title":709,"_source":15,"_file":710,"_stem":711,"_extension":18},"/en-us/blog/5-problems-you-can-help-us-solve-right-now",{"title":693,"description":694,"ogTitle":693,"ogDescription":694,"noIndex":6,"ogImage":695,"ogUrl":696,"ogSiteName":672,"ogType":673,"canonicalUrls":696,"schema":697},"5 UX problems you can help us fix right now","“We spent 40 hours talking to 20 of you. Now we’ve got some issues we’d like your help on.”","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682386/Blog/Hero%20Images/pexels-sevenstorm-juhaszimrus-704767.jpg","https://about.gitlab.com/blog/5-problems-you-can-help-us-solve-right-now","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"5 UX problems you can help us fix right now\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ben Leduc-Mills\"}],\n \"datePublished\": \"2022-07-25\",\n }",{"title":693,"description":694,"authors":699,"heroImage":695,"date":701,"body":702,"category":680,"tags":703},[700],"Ben Leduc-Mills","2022-07-25"," \n\nWe’ve all been there. You’re sailing along, being productive, and wham! Something inexplicably awful disrupts your workflow. You ask yourself, “How could _anyone_ think this was a good idea?” Maybe it’s a bug, slow performance, or bad design. One of the reasons we conduct [user experience research at GitLab](/handbook/product/ux/ux-research/) is to find these problems and report back to our teams so they can fix them. \n\n![Grumpy cat looking over computer](https://about.gitlab.com/images/blogimages/hhh13-tEMU4lzAL0w-unsplash__1_.jpg)\nWe've all been there\n{: .note.text-center}\n\nWith a product as rich and complex as GitLab, we find _a lot_ of problems. So many, in fact, we often can't fix them as fast as you find them. ([Although we do try!](/releases/2022/05/22/gitlab-15-0-released/#bug-fixes)) The great thing about GitLab is that [**everyone** can contribute](/company/mission/). This is the first in a new series of blog posts where the UX researchers at GitLab transform their findings into some great first contributions that community members can explore. \n\nWe recently spent 2 hours each with 20 people who use GitLab, going through specific tasks related to branch and merge request operations, and, predictably, we found plenty of things to work on (although this research focused on the code creation and review process) - you can check out the full report below:\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe style=\"border: 1px solid rgba(0, 0, 0, 0.1);\" width=\"800\" height=\"450\" src=\"https://www.figma.com/embed?embed_host=share&url=https%3A%2F%2Fwww.figma.com%2Fproto%2FmF555KKsf1m1UyyXbWxXu2%2FBenchmarking-Slides%3Fnode-id%3D943%253A12915%26scaling%3Dscale-down%26page-id%3D40%253A124%26starting-point-node-id%3D943%253A12915\" allowfullscreen>\u003C/iframe>\n\u003C/figure>\n\n\nWithout further ado, here are five issues we would **love** your contributions on:\n\n1. [Show more branches in the drop down menu while reverting a merge request.](https://gitlab.com/gitlab-org/gitlab/-/issues/358218) \n1. [Increase the discoverability of the insert suggestion feature.](https://gitlab.com/gitlab-org/gitlab/-/issues/368716) \n1. [Fix data loss when switching from inline to side-by-side view on MR creation page.](https://gitlab.com/gitlab-org/gitlab/-/issues/358217) \n1. [Show selected labels within the dropdown menu.](https://gitlab.com/gitlab-org/gitlab/-/issues/322945) \n1. [Improve clarity of text-only buttons -- Move 'mark as draft' onto new line](https://gitlab.com/gitlab-org/gitlab/-/issues/358437) \n\nWondering where to start? Check out [this blog post](/blog/first-time-open-source-contributor-5-things-to-get-you-started/) and [our development guide](/community/contribute/development/) and become an all-star contributor! \n\nNeed guidance or help? Feel free to leave a comment directly on one of the issues linked above, or find support in the \"get help\" section [in our contributing guide](/community/contribute/#getting-help).\n\nContributing to an open source project also brings a ton of proven benefits you might not expect:\n\n- Contributing is one of the most efficient ways to learn, as it is learning by doing and [being guided by merge request coaches](https://handbook.gitlab.com/job-families/expert/merge-request-coach/). Contributing has been proven time and time again to be the best form of learning!\n- Public exposure and explicit appreciation from the open source community, which helps build your public profile And show your expertise ... you never know when that resume might come in handy! 😊 \n- You're in for a treat: **first-time** contributors receive GitLab swag, **regular** contributors (5 MRs or more) are eligible for the [GitLab Heroes program](/community/heroes), and **top** contributors may be invited to join the [GitLab Core team](/community/core-team/).\n\nAnd not only is this beneficial for you, but also for your employer (if you are employed). Because you are growing and learning at a rapid speed from the best, you will get a faster turnaround time when integrating a feature into the platform since you know how the system works. You will get more value from the most precious resource in the universe, time 🕐. Take advantage of this experience today. We are convinced of the benefits and we hope you and/or your employer are too now. Let's aim for the moon together. 🚀 \n\n1,2,3...**let's go!**\n\nCover image by [SevenStorm JUHASZIMRUS](https://www.pexels.com/@sevenstormphotography/) on [Pexels](https://www.pexels.com/photo/123-let-s-go-imaginary-text-704767/)\n{: .note}\n",[9,266,682,704,705],"research","UX",{"slug":707,"featured":6,"template":685},"5-problems-you-can-help-us-solve-right-now","content:en-us:blog:5-problems-you-can-help-us-solve-right-now.yml","5 Problems You Can Help Us Solve Right Now","en-us/blog/5-problems-you-can-help-us-solve-right-now.yml","en-us/blog/5-problems-you-can-help-us-solve-right-now",{"_path":713,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":714,"content":720,"config":729,"_id":731,"_type":13,"title":732,"_source":15,"_file":733,"_stem":734,"_extension":18},"/en-us/blog/a-special-farewell-from-gitlab-dmitriy-zaporozhets",{"title":715,"description":716,"ogTitle":715,"ogDescription":716,"noIndex":6,"ogImage":717,"ogUrl":718,"ogSiteName":672,"ogType":673,"canonicalUrls":718,"schema":719},"A special farewell from GitLab’s Dmitriy Zaporozhets","A message from GitLab's co-founders","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670031/Blog/Hero%20Images/siddz.png","https://about.gitlab.com/blog/a-special-farewell-from-gitlab-dmitriy-zaporozhets","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"A special farewell from GitLab’s Dmitriy Zaporozhets\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sid Sijbrandij\"},{\"@type\":\"Person\",\"name\":\"Dmitriy Zaporozhets\"}],\n \"datePublished\": \"2021-11-10\",\n }",{"title":715,"description":716,"authors":721,"heroImage":717,"date":724,"body":725,"category":726,"tags":727},[722,723],"Sid Sijbrandij","Dmitriy Zaporozhets","2021-11-10","\n**Sid Sijbrandij**: Today, we shared the news with the team that my co-founder and the creator of GitLab the open source project, Dmitriy Zaporozhets, has made the decision to leave his position as Engineering Fellow at GitLab. Below, Dmitriy shares this news in his own words with the GitLab community.\n\n**Dmitriy Zaporozhets**: I remember when I told Sid, my co-founder and the CEO of GitLab, that I wanted to commit 10 years to GitLab from the time I started the project in October of 2011. It’s been an amazing journey over the last 10 years. And just last month, on October 14, 2021, I joined Sid at Nasdaq in New York City as GitLab became a public company. Today, I want to share with the GitLab community that I am stepping away from my position as an Engineering Fellow at GitLab Inc. I have fulfilled my 10 year vision, and I feel that I can step away with so much pride in what GitLab has become and so much faith in where GitLab is headed.\n\nBack in 2011, I was working as a software developer. I worked with version control everyday. There was no modern open source software to run on your server and I saw an opportunity to make something useful as a hobby project. I started the project with Valery Sizov, and I remember having coffee with him, discussing the challenges and improvements we wanted to make. It was such a great feeling to brainstorm something that we cared so deeply about. \n\nIn that first year, we grew a functional open source community around the project. I was quite surprised that so many people participated. That gave me energy and confidence to keep going with the project. Everytime someone contributed, I felt like I needed to put even more effort into it. \n\nIn 2012, I got an email from Sid, saying that he wanted to let me know that he started GitLab.com. I remember he said, “I hope you don’t mind.” The truth is, I was happy that he was interested in GitLab. I hoped that he would bring more users and potentially more contributors. I did not imagine we would end up joining together and making the project as popular as it has become. \n\nI came to work at GitLab full time in 2013. A team member recently asked me what my job title was when I started working at GitLab full time. The answer: it was Dmitriy. I didn’t have a formal title in the beginning. My first official title with the company was Chief Technology Officer. Quite a lot happened during that time. I wrote a lot of code, merged a lot of merge requests. I still have the highest number of commits in the main repository. I worked closely with the first front-end developer and the first UX designer, and we were building everything from scratch.\n\nBy October of 2018, the company grew to the size when the CTO couldn't write the code anymore. I transitioned into my role as Engineering Fellow and worked on several new features in the product. It was a time when building something was just as important as not breaking it. \n\nIt has been an amazing experience to be a part of GitLab’s evolution into [The DevOps Platform](/solutions/devops-platform/). From the simple source control software to the platform that helps you deliver better software faster. I am very glad to have been a part of GitLab’s growth and to be a part of building something that is so valuable to software development. \n\nIt was an honor to be in New York City last month to help Sid ring the opening bell at Nasdaq and see GitLab become a publicly traded company. I know what we do at GitLab had value for the rest of the world even before the company went public. However, experiencing GitLab’s listing day in person filled me with emotion, and there’s one thing I know for sure: the world cares about what we are doing here. \n\nI am so thankful to everyone who has contributed to GitLab. I especially want to thank Valery Sizov, Kamil Trzciński, Douwe Maan, Phil Hughes, Stan Hu, Rémy Coutable, Robert Speicher, and Sean McGivern, most of whom joined soon before or after Y Combinator and took our productivity to the next level. You were all just as passionate about the product as I was and it was amazing to work with you all. I also want to thank employee number 1 Marin Jankovski and employee number 2 Jacob Vosmaer, both of whom are still at GitLab Inc. after all these years. And of course, I want to thank Sid. Sid, your noble aspirations and your strong leadership made all of this possible. Thank you for your partnership over the years, it has been an honor to be on this journey with you as co-founders.\n\nThank you to the community and everyone who has believed in, supported, and contributed to GitLab’s journey. I believe we are still early in GitLab’s evolution, and I cannot wait to see what the team and the community do next.\n\nDmitriy \n\nDmitriy Zaporozhets\n\nCo-founder, GitLab\n\n**Sid Sijbrandij**: Dmitriy, it has been an incredible 10 years since you started the project. Thank you for creating GitLab, making it open source, joining me on this journey and caring for GitLab for the last 10 years. It was an amazing experience to ring the opening bell with you at Nasdaq and I’m excited to continue to build upon what we’ve created thus far and lead GitLab through its next phase. \n\nWhile you are leaving your position as Engineering Fellow, I know that we will still keep in touch, and your legacy will live on through the company and the wider community. To honor your impact, GitLab Inc. has announced an annual “DZ Award” to recognize one team member who has made great impact by solving a difficult problem using a [boring solution](https://handbook.gitlab.com/handbook/values/#boring-solutions), because at GitLab, we celebrate the boring solution as a simple, fast, and effective way to maintain our speed of innovation. It will be an honor to recognize team members who embody your innovative spirit and deliver results that help us continue to grow.\n\nDmitriy, thank you for the incredible impact you’ve had on all of us. \n\nSid\n\nSid Sijbrandij\n\nCo-founder and CEO, GitLab\n","news",[728,266,9],"inside GitLab",{"slug":730,"featured":6,"template":685},"a-special-farewell-from-gitlab-dmitriy-zaporozhets","content:en-us:blog:a-special-farewell-from-gitlab-dmitriy-zaporozhets.yml","A Special Farewell From Gitlab Dmitriy Zaporozhets","en-us/blog/a-special-farewell-from-gitlab-dmitriy-zaporozhets.yml","en-us/blog/a-special-farewell-from-gitlab-dmitriy-zaporozhets",{"_path":736,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":737,"content":743,"config":753,"_id":755,"_type":13,"title":756,"_source":15,"_file":757,"_stem":758,"_extension":18},"/en-us/blog/availability-postgres-patroni",{"title":738,"description":739,"ogTitle":738,"ogDescription":739,"noIndex":6,"ogImage":740,"ogUrl":741,"ogSiteName":672,"ogType":673,"canonicalUrls":741,"schema":742},"Introducing Patroni as the Postgres Failover Manager on GitLab.com","GitLab.com is introducing Patroni as the Postgres Failover Manager on GitLab.com.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671280/Blog/Hero%20Images/gitlab-gke-integration-cover.png","https://about.gitlab.com/blog/availability-postgres-patroni","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Introducing Patroni as the Postgres Failover Manager on GitLab.com\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Gerardo Lopez-Fernandez\"}],\n \"datePublished\": \"2018-12-05\",\n }",{"title":738,"description":739,"authors":744,"heroImage":740,"date":746,"body":747,"category":748,"tags":749},[745],"Gerardo Lopez-Fernandez","2018-12-05","\n\n## Upcoming Maintenance Windows for Patroni Deployment\n\nWe are writing this post to let our community know we are planning on performing the work necessary \nto deploy [Patroni](https://github.com/zalando/patroni) as the Postgres Failover Manager on GitLab.com over two weekends: a dry-run to test\nour migration plan and tools on Saturday, Dec 8, 2018, and the actual deployment on Saturday, December\n15, 2018.\n\nDuring the maintenance windows, the following services will be unavailable:\n\n* SaaS website ([GitLab.com](https://gitlab.com/) will be offline, but [about.gitlab.com](https://about.gitlab.com/) and [docs.gitlab.com](https://docs.gitlab.com/) will still be available)\n* Git ssh\n* Git https\n* registry\n* CI/CD\n* Pages\n\n### Maintenance Window - Dry run - Saturday, December 8 at 13:00 UTC\n\nWe will perform testing and validation of our deployment procedures and tools during this maintenance\nwindow to do final readiness checks. This maintenance window should last 30 minutes.\n\n### Maintenance Window - Actual Cutover - Saturday, December 15 at 13:00 UTC\n\nOn the day of the cutover, we are planning to start at 13:00 UTC. The time window for GitLab.com to be\nin maintenance is currently planned to be 30 minutes. Should any times for this change, we will be updating\non the channels listed below. When this window is completed GitLab.com will be running Patroni.\n\n* [GitLab Status page](https://status.gitlab.com/)\n* [GitLab Status Twitter](https://twitter.com/gitlabstatus)\n\n","engineering",[750,750,751,752,751,9],"features","agile","bug bounty",{"slug":754,"featured":6,"template":685},"availability-postgres-patroni","content:en-us:blog:availability-postgres-patroni.yml","Availability Postgres Patroni","en-us/blog/availability-postgres-patroni.yml","en-us/blog/availability-postgres-patroni",{"_path":760,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":761,"content":767,"config":776,"_id":778,"_type":13,"title":779,"_source":15,"_file":780,"_stem":781,"_extension":18},"/en-us/blog/best-advice-for-your-devops-career-keep-on-learning",{"title":762,"description":763,"ogTitle":762,"ogDescription":763,"noIndex":6,"ogImage":764,"ogUrl":765,"ogSiteName":672,"ogType":673,"canonicalUrls":765,"schema":766},"Best advice for your DevOps career? Keep on learning","If you want a new job, or a higher salary, or preferably both, add some skills to your DevOps resume. Here's a look at our strategy for DIY-ing your continuing ed.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679473/Blog/Hero%20Images/designing-in-an-all-remote-company.jpg","https://about.gitlab.com/blog/best-advice-for-your-devops-career-keep-on-learning","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Best advice for your DevOps career? Keep on learning\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sharon Gaudin\"}],\n \"datePublished\": \"2021-11-09\",\n }",{"title":762,"description":763,"authors":768,"heroImage":764,"date":770,"body":771,"category":772,"tags":773},[769],"Sharon Gaudin","2021-11-09","\nDevOps skills might be in demand, but it’s not the time to remain complacent if you want a new (and better) job or a higher salary. Luckily the best career move you can make is also the easiest: continue to add new skills, even if you have to DIY it.\n\n“I think continually educating myself has been really important in my career, and it’s been mostly DIY,” said said [Brendan O’Leary](https://gitlab.com/brendan), a staff developer evangelist, and product and engineering leader at GitLab. “It’s allowed me to make different career moves and advance my career by changing companies or by changing roles at my current company… Continuing to educate yourself is one of the most important things you can do.”\n\n## DevOps education: how to keep learning\n\nIt’s well known that continuing to educate yourself and pursuing certifications are two of the [top ways to increase your paycheck](/blog/four-tips-to-increase-your-devops-salary/), but here’s our best advice on how to bootstrap your learning journey without waiting for your employer.\n\n### Take responsibility for your own journey\n\nDon’t panic if your company is one of the many that doesn’t offer continuous education opportunities: According to the DevOps Institute’s 2021 Enterprise DevOps Skills Report, [52 percent of companies don’t](https://learn.gitlab.com/devops-institute/2021-doi-devops-upskilling-report?utm_medium=email&utm_source=marketo&utm_campaign=devopsgtm&utm_content=doi-devops-upskilling-report). (To be transparent, GitLab was one of the partners in the Institute’s survey.)\n\n### Figure out what you, and your company, need\n\nMake sure you’re not learning about a new technology or tool because it’s the cool new thing. Focus your time and energy on learning something that actually will solve a problem or give your business a competitive edge. Keep your skills aligned with shifting business demands, learning enough about a new technology so you understand if it will solve a business problem.\n\nIn a sea of possibilities, there are some concrete learning options we can suggest. In our [2021 Global DevSecOps Survey](/developer-survey/), we asked respondents what skill or skills would be most important for their future career. A majority of developers said knowledge around artificial intelligence and machine learning would be critical, while ops team members wanted more advanced programming languages. Security pros, on the other hand, wanted to become subject matter experts in their industries.\n\n### Assessing your skills and deficits\n\nGauge your baseline of skills, experience and certifications. What comes naturally to you, and what is more of a struggle? Now compare your baseline to what your company needs, and then broaden it out to what the industry is looking for.\n\nOne easy way to broadly compare your skills to others is to look at a job search site like [Glassdoor.com](https://www.glassdoor.com). The job listings detail the skills, languages, experiences, technologies and other attributes an employer is looking for.\n\nWe randomly grabbed and anonymized a job posting for a DevOps engineer from Glassdoor, below. You’ll see how many boxes you’ll need to check (we bolded the key phrases just to make the point):\n\n_You will demonstrate a **leadership** mindset, solid **operational experience**, and the **ability to problem-solve**. Additionally, you should have exceptional **communication skills**, be knowledgeable about the latest industry trends, and be **highly innovative**. The DevOps Engineer will help enhance and maintain a **programmable infrastructure, configure, implement, debug and document new and existing applications running on Linux and Windows operating systems in private and public cloud infrastructures**. Engage in **design, development, installation, and system administration of build/continuous integration systems, anti-virus systems, and configuration management systems**. Participate in the full development life cycle of DevOps projects including **assessment of requirements, system analysis, and design.**_\n\n### Go to the source for certifications\n\nOf course, there are university classes but they can be pricey. You don’t always have to spend thousands of dollars on a college course. Go to the original source of what you want to learn, and let certifications be your friend. [A survey from the McKinsey Quarterly,](https://www.mckinsey.com/business-functions/mckinsey-accelerate/our-insights/five-fifty-the-skillful-corporation?cid=fivefifty-eml-alt-mkq-mck&hlkid=a7a8ae1b68574d02b81db1f1eeb8fd8d&hctky=12428831&hdpid=8233aa33-5ff4-4450-a4c7-2f47dfeaf9d0) noted that 66 percent of survey respondents called certifications “extremely valuable.”\n\nFor instance, if you’re using The GitLab Platform, you can get a [security certification](/services/education/gitlab-security-specialist/) from GitLab. There are also [certifications for](/learn/certifications/public/) everything from CI/CD training, to project management and Git basics. Similarly, if you need to bone up on Google Cloud, check out their site for [certifications](https://acloudguru.com/training-library/gcp-cloud-training?utm_campaign=11244863417&utm_source=google&utm_medium=cpc&utm_content=469352928666&utm_term=b_&adgroupid=115625160932&gclid=Cj0KCQjw5oiMBhDtARIsAJi0qk20jsoQ55oCnlbde3tozrDRExDxxiJ0AooFulqXXguwOX072-OwJNAaAjd3EALw_wcB).\n\n### Other opportunities to educate yourself\n\nYou also can find learning opportunities at a lot of conferences, coding events, bootcamps, hackathons and workshops. Especially in the time of COVID-19, think about taking advantage of online courses. [YouTube](https://www.youtube.com) is full of hands-on technical tutorials, including a lot from GitLab and other tech companies as well as consultants and individual contributors. Don’t forget GitLab Learn, where you can do a self-paced deep dive via video tutorials into a number of key DevOps areas, including [continuous integration (CI)](/solutions/continuous-integration/).\n\nAnd for female developers, organizations like [Women Who Code](https://www.womenwhocode.com/) offer scholarships, tutorials and educational materials.\n\nDon’t forget about mentorships. Find someone who has the knowledge and experience you need and ask them to work with you and bring you up to speed. Then don’t forget to later turn around and lend a hand to the person coming up after you.\n\nStay tuned for more information on what hard and soft skills you should consider adding to your resume.\n\n## Read more on DevOps careers:\n\n- [6 tips to make software developer hiring easier](/blog/6-tips-to-make-software-developer-hiring-easier/)\n\n- [Four tips to increase your DevOps salary](/blog/four-tips-to-increase-your-devops-salary/)\n\n- [DevOps salaries in 2021: Where do you rank?](/blog/a-look-at-devops-salaries/)\n\n- [Have DevOps jobs to fill? Try these 3 strategies to hire and retain](/blog/have-devops-jobs-to-fill-try-these-3-strategies-to-hire-and-retain/)\n","insights",[774,775,9],"careers","DevOps",{"slug":777,"featured":6,"template":685},"best-advice-for-your-devops-career-keep-on-learning","content:en-us:blog:best-advice-for-your-devops-career-keep-on-learning.yml","Best Advice For Your Devops Career Keep On Learning","en-us/blog/best-advice-for-your-devops-career-keep-on-learning.yml","en-us/blog/best-advice-for-your-devops-career-keep-on-learning",{"_path":783,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":784,"content":790,"config":798,"_id":800,"_type":13,"title":801,"_source":15,"_file":802,"_stem":803,"_extension":18},"/en-us/blog/can-chatgpt-resolve-gitlab-issues",{"title":785,"description":786,"ogTitle":785,"ogDescription":786,"noIndex":6,"ogImage":787,"ogUrl":788,"ogSiteName":672,"ogType":673,"canonicalUrls":788,"schema":789},"Testing ChatGPT: Can it solve a GitLab issue?","We put ChatGPT to the test to see if it could contribute to GitLab. Here's what we learned.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670171/Blog/Hero%20Images/akshay-nanavati-Zq6HerrBPEs-unsplash.jpg","https://about.gitlab.com/blog/can-chatgpt-resolve-gitlab-issues","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Testing ChatGPT: Can it solve a GitLab issue?\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"John Coghlan\"},{\"@type\":\"Person\",\"name\":\"Fatima Sarah Khalid\"}],\n \"datePublished\": \"2022-12-15\",\n }",{"title":785,"description":786,"authors":791,"heroImage":787,"date":794,"body":795,"category":748,"tags":796},[792,793],"John Coghlan","Fatima Sarah Khalid","2022-12-15","\nChatGPT has taken the tech world by storm since its [launch on November 30](https://openai.com/blog/chatgpt/). Media coverage, front page posts on Hacker News, Twitter threads, and videos - everywhere you look, there is another story.\n\nThe [GitLab Slack](/handbook/communication/#slack) was no different. In threads across Slack channels, including those for developer evangelism, UX, the CEO, random news, and every space in between, our team was chatting about this exciting new tool.\n\nAs we got more familiar with the tool, we started to learn about numerous things it can do. Here are a few that we found:\n\n- It can write poetry about GitLab features. \n- It can write blog posts.\n- It can write unit tests.\n- It gives advice on how to use certain features of GitLab.\n- It conducts competitive analysis.\n\nThere’s quite a bit more out there, including [inventing a new language](https://maximumeffort.substack.com/p/i-taught-chatgpt-to-invent-a-language) and [building a virtual machine](https://www.engraved.blog/building-a-virtual-machine-inside/). We can’t recall any technology that has generated more excitement in such a short time.\n\nWe acknowledge there are ethical and licensing concerns around using AI-generated code. For the purpose of this blog post, we will focus strictly on the capabilities of ChatGPT.\n\n## Testing ChatGPT\n\nAs members of GitLab’s [Developer Relations team](/handbook/marketing/developer-relations/), where we’re focused on growing our community of contributors and evangelists, our first reaction was to think of how this tool can help our contributors. The responses to questions like “How can I get started contributing to GitLab?” were cool but didn’t move the needle. So then we asked ourselves: Can we use ChatGPT to make a contribution to GitLab?\n\nHaving already been testing the tool, we knew we’d need to look for a very specific type of issue. We started to fine-tune our search. Here are the steps we took to find a potential issue:\n\n- Visited [https://gitlab.com/gitlab-org](https://gitlab.com/gitlab-org) and pulled up all the open issues by clicking on `Issues` in the left side nav.\n- Searched for all issues with the [“good for new contributors” label](https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=updated_desc&state=opened&label_name%5B%5D=good%20for%20new%20contributors&first_page_size=20). This returned 482 issues at the time of writing.\n- Set [`“Assignee = None”`](https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=updated_desc&state=opened&label_name%5B%5D=good%20for%20new%20contributors&assignee_id=None&first_page_size=20) to filter out issues that have already been assigned to someone. This trimmed things down even more.\n\nAfter poking through a few issues, this one caught our attention: an issue that is a request to [de-depulicate identical dropdown functionality from two Vue components into a shared component](https://gitlab.com/gitlab-org/gitlab/-/issues/221293).\n\n### Getting started\n\nWe opened up a ChatGPT thread via [https://chat.openai.com/chat](https://chat.openai.com/chat). If you don’t already have an account, you’ll need to register with OpenAI.\n\nThen we started a thread with Assistant (that’s what is returned when you ask ChatGPT what is its name). We asked Assistant to create a shared Vue component called `SharedDropdownFilter` from the duplicate code in `GroupsDropdownFilter` and `ProjectsDropdownFilter` and passed the scripts of both components.\n\nChatGPT replied with:\n\n>You can create a new `SharedDropdownFilter` component that contains the duplicate code and use it in both `GroupsDropdownFilter` and `ProjectsDropdownFilter`:\n\nand provided a template to describe the use. The template provided wasn’t quite what we were looking for.\n\n```vue\n\u003Ctemplate>\n \u003CGlDropdown\n :aria-label=\"label\"\n :class=\"{ disabled: loading }\"\n :disabled=\"loading\"\n :selected=\"selectedProjectsLabel\"\n :variant=\"multiSelect ? 'inline' : 'single-line'\"\n >\n \u003Ctemplate v-slot:menu>\n \u003Cdiv class=\"py-4\">\n \u003CGlSearchBoxByType\n autofocus\n class=\"search-box\"\n :placeholder=\"searchPlaceholder\"\n :type=\"searchType\"\n v-model=\"searchTerm\"\n />\n\n \u003CGlDropdownHeader\n v-if=\"selectedProjects.length && multiSelect\"\n :class=\"{ 'd-none': !searchTerm }\"\n class=\"js-dropdown-header\"\n >\n \u003Cspan>\n {{ selectedProjectsLabel }}\n \u003C/span>\n\n \u003Cbutton\n```\n\nSo we tried again, this time being more specific and asking ChatGPT to “Create a shared Vue component that combines the two components `ProjectsDropdownFilter` and `GroupsDropdownFilter`”. We passed in the full component files, including the templates.\n\nChatGPT responded with instructions, a sample Vue component, and an explanation of the functionality:\n\n> Here is a sample implementation of a shared Vue component that combines the two components `ProjectsDropdownFilter` and `GroupsDropdownFilter`:\n\n```vue\n\u003Ctemplate>\n \u003Cdiv>\n \u003CProjectsDropdownFilter\n :groupId=\"groupId\"\n :multiSelect=\"multiSelect\"\n :label=\"label\"\n :queryParams=\"queryParams\"\n :defaultProjects=\"defaultProjects\"\n @selected=\"onProjectsSelected\"\n />\n \u003CGroupsDropdownFilter\n :multiSelect=\"multiSelect\"\n :label=\"label\"\n :queryParams=\"queryParams\"\n :defaultGroups=\"defaultGroups\"\n @selected=\"onGroupsSelected\"\n />\n \u003C/div>\n\u003C/template>\n\n\u003Cscript>\nimport { ProjectsDropdownFilter } from './ProjectsDropdownFilter.vue';\nimport { GroupsDropdownFilter } from './GroupsDropdownFilter.vue';\n\nexport default {\n name: 'SharedDropdownFilter',\n components: {\n ProjectsDropdownFilter,\n GroupsDropdownFilter,\n },\n props: {\n groupId: {\n type: Number,\n required: true,\n },\n multiSelect: {\n type: Boolean,\n required: false,\n default: false,\n },\n label: {\n type: String,\n required: false,\n default: 'Dropdown filter',\n },\n queryParams: {\n type: Object,\n required: false,\n default: () => ({}),\n },\n defaultProjects: {\n type: Array,\n required: false,\n default: () => [],\n },\n defaultGroups: {\n type: Array,\n required: false,\n default: () => [],\n },\n },\n data() {\n return {\n selectedProjects: this.defaultProjects || [],\n selectedGroups: this.defaultGroups || [],\n };\n },\n methods: {\n onProjectsSelected(selectedProjects) {\n this.selectedProjects = selectedProjects;\n this.$emit('selected', this.selectedProjects, this.selectedGroups);\n },\n onGroupsSelected(selectedGroups) {\n this.selectedGroups = selectedGroups;\n this.$emit('selected', this.selectedProjects, this.selectedGroups);\n },\n },\n};\n\u003C/script>\n```\n\n> In this implementation, the `SharedDropdownFilter` component is rendered as a container for the `ProjectsDropdownFilter` and` GroupsDropdownFilter` components. It passes down the `groupId`, `multiSelect`, `label`, `queryParams`, and `defaultProjects` props to the `ProjectsDropdownFilter` component, and the `multiSelect`, `label`, `queryParams`, and `defaultGroups` props to the `GroupsDropdownFilter` component. It also listens to the selected event emitted by the two components and updates its own `selectedProjects` and `selectedGroups` data accordingly. The `SharedDropdownFilter` component emits its own `selected` event with the updated `selectedProjects` and `selectedGroups` data when it receives the selected event from the `ProjectsDropdownFilter` and `GroupsDropdownFilter` components. This allows the parent component of the `SharedDropdownFilter` to be notified whenever the selected projects and groups are updated, so that it can take appropriate action, such as updating the data it displays.\n\nWith ChatGPT’s shared Vue component, we could start an MR for the issue, but would need to manually review the code and run tests in order to make sure the deduplication was done correctly.\n\n### Adjusting the filters\n\nIn hopes of finding an issue that ChatGPT could fully solve, this time we filtered using two labels (`good for new contributors` and `quick win`), Assignee = None, and added the keyword “refactor” to look for issues that required less net new code. At the time of writing, this [query](https://gitlab.com/gitlab-org/gitlab/-/issues/?search=refactor&sort=updated_asc&state=opened&label_name%5B%5D=quick%20win&label_name%5B%5D=good%20for%20new%20contributors&assignee_id=None&first_page_size=20) returned one issue: [a refactor for widget state tests](https://gitlab.com/gitlab-org/gitlab/-/issues/228611).\n\nAfter reviewing the issue, we opened the `/spec/frontend/vue_merge_request_widget/stores/get_state_key_spec.js` file mentioned in the issue description by navigating to that file on GitLab.com SaaS and opening the dropdown on the blue button at the top of the file frame, selecting “Open in Web IDE”, and then clicking the button to open the file in GitLab’s built-in Web IDE.\n\nWe copied the code from the file and asked ChatGPT to refactor these tests into a table of `it.each`. It was interesting to watch the output as ChatGPT provided an example of how we could refactor the tests using `it.each`:\n\n```javascript\nimport getStateKey from '~/vue_merge_request_widget/stores/get_state_key';\n\ndescribe('getStateKey', () => {\n const context = {\n mergeStatus: 'checked',\n autoMergeEnabled: false,\n canMerge: true,\n onlyAllowMergeIfPipelineSucceeds: false,\n isPipelineFailed: false,\n hasMergeableDiscussionsState: false,\n isPipelineBlocked: false,\n canBeMerged: false,\n projectArchived: false,\n branchMissing: false,\n commitsCount: 2,\n hasConflicts: false,\n draft: false,\n detailedMergeStatus: null,\n };\n\n it.each([\n [{}, null],\n [{detailedMergeStatus: 'MERGEABLE'}, 'readyToMerge'],\n [{detailedMergeStatus: 'DISCUSSIONS_NOT_RESOLVED'}, 'unresolvedDiscussions'],\n [{detailedMergeStatus: 'DRAFT_STATUS'}, 'draft'],\n [{detailedMergeStatus: 'CI_MUST_PASS'}, 'pipelineFailed'],\n [{shouldBeRebased: true}, 'rebase'],\n [{hasConflicts: true}, 'conflicts'],\n [{detailedMergeStatus: 'CHECKING'}, 'checking'],\n [{commitsCount: 0}, 'nothingToMerge'],\n [{commitsCount: 1, branchMissing: true}, 'missingBranch'],\n [{projectArchived: true}, 'archived'],\n ])('should return \"%s\" when called with %p', (expected, input) => {\n const bound = getStateKey.bind(Object.assign({}, context, input));\n expect(bound()).toEqual(expected);\n });\n\n it('returns rebased state key', () => {\n const context = {\n mergeStatus: 'checked',\n autoMergeEnabled: false,\n canMerge: true,\n onlyAllowMergeIfPipelineSucceeds: true,\n isPipelineFailed: true,\n hasMergeableDiscussionsState: false,\n isPipelineBlocked: false,\n canBeMerged: false,\n shouldBeRebased: true,\n projectArchived: false,\n branchMissing: false,\n commitsCount: 2,\n hasConflicts: false,\n draft: false,\n };\n const bound = getStateKey.bind(context);\n\n expect(bound()).toEqual('rebase');\n });\n});\n\n\n```\n\nAlong with an explanation of `it.each`:\n\n> Note that `it.each` is a utility provided by Jest that allows you to write the same test with different inputs and expected results. This can make your tests more concise and easier to read.\n\nOur next steps were to:\n- Paste the output from ChatGPT into the Web IDE.\n- Click the blue “Commit” button to commit the code.\n- Name the branch.\n- Open a merge request.\n\nAll of this can be done inside [GitLab’s Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/) without leaving the browser.\n\n### Examining the results\n\nOnce we opened the merge request, a CI/CD pipeline was created to test the change. Unfortunately, the pipeline jobs for the Jest tests failed because the tests were returning `null` for each case instead of the expected results. We went back to ChatGPT to see if it could help us understand why the test was returning null for all cases. ChatGPT suggested a few different implementations to check to make sure things are defined currently:\n\n> There are a few reasons why the tests in the `it.each` function might be returning null for every case. Here are a few possibilities:\n>\n> If the `getStateKey` function is not implemented correctly, it might always return null, regardless of the input.\n> If the `getStateKey` function relies on certain variables that are not defined in the test cases, it might return null because those variables are undefined.\n> If the context object passed to the `getStateKey` function is not being merged correctly with the input object in the test cases, the function might not have access to all of the necessary information, and it might return null.\n\nWhile ChatGPT couldn’t solve the issue with the returned value directly, it provided a lot of possibilities to look into and offered suggestions of what variables or functions to debug. The suggestions prompted us to add code changes that logged the variable values onto the [JavaScript debug console](https://www.w3schools.com/js/js_debugging.asp), find the implementation of the `getStateKey` function, and figure out why the return value was null. Whenever we came across something unfamiliar in the code, like syntax in the `it.each` that wasn’t familiar, we asked ChatGPT for clarification or a helpful example. Many times throughout this experiment, working with ChatGPT felt like “rubber duck debugging,” but with an AI with which you have to be very specific about your ask.\n\n## What we learned from ChatGPT\n\nIn the end, we weren’t able to figure out why our tests were returning null, so we asked the front-end team if someone could review the code. Senior Frontend Engineer [Angelo Gulina](https://gitlab.com/agulina) reviewed the MR. He found that the solution was actually quite trivial: The order of parameters was inverted, resulting in a comparison that led to null! In his assessment, ChatGPT wasn’t able to provide a working solution, but would be able to provide solutions and ideas to an engineer with some experience with the codebase. It delivered a clean, organized solution and answered the task of combining the tests into an it.each table. It could not, however, catch the actual error (the inversion of parameters) or correctly guess why the tests were returning null.\n\nLet's circle back to the question that started this experiment: Can we use ChatGPT to contribute to GitLab? At this time, we’d say, \"yes,\" and you will need some understanding of the code to complete your solution. Since ChatGPT is a language model trained by OpenAI, it can only answer questions and provide information addressed in the model, which means answers requiring contextual specificity may fall short of what is needed to resolve an issue. However, it’s a tool that can help you if you’re stuck, need more clarification on a code snippet, or are trying to refactor some code. It was fascinating for us to experiment with ChatGPT and we were excited to see what it was capable of. The code provided, however, lacked some of the valuable insight and industry experience that a community of contributors can provide.\n\nAt GitLab, our [community and our open source stewardship](https://about.gitlab.com/company/strategy/#dual-flywheels) are part of our company strategy. Thousands of open source contributors worldwide have helped make GitLab what it is today. We see potential for ChatGPT and similar AI tools, not as a replacement for our community, but a way to make our community more efficient and enable more people to contribute GitLab.\n\n\n\n\n",[797,266,9,775],"tutorial",{"slug":799,"featured":6,"template":685},"can-chatgpt-resolve-gitlab-issues","content:en-us:blog:can-chatgpt-resolve-gitlab-issues.yml","Can Chatgpt Resolve Gitlab Issues","en-us/blog/can-chatgpt-resolve-gitlab-issues.yml","en-us/blog/can-chatgpt-resolve-gitlab-issues",{"_path":805,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":806,"content":812,"config":818,"_id":820,"_type":13,"title":821,"_source":15,"_file":822,"_stem":823,"_extension":18},"/en-us/blog/cern-contributor-post",{"title":807,"description":808,"ogTitle":807,"ogDescription":808,"noIndex":6,"ogImage":809,"ogUrl":810,"ogSiteName":672,"ogType":673,"canonicalUrls":810,"schema":811},"GitLab Code Contributor: Daniel Juarez","Daniel Juarez shares his experience contributing to GitLab from CERN.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673096/Blog/Hero%20Images/contributors-cover.png","https://about.gitlab.com/blog/cern-contributor-post","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab Code Contributor: Daniel Juarez\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2019-06-19\",\n }",{"title":807,"description":808,"authors":813,"heroImage":809,"date":814,"body":815,"category":680,"tags":816},[677],"2019-06-19","\n\nFor this edition of the [GitLab contributor blog posts](/blog/tags.html#contributors), I'm excited to introduce [Daniel Juarez](https://gitlab.com/danieljg) from [CERN](https://home.cern/).\n\n### Can you tell us about you do at CERN and what Geneva is like?\n\nI started working at CERN in September 2017 as an associate for the Version Control Systems team. I came to CERN from the [University of Oviedo](http://www.uniovi.es/en) in Spain, as the university has an arrangement with CERN to give its students an opportunity to work here. One of my main responsibilities is to improve, maintain, and support the GitLab setup at CERN, as well as the continuous integration (CI) infrastructure.\n\n[Geneva](https://www.google.com/maps/place/Geneva,+Switzerland/@46.2050241,6.1089833,13z) feels like an extension of CERN, as you can meet people from all over the world with so many international organizations in the city. It may not be the best place in the winter if you are not into skiing, but the city has a wonderful lake and is full of life in the summer.\n\n![Daniel Juarez](https://about.gitlab.com/images/blogimages/Daniel_Juarez.jpeg){: .shadow.small.right.wrap-text}\n\n### How long have you used GitLab and why did you decide to make contributions?\n\nI first used GitLab when I joined CERN. Contributing to GitLab is part of my job, and [my first merge request (MR)](https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/965) was on [the Runner project](https://gitlab.com/gitlab-org/gitlab-runner).\n\nIn addition to MRs, I create issues and work with the GitLab team to find solutions. A good example is the [storage performance issue](https://gitlab.com/gitlab-org/gitlab-ee/issues/11556) that we ran into recently.\n\n### Do you plan/coordinate contributions to GitLab at CERN or is contribution done on an individual basis? Any advice for GitLab customers who want to make contributions?\n\nWe keep track of our current GitLab issues and improvement areas in our internal Jira instance, and from there we organize who will submit an MR or open an issue with GitLab. We have a few other GitLab contributors at CERN, like [Alex Lossent](https://gitlab.com/alexcern) and [Borja Aparicio](https://gitlab.com/baparici).\n\nIn terms of advice for others, I encourage people to ping GitLab team members, such as product managers or maintainers, if you feel like your MRs or issues are not being picked up in a timely manner. You can find GitLab team members either on the [team page](/company/team/) or the [product categories page](/handbook/product/categories/). It's also helpful to note how many users are being impacted by your issue. Even though only one person from your organization may be commenting on an issue or MR, it could actually have an impact on thousands of people.\n\n### What has been your experience when contributing to GitLab?\n\nGitLab team members are always eager to help. They show interest in community issues and MRs, which is highly appreciated. Engagement from the GitLab team has helped us improve the service we provide to ~16,000 GitLab users at CERN.\n\nHowever, we are concerned about the large number of open issues at GitLab. Even if issues have the `customer` label, we are concerned that sometimes they could be forgotten.\n\n### Are there any community contributions (MRs) to GitLab that you thought were particularly interesting/useful?\n\nFrom CERN, we were definitely happy to have [SAML support](/releases/2015/06/22/gitlab-7-12-released/) a few years ago. We also found [Shared CI Runners for groups](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9646) to be helpful, because some of our users were required to have the same runner registered against multiple projects instead of having it per group. This clearly improved the service for many of our users that rely on private runners and cannot use our shared infrastructure.\n\n### What do you like to do when you're not working?\n\nI love playing video games no matter the genre. Recently, I started watching bad movies and learning to cook new dishes (usually at the same time). I find that cooking helps me digest the bad movies!\n\n### Anything else you want to share with the community?\n\nDo not be afraid to submit MRs! It might look difficult in the beginning, but GitLab team members will do their best to help your changes \"go upstream\" to GitLab. I learned that wider community members are also willing to help.\n\n## Interested in learning how you can contribute?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can contribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n_Note: This post is part of [a series featuring people who contribute to GitLab](/blog/tags.html#contributors)._\n",[266,817,682,9],"collaboration",{"slug":819,"featured":6,"template":685},"cern-contributor-post","content:en-us:blog:cern-contributor-post.yml","Cern Contributor Post","en-us/blog/cern-contributor-post.yml","en-us/blog/cern-contributor-post",{"_path":825,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":826,"content":832,"config":838,"_id":840,"_type":13,"title":841,"_source":15,"_file":842,"_stem":843,"_extension":18},"/en-us/blog/cobol-programmer-shortage",{"title":827,"description":828,"ogTitle":827,"ogDescription":828,"noIndex":6,"ogImage":829,"ogUrl":830,"ogSiteName":672,"ogType":673,"canonicalUrls":830,"schema":831},"How can we help solve the COBOL programmer shortage?","A shortage of COBOL programmers is causing delays in processing unemployment claims and small business loans. We’re hoping our community can help.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667886/Blog/Hero%20Images/cobolshortage.jpg","https://about.gitlab.com/blog/cobol-programmer-shortage","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How can we help solve the COBOL programmer shortage?\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n \"datePublished\": \"2020-04-23\",\n }",{"title":827,"description":828,"authors":833,"heroImage":829,"date":835,"body":836,"category":680,"tags":837},[834],"Valerie Silverthorne","2020-04-23","\n\nIn our current world situation is it any surprise that a shortage of COBOL developers is holding up unemployment benefits and Small Business Association loan processing?\n\nActually, it is kind of surprising. We’ve grown used to the rapid advance of technology and it’s safe to say we’re like most companies – looking forward and not backward.\n\n## COBOL programmers needed\n\nBut it might be time to change that, and we’re reaching out to all of you for ideas and suggestions on ways to help provide a solution to the large number of COBOL programmers needed. What can we, as a community, do to help government agencies overwhelmed with demands on aging mainframes and with too few programmers to get the jobs done?\n\nCNN and a number of other news agencies reported that a lack of COBOL programming expertise has led to [long waits in processing unemployment benefits and small business loans](https://www.techspot.com/news/84796-us-states-desperate-cobol-programmers-ibm-offering-free.html?fbclid=IwAR1M2tlg2MeLHsG7ZzHawzPtsliTBaJX-1EgTlxIdr4BSHihN6sn-JbKpeo) at a time when [joblessness has hit record highs](https://www.washingtonpost.com/business/2020/04/16/unemployment-claims-coronavirus/).\n\n### Oppertunities for COBOL programmers\n\nBut COBOL isn’t limited to government entities: Large financial services and a myriad of other industries are still heavily reliant on mainframes and their primary programming language. As such,there is a large number of COBOL programmers needed with a wide array of oppertunities available. That’s not likely to change anytime soon – IBM says there are 240 billion lines of COBOL running today with an additional 5 billion being written every year.\n\nWhile that may sound like job security, COBOL programming isn’t widely taught today and it certainly lacks the developer interest level of Ruby or TypeScript or Go. A quick search on job site [Glassdoor](https://www.glassdoor.com/) shows about 1700 jobs advertised for COBOL programmers across the US today, while there are well over 4000 potential employers for Go or Ruby developers, and over 30,000 for Java developers.\n\nToday a number of companies [are working to integrate](https://www.rocketsoftware.com/zos-open-source/tools) more \"modern\" software development methodologies with mainframes ([even GitLab](https://gitlab.com/gitlab-org/gitlab-runner/issues/3263)), but that’s not going to solve the short-term need (or probably even the medium-term need).\n\n### Education and Upskilling for COBOL programmers\n\nThere are some educational opportunities available from [Udemy](https://www.udemy.com/course/mainframe-the-complete-cobol-course-from-beginner-to-expert/), [LinkedIn](https://www.linkedin.com/learning/topics/cobol), [Learning Tree](https://www.learningtree.com/courses/2301/enterprise-cobol-programming-part-1/) and a [free COBOL programming course](https://github.com/openmainframeproject/cobol-programming-course) from the openmainframeproject on GitHub.\n\nCan we do more? We don’t have the answers but we’ve opened [a public issue](https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/7271) so please leave any ideas there.\n\n_Updated on June 1, 2020: We've had some responses on our public issue including this from contributor [Timothy Austin](https://gitlab.com/taustin288): \"The companies who hold all these large COBOL code bases need to pressure the universities to require all up and coming Java programmers to have a rudimentary knowledge of COBOL. This would allow them the flexibility to convert the COBOL or continue use it as is if they so desire.\" Learn more in [our issue](https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/7271)._ \n\nCover image by [Joshua Sortino](https://unsplash.com/@sortino) on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[266,9,682],{"slug":839,"featured":6,"template":685},"cobol-programmer-shortage","content:en-us:blog:cobol-programmer-shortage.yml","Cobol Programmer Shortage","en-us/blog/cobol-programmer-shortage.yml","en-us/blog/cobol-programmer-shortage",{"_path":845,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":846,"content":852,"config":862,"_id":864,"_type":13,"title":865,"_source":15,"_file":866,"_stem":867,"_extension":18},"/en-us/blog/configuring-your-cluster-with-kubernetes-integration",{"title":847,"description":848,"ogTitle":847,"ogDescription":848,"noIndex":6,"ogImage":849,"ogUrl":850,"ogSiteName":672,"ogType":673,"canonicalUrls":850,"schema":851},"Heroes journey: Working with GitLab's Kubernetes agent","A tutorial on deploying and monitoring an application in Kubernetes without leaving GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682342/Blog/Hero%20Images/treasure.jpg","https://about.gitlab.com/blog/configuring-your-cluster-with-kubernetes-integration","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab Heroes Unmasked - How I became acquainted with the GitLab Agent for Kubernetes\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Jean-Philippe Baconnais\"}],\n \"datePublished\": \"2022-06-08\",\n }",{"title":853,"description":848,"authors":854,"heroImage":849,"date":856,"body":857,"category":680,"tags":858},"GitLab Heroes Unmasked - How I became acquainted with the GitLab Agent for Kubernetes",[855],"Jean-Philippe Baconnais","2022-06-08","\n\n_A key to GitLab’s success is our vast community of advocates. Here at GitLab, we call these active contributors \"[GitLab Heroes](/community/heroes/).\" Each hero contributes to GitLab in numerous ways, including elevating releases, sharing best practices, speaking at events, and more. Jean-Phillippe Baconnais is an active GitLab Hero, who hails from France. We applaud his contributions, including leading community engagement events. Baconnais shares his interest in Kubernetes and explains how to deploy and monitor an application in Kubernetes without leaving GitLab._ \n\nSince 2007, I’ve been a developer. I’ve learned a lot of things about continuous integration, deployment, infrastructure, and monitoring. In both my professional and personal time, my favorite activity remains software development. After creating a new application with multiple components, I wanted to deploy it on Kubernetes, which has been really famous over the last few years. This allows me to experiment on this platform. This announces a lot of very funny things. I know some terms, I used them in production for five years. But as a user, Kubernetes Administration is not my “cup of tea” 😅.\n\n## My first deployment in Kubernetes\n\nWhen I decided to deploy an application on Kubernetes, I wasn’t sure where to start until I saw, navigating in my project in GitLab, a menu called “Kubernetes.\" I wanted to know what GitLab was hiding behind this. Does this feature link my project’s sources to a Kubernetes cluster? I used the credit offered by Google Cloud to discover and test this platform. \n\nDeploying my application on Kubernetes was easy. I wrote [a blog post](https://dev.to/jphi_baconnais/deploy-an-quarkus-application-on-gke-with-gitlabci-lgp) in 2019 describing how I do this, or rather, how GitLab helped me to create this link so easily. In this blog post I will explain further and talk about what’s changed since then.\n\nBehind the “Kubernetes” menu, GitLab helps you integrate Kubernetes into your project. You can create, from GitLab, a cluster on Google Cloud Platform (GCP), and Amazon Web Services (AWS). If you already have a cluster on this platform or anywhere else, you can connect to it. You just need to specify the cluster name, Kubernetes API UR, and certificate.\n\n![Connect cluster](https://about.gitlab.com/images/blogimages/baconcreatecluster.png){: .shadow}\n\nGitLab is a DevOps platform and in the list of DevOps actions, there is the monitoring part. \n\n![Chart of GitLab stages](https://about.gitlab.com/images/blogimages/baconstreamline.png){: .shadow}\n\nGitLab deploys an instance of Prometheus to get information about your cluster and facilitate the monitoring of your application.\n\nFor example, you can see how many pods are deployed and their states in your environment. You can also view some charts and information about your cluster, like memory and CPU available. All these metrics are available by default without changing the application of your cluster. We can also read the logs directly in GitLab. For a developer, it’s great to have all this information on the same tool and this allows us to save time. \n\n![Pod deployment](https://about.gitlab.com/images/blogimages/baconhealth.png){: .shadow}\n\n\n## A new way to integrate Kubernetes\n\nEverything I explained in the previous chapter doesn’t quite exist anymore. The release of GitLab 14.5 was the beginning of a revolution. The Kubernetes integration with certificates has limitations on security and many issues were created. GitLab teams worked on a new way to rely on your cluster. And in Version 14.5, the [GitLab Agent for Kubernetes](https://docs.gitlab.com/ee/user/clusters/agent/) was released! \n\n## GitLab Agent for Kubernetes\n\nGitLab Agent for Kubernetes is a new way to connect to your cluster. This solution is easy to explain: An agent installed on your cluster communicates with your GitLab instance with [gRPC](https://grpc.io/) protocol. Your agent offers you useful GitOps features I will explain later. The next picture shows you the GitLab Agent for Kubernetes architecture (from GitLab). \n\n![GitLab Agent for Kubernetes flow chart](https://about.gitlab.com/images/blogimages/baconkubernetesflowchart.png){: .shadow}\n\n### GitOps defined\n\nLet’s quickly define the term “[GitOps](/topics/gitops/)”: It’s a way to manage your infrastructure as code, in a Git project. For me, there are two aspects in GitOps: “pull” and “push” mode. \n\n- Push mode is when your Git project activates the upgrade of your infrastructure following a change. \n- Pull mode is when your infrastructure verifies without interruption of your Git project and applies changes automatically.\n\nAnd GitLab chose the latter mode for their solution of GitLab Agent for Kubernetes. Indeed, your agent available on your cluster will check frequently if your project changes. The gRPC protocol is great to respect this intent. When you push a modification on your project, agents detect it automatically, and then your cluster upgrades.\n\n### How the GitLab Agent for Kubernetes works\n\nThere are some actions to do to install and have a GitLab Agent for Kubernetes available on your project. \n\nFirst, if you create a new project on GitLab, you can use the template “Management cluster,” which allows the initialization of files. These files allow you to have examples of: \n- a declaration of an agent\n- a list of starter kits to install DevOps tools\n\nGitLab is a DevOps platform that wants to help you to configure all steps of the lifecycle of your project. You can find the configuration of tools like Prometheus, Sentry, Ingress, etc. I will detail this later.\n\n### The evolution of GitLab Agent for Kubernetes\n\nBefore explaining more details about this agent, you have to know one thing. This product is in constant evolution and your feedback is welcome in [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/342696#note_899701396) to improve it. The roadmap is available and each version gives some information about its evolution.\n\n## How to use GitLab Agent for Kubernetes\n\nCreating an agent is simple. You have to create a file in the directory .gitlab/agents/\u003Cnameofyouragent>/config.yaml. \n\n\n![Connect cluster](https://about.gitlab.com/images/blogimages/baconstructure.png)\n\n\nThe default configuration should contain:\n- your project id, represented by your \u003Cuser or group>/project\n- a namespace by default to deploy applications if it’s not present in your yaml files\n- path of your yaml file to apply. This can be a specific file, a directory, or a pattern of files\n- level of debug\n\n```\n\ngitops:\n manifest_projects:\n - id: xxxxx/demo-gitlab-kubernetes-cluster-management\n default_namespace: gitlab-kubernetes-agent-demo\n paths:\n - glob: 'deploy.yaml'\nobservability:\n logging:\n level: debug\n\n```\n\nYou can add security to this configuration file with the “ci_access” property. For example, it allows developers to avoid destroying the Kubernetes infrastructure 😅. I didn’t explore in detail this part yet. \n\nAll configuration options are available on [this reference page](https://docs.gitlab.com/ee/user/clusters/agent/gitops.html#gitops-configuration-reference). \n\nAfter creating and pushing your file in your project, you have to register your agent. And this action takes two seconds on the GitLab UI. \n\n![Add an agent](https://about.gitlab.com/images/blogimages/baconaddanagent.png){: .shadow}\n\nOn the next step, GitLab gives you the Docker command to install your agent on your cluster. For example:\n\n```\n\ndocker run --pull=always --rm \\\n registry.gitlab.com/gitlab-org/cluster-integration/gitlab-agent/cli:stable generate \\\n --agent-token=\u003Cyour token generated by GitLab> \\\n --kas-address=wss://kas.gitlab.com \\\n --agent-version stable \\\n --namespace gitlab-kubernetes-agent | kubectl apply -f -\n\n```\nYou can copy-paste this command on your cluster and your agent will be available in a Kubernetes namespace. You can see on the GitLab UI that the link with the agent is successful.\n\n![Link with agent success](https://about.gitlab.com/images/blogimages/baconagentk.png){: .shadow}\n\n\nYou can also verify this connection in logs of agent container: \n\n```\n\n{\"level\":\"debug\",\"time\":\"2022-xx-xxT14:11:57.517Z\",\"msg\":\"Handled a connection successfully\",\"mod_name\":\"reverse_tunnel\"} \n\n```\n\n### GitLab cluster management \n\nGitLab is a DevOps platform and uses tiers of applications to manage all the steps of a modern DevOps pipeline. The “Monitor” part in GitLab is based on some tools such as [Prometheus](https://prometheus.io/docs/visualization/grafana/),[Sentry](https://sentry.io/), [Vault](https://www.vaultproject.io/), etc. To help you, GitLab created the template [GitLab Cluster Management]( https://gitlab.com/gitlab-org/project-templates/cluster-management), which gives you a basic configuration of these tools.\n\nTo install these tools, a `.gitlab-ci.yml` file is created and defines a job to deploy them with helmfile configuration. All these tools, contained in the directory named “applications,” can be overridden or customized in `values.yaml` file. \n \nAnd for my experimentation, I used this template and applied a small change to have an external IP address for the Prometheus instance. After registering this external IP in GitLab (Menu Settings > Monitor > Alerts), the Monitor menu has data. We can check information about any pods deployed on my cluster. \n\n![Agent graph](https://about.gitlab.com/images/blogimages/baconagentgraph.png){: .shadow}\n\n## The GitOps aspect \n\nThe GitOps aspect can be verified quickly. If you choose to specify one manifest file defining an application deployment, a modification on this file implies an automatic deployment on your cluster. Without CI! This allows us to have a faster deployment than if we passed with a pipeline. The new features or fixes will be deployed faster on your infrastructures. And if you use the free version of GitLab, your deployment will not count in your CI quota. \n\nAfter a commit, the agent detects it and we can see the commit id in the agent logs.\n\n```\n{\"level\":\"info\",\"time\":\"2022-04-11T15:22:44.049Z\",\"msg\":\"Synchronizing objects\",\"mod_name\":\"gitops\",\"project_id\":\"jeanphi-baconnais/demo-gitlab-kubernetes-cluster-management\",\"agent_id\":12804,\"commit_id\":\"e2a82fe6cc82fa25e8d5a72584774f4751407558\"}\n\n```\n\n## CI/CD tunnel\n\nAnother feature that comes with the GitLab Agent for Kubernetes is the CI/CD tunnel. Your agent facilitates the interaction with your cluster. You just have to define a KUBE_CONTEXT variable referencing the path of your agent. \n\n```\nvariables:\nKUBE_CONTEXT: \"xxxxx/demo-gitlab-kubernetes-cluster-management:agentk\"\n\n```\n\nAnd actions on your cluster are available without secret configuration or anything else. If you want to execute `kubectl` commands, you can easily use this job:\n\n```\n\ntest-cicd-tunnel:\n stage: test\n extends: [.kube-context]\n image:\n name: bitnami/kubectl:latest\n entrypoint: [\"\"]\n script:\n - kubectl get ns\n when: manual\n\n```\n\n## What's next\n\nCurrently, GitLab Agent for Kubernetes doesn’t allow you to get information about the state of pods on your cluster’s environment page.\n\n![Success](https://about.gitlab.com/images/blogimages/baconci.png){: .shadow}\n\nBut GitLab wants to offer the same level of service as the certificate integration. So, check the roadmap ([in this issue](https://gitlab.com/groups/gitlab-org/-/epics/3329)) and the contents of each release. The template Cluster Management is in progress, too. Some issues will give new features for configuration tools.\n\nThis experience was so rewarding for me. I would deploy a project on Google Cloud, and I discovered a new method. I saw this agent described in [GitLab 14.5](/releases/2021/11/22/gitlab-14-5-released/) but I didn’t imagine the impact it can have on a project. \n\nMy colleague [Eric Briand](https://twitter.com/eric_briand) and I had the opportunity to speak about this subject at [Malt Academy sessions](https://www.malt-academy.com/) and [Meetup GitLab France](https://www.meetup.com/GitLab-Meetup-France/events/283917115). I will continue to experiment with this agent and try different options for this wonderful product! \n\n**This blog post and linked pages contain information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this video/blog post and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.**\n\nCover image by [Ashin K Suresh](https://unsplash.com/photos/mkxTOAxqTTo) on Unsplash.\n{: .note}\n",[859,266,860,861,9],"kubernetes","user stories","growth",{"slug":863,"featured":6,"template":685},"configuring-your-cluster-with-kubernetes-integration","content:en-us:blog:configuring-your-cluster-with-kubernetes-integration.yml","Configuring Your Cluster With Kubernetes Integration","en-us/blog/configuring-your-cluster-with-kubernetes-integration.yml","en-us/blog/configuring-your-cluster-with-kubernetes-integration",{"_path":869,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":870,"content":875,"config":880,"_id":882,"_type":13,"title":883,"_source":15,"_file":884,"_stem":885,"_extension":18},"/en-us/blog/contributor-post-hannes",{"title":871,"description":872,"ogTitle":871,"ogDescription":872,"noIndex":6,"ogImage":809,"ogUrl":873,"ogSiteName":672,"ogType":673,"canonicalUrls":873,"schema":874},"GitLab Code Contributor: Hannes Rosenögger","Core team member Hannes Rosenögger shares his experience contributing to GitLab since 2014.","https://about.gitlab.com/blog/contributor-post-hannes","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab Code Contributor: Hannes Rosenögger\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2018-11-20\",\n }",{"title":871,"description":872,"authors":876,"heroImage":809,"date":877,"body":878,"category":680,"tags":879},[677],"2018-11-20","\nFor this month's blog post, we're featuring another [Core Team](/community/core-team/) member [Hannes Rosenögger](https://gitlab.com/haynes).\n\n### When did you first contribute to GitLab?\n\nMy first [MR to close multiple issues with one commit](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/263) was back in December 2014. So that's almost four years ago!\n\n### Why and how did you decide to contribute to GitLab?\n\n I used the Community Edition privately and noticed that mentioning multiple issues in an MR only closed the first issue. Since GitLab was open source and the fix was easy, I decided to fix it myself. GitLab's open policy about everything within the company was also a huge factor.\n\n### Which area(s) of the GitLab product have you been contributing to?\n\nI guess it's been pretty random for me. Most of my contributions have been on the backend side and documentation fixes, but if I see something that I can easily fix or I need a feature for my work, I try to make a contribution. I also provide support on the #gitlab IRC channel on freenode. My IRC handle is `haynes`.\n\n### Can you tell us what you do professionally?\n\nI am a Java software developer for a public sector organization in Germany.\n\n### What do you like to do when you're not working?\n\nWhen I'm not working, I'm probably doing something for my local scout group. I enjoy working with the kids and teaching. I also like to fix things from coffee machines to cars. Basically anything that I can fix with a bit of work.\n\n\u003C!-- carousel -->\n\n\u003Cdiv id=\"carousel-example-generic-5\" class=\"carousel slide medium center\" data-ride=\"carousel\" data-interval=\"10000\">\n \u003C!-- Indicators -->\n \u003Col class=\"carousel-indicators\">\n \u003Cli data-target=\"#carousel-example-generic-5\" data-slide-to=\"0\" class=\"active\">\u003C/li>\n \u003Cli data-target=\"#carousel-example-generic-5\" data-slide-to=\"1\">\u003C/li>\n \u003Cli data-target=\"#carousel-example-generic-5\" data-slide-to=\"2\">\u003C/li>\n \u003C/ol>\n\n \u003C!-- Wrapper for slides -->\n \u003Cdiv class=\"carousel-inner\" role=\"listbox\">\n \u003Cdiv class=\"item active\">\n \u003Cimg src=\"/images/blogimages/Hannes-blogpost/workbench.jpg\" alt=\"Hannes on workbench\">\n \u003C/div>\n \u003Cdiv class=\"item\">\n \u003Cimg src=\"/images/blogimages/Hannes-blogpost/dishwasher.jpg\" alt=\"Hannes working on his dishwasher\">\n \u003C/div>\n \u003Cdiv class=\"item\">\n \u003Cimg src=\"/images/blogimages/Hannes-blogpost/washing_machine.jpg\" alt=\"Washing machine repair\">\n \u003C/div>\n\n \u003C/div>\n\n \u003C!-- Controls -->\n \u003Ca class=\"left carousel-control\" href=\"#carousel-example-generic-5\" role=\"button\" data-slide=\"prev\">\n \u003Csvg class=\"glyphicon glyphicon-chevron-left\" width=\"11\" height=\"19\" viewBox=\"0 0 11 19\" xmlns=\"http://www.w3.org/2000/svg\">\u003Cpath d=\"M.44 10.13l8.345 8.345 2.007-2.007-6.814-6.814 6.814-6.815L8.785.832.44 9.177a.652.652 0 0 0-.202.477c0 .183.067.343.202.477z\" fill-rule=\"evenodd\"/>\u003C/svg>\n \u003Cspan class=\"sr-only\">Previous\u003C/span>\n \u003C/a>\n \u003Ca class=\"right carousel-control\" href=\"#carousel-example-generic-5\" role=\"button\" data-slide=\"next\">\n \u003Csvg class=\"glyphicon glyphicon-chevron-right\" width=\"11\" height=\"19\" viewBox=\"0 0 11 19\" xmlns=\"http://www.w3.org/2000/svg\">\u003Cpath d=\"M10.59 10.13l-8.344 8.345L.24 16.468l6.814-6.814L.24 2.839 2.246.832l8.345 8.345a.652.652 0 0 1 .201.477.652.652 0 0 1-.201.477z\" fill-rule=\"evenodd\"/>\u003C/svg>\n \u003Cspan class=\"sr-only\">Next\u003C/span>\n \u003C/a>\n\u003C/div>\n\n### What advice do you have for others who may be interested in contributing to GitLab?\n\nContributing to GitLab is easier than it looks at a first glance and you can contribute to the community in many different ways. For example, if you want to help out translating the GitLab user interface to your native language on [CrowdIn](https://translate.gitlab.com/), this does not require programming skills or any special setup on your laptop. Also when you want to contribute code, reviewers are normally quite fast in getting back to you and are more than happy to help if you have any questions.\n\nIf you are unsure how to get started or you need help, anyone should feel free to ping me on Twitter ([@hrosenoegger](https://twitter.com/hrosenoegger)) or in the #gitlab IRC channel on [freenode](http://freenode.net/).\n\n### Anything else you want to share with the community?\n\nI love the fact that GitLab actually listens to the community. Even after they make a decision to add a new, paid feature, when community members believe it makes more sense to have the feature in [GitLab Core](/pricing/#self-managed) or the free tier of [GitLab.com](/pricing/), they will actually port it back. The [Squash and Merge feature](/releases/2018/06/22/gitlab-11-0-released/#squash-and-merge-in-gitlab-core-and-gitlabcom-free) is a good example of that.\n\n## Interested in learning how you can contribute?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can contribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n_Note: This post is part of [a series featuring people who contribute to GitLab](/blog/tags.html#contributors)._\n",[266,817,682,9],{"slug":881,"featured":6,"template":685},"contributor-post-hannes","content:en-us:blog:contributor-post-hannes.yml","Contributor Post Hannes","en-us/blog/contributor-post-hannes.yml","en-us/blog/contributor-post-hannes",{"_path":887,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":888,"content":893,"config":898,"_id":900,"_type":13,"title":901,"_source":15,"_file":902,"_stem":903,"_extension":18},"/en-us/blog/contributor-post-jacopo",{"title":889,"description":890,"ogTitle":889,"ogDescription":890,"noIndex":6,"ogImage":809,"ogUrl":891,"ogSiteName":672,"ogType":673,"canonicalUrls":891,"schema":892},"GitLab Code Contributor: Jacopo Beschi","Core Team member Jacopo Beschi shares why he loves contributing to GitLab.","https://about.gitlab.com/blog/contributor-post-jacopo","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab Code Contributor: Jacopo Beschi\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2018-09-06\",\n }",{"title":889,"description":890,"authors":894,"heroImage":809,"date":895,"body":896,"category":680,"tags":897},[677],"2018-09-06","\n\nThis is the second blog post [highlighting GitLab community members](/blog/contributor-post-vitaliy/)\nwho are making code contributions to GitLab. This month, we're featuring Jacopo\nBeschi, who is based in Italy and is also a member of the [Core Team](/community/core-team/).\n\n### How long have you been contributing to GitLab?\n\nI've been contributing since late 2016.\n\n### Why and how did you decide to contribute to GitLab?\n\nI was looking for an interesting open source software application mostly written\nin Ruby to contribute to. After some Googling around, I found GitLab and instantly\nfell in love with the application and this community.\n\n### Which areas of the GitLab product do you contribute to?\n\nI've contributed to multiple areas of GitLab, such as [backend](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18757),\n[frontend](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9890),\n[API](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/16478),\n[Utility](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/11579),\nand [Quality](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15188)\nwhich are written in Rails.\n\nI haven’t had a chance to contribute to the Golang part of GitLab, such as\n[GitLab Runner](https://docs.gitlab.com/runner/), [Gitaly](https://docs.gitlab.com/ee/administration/gitaly/),\nor [GitLab Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse).\n\n### Can you tell us what you do professionally?\n\nCurrently, I work as technical lead for [Iubenda](http://www.iubenda.com), a SaaS\nprovider focused on privacy and cookie policies.\n\n### What do you like to do when you're not working?\n\nWhen I’m not working, I enjoy training in the gym and spending time with my wife and friends.\n\n### What advice do you have for others who may be interested in contributing to GitLab?\n\nDon’t be nervous about getting started! This [Contributing to GitLab page](/community/contribute/)\nexplains all the steps you need to take in order to be a successful contributor,\nand I encourage people to start there.\n\nGitLab also has a lot of [online documentation](https://docs.gitlab.com/) that\nyou could search in order to solve most common questions that developers have.\n\n### Do you have anything else you’d like to share?\n\nContributing to GitLab not only enhances your resume but also allows you to get\nin touch with great people who can help you improve your technical knowledge.\nIn addition, your contribution to GitLab will affect the lives of thousands of\ndevelopers around the globe!\n\n## Interested in learning how you can contribute?\n\nAs Jacopo already suggested, a good place to start is the\n[Contributing to GitLab page](/community/contribute/), where you can learn how you can\ncontribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n_Note: This post is part of [a series featuring people who contribute to GitLab](/blog/tags.html#contributors)._\n",[266,817,682,9],{"slug":899,"featured":6,"template":685},"contributor-post-jacopo","content:en-us:blog:contributor-post-jacopo.yml","Contributor Post Jacopo","en-us/blog/contributor-post-jacopo.yml","en-us/blog/contributor-post-jacopo",{"_path":905,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":906,"content":911,"config":916,"_id":918,"_type":13,"title":919,"_source":15,"_file":920,"_stem":921,"_extension":18},"/en-us/blog/contributor-post-luke",{"title":907,"description":908,"ogTitle":907,"ogDescription":908,"noIndex":6,"ogImage":809,"ogUrl":909,"ogSiteName":672,"ogType":673,"canonicalUrls":909,"schema":910},"GitLab Code Contributor: Luke Picciau","New contributor Luke Picciau shares why he started contributing to GitLab.","https://about.gitlab.com/blog/contributor-post-luke","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab Code Contributor: Luke Picciau\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2018-10-04\",\n }",{"title":907,"description":908,"authors":912,"heroImage":809,"date":913,"body":914,"category":680,"tags":915},[677],"2018-10-04","\nFor this month's blog post, we're featuring a new contributor [Luke Picciau](https://gitlab.com/Qwertie), who started contributing to GitLab a few months ago.\n\n### When did you first contribute to GitLab?\nMy first contribution was in July 2018, with my MR to [add a button for regenerating 2FA codes](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20295).\n\n### Why and how did you decide to contribute to GitLab?\nI have been using GitLab pretty heavily since 2014. I decided to start contributing in order to practice developing features on a large project. Because I am very familiar with features of GitLab from the user perspective, navigating the code was easy and I was able to start adding new features quickly.\n\n### Which area(s) of the GitLab product are you interested in contributing to?\nI’d love to look into the new [Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/) and see what improvements could be made, as I see this as a useful tool. Personally, I’d like to use it to write posts for my static site and see the compiled result in my browser as well.\n\n### Can you tell us what you do professionally (or academically if you're going to school)?\nI am a full stack web developer. I primarily use Rails and VueJS. Currently I am also studying for a Bachelor of Information Technology at the University of South Australia. I’m also building an open source website for fitness tracking and analytics of GPS recordings. It’s not quite ready to use yet, but I am pushing regular updates to [the repo](https://gitlab.com/pikatrack/pikatrack).\n\n### What do you like to do when you're not working or studying?\nI’ll often be helping open source projects such as mapping the local area on [Open Street Map](https://www.openstreetmap.org). I also love to go down to the mountain bike parks around Adelaide.\n\n### Can you tell us where you live and what you like about your area?\nI live in [Adelaide, South Australia](https://www.google.com/maps/place/Adelaide+SA,+Australia/@-35.0278392,134.1260638,6z/). My favorite thing about the area is living close to so many national parks and amazing mountain bike trails which give endless exploration possibilities.\n\n![Luke on his mountain bike](https://about.gitlab.com/images/blogimages/Luke_Picciau_mountain_biking_new.jpg){: .shadow.small.center}\n\n### What advice do you have for others who may be interested in contributing to GitLab?\nOne of the things I find most useful is using an IDE or text editor with “go to definition” support. This allows you to click on function and class names and be taken to the place where they are defined. This, in my opinion, is an essential feature for working on a codebase as large as GitLab, especially in a language like Ruby, where it can be difficult to work out where things have been imported from. I personally use [RubyMine](https://www.jetbrains.com/ruby/), but I have been told [Vim](https://www.vim.org/) can also be set up with good Ruby support. Another tip I have is if you get part way through making a change and get stuck on something or need advice on what should be done, commit the changes and [create a merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#doc-nav) with what you have done and any questions you have. Someone should reply to the merge request to help you get the changes finished and ready for merge.\n\n## Interested in learning how you can contribute?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can contribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n_Note: This post is part of [a series featuring people who contribute to GitLab](/blog/tags.html#contributors)._\n",[266,817,682,9],{"slug":917,"featured":6,"template":685},"contributor-post-luke","content:en-us:blog:contributor-post-luke.yml","Contributor Post Luke","en-us/blog/contributor-post-luke.yml","en-us/blog/contributor-post-luke",{"_path":923,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":924,"content":929,"config":934,"_id":936,"_type":13,"title":937,"_source":15,"_file":938,"_stem":939,"_extension":18},"/en-us/blog/contributor-post-siemens",{"title":925,"description":926,"ogTitle":925,"ogDescription":926,"noIndex":6,"ogImage":809,"ogUrl":927,"ogSiteName":672,"ogType":673,"canonicalUrls":927,"schema":928},"GitLab Code Contributor: Alexis Reigel","Alexis Reigel shares his experience as a GitLab contributor on behalf of Siemens.","https://about.gitlab.com/blog/contributor-post-siemens","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab Code Contributor: Alexis Reigel\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2018-12-18\",\n }",{"title":925,"description":926,"authors":930,"heroImage":809,"date":931,"body":932,"category":680,"tags":933},[677],"2018-12-18","\nFor this month's blog post, we're featuring [Alexis Reigel](https://gitlab.com/koffeinfrei). Alexis was also an [MVP for GitLab 9.5 and 10.8](/community/mvp/).\n\n![Alexis Reigel](https://about.gitlab.com/images/blogimages/Alexis_Reigel.jpeg){: .shadow.small.center}\n\n### How did you get involved with contributing to GitLab?\n\nMy Siemens colleagues have been using GitLab since 2013 with [GitLab 5.2](/releases/2013/05/22/gitlab-5-dot-2-released/). The *[upstream first](https://www.redhat.com/blog/verticalindustries/why-upstream-contributions-matter-when-developing-open-source-nfv-solutions/)* principle is important at Siemens, as they don't want to maintain local patches/forks of software. I was hired to contribute features to GitLab that are needed at Siemens, and this give-and-take process between contributors and users is what is great about open source software. My first contribution was the ability to add a [custom brand header logo in emails](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/9049), which I created on Feb. 7, 2017 and was merged on Feb. 22, 2017.\n\n### What was your experience with the first merged MR?\n\nThere was no controversy with my first MR, and therefore not much debate before it was merged. The review was very quick and the relevant people chimed in right from the start. For some of the later, more complicated merge requests, it was not always this straightforward. Depending on how complicated the MR is and how many people from GitLab participate, the process may take longer and generate a lot of discussions.\n\n### What advice do you have for others who may be interested in contributing to GitLab? In particular, any insights you can share with current GitLab customers who may be thinking about making code contributions?\n\nFirst, I recommend reviewing existing MRs and issues before submitting an MR. In many cases, there are already discussions and potential solutions for a certain feature or bug fix. It's also helpful to find out [who from GitLab](/company/team/) is relevant or responsible for a certain area so you can ping the right person from the start.\n\nThe initial contribution should always be a minimal solution or what GitLab calls a [\"Minimum Viable Change (MVC)\"](/handbook/product/product-principles/#the-minimal-viable-change-mvc), because the solution will often change with feedback. The initial contribution should be considered a starting point for collaboration between the contributor and GitLab team-members.\n\nIn some cases, a contributor may need to be patient with their MR, as depending on the topic and complexity it may take some time to move things forward. The people from GitLab are always very kind and friendly so the discussions are respectful.\n\n### Do you have other colleagues at Siemens who also contribute to GitLab? How do you go about planning and working on your contributions?\n\nYes, there are several colleagues who are active within the GitLab community and you will see [Siemens mentioned in MRs](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/?scope=all&utf8=%E2%9C%93&state=merged&search=siemens).\n\nMy Siemens colleagues collect issues and feature requests internally and prioritize them based on how important and urgent they are. After discussing feature requests with coworkers to make sure we have a common understanding of the intended functionality, I start to work on the issues according to their priority. I have a lot of freedom and trust from Siemens on what the solution I contribute should look like.\n\n### What do you like to do when you're not working?\n\nI work on several other free and open source projects such as [Metaflop](https://www.metaflop.com/), [Mykonote](https://github.com/panter/mykonote/blob/master/README.md), and others in my spare time. Apart from that, I like spending time with my family and friends. If there's any time left, I make and listen to music or watch a movie or two.\n\n### Anything else you want to share with the community?\n\nGitLab is a great product and is one of the friendliest and healthiest open source communities. Contributing to such a large project may seem daunting at first, but will pay off in the end. Your contribution will be appreciated by GitLab team-members as well as everyone who uses the product.\n\n## Interested in learning how you can contribute?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can contribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n_Note: This post is part of [a series featuring people who contribute to GitLab](/blog/tags.html#contributors)._\n",[266,817,682,9],{"slug":935,"featured":6,"template":685},"contributor-post-siemens","content:en-us:blog:contributor-post-siemens.yml","Contributor Post Siemens","en-us/blog/contributor-post-siemens.yml","en-us/blog/contributor-post-siemens",{"_path":941,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":942,"content":947,"config":952,"_id":954,"_type":13,"title":955,"_source":15,"_file":956,"_stem":957,"_extension":18},"/en-us/blog/contributor-post-vitaliy",{"title":943,"description":944,"ogTitle":943,"ogDescription":944,"noIndex":6,"ogImage":809,"ogUrl":945,"ogSiteName":672,"ogType":673,"canonicalUrls":945,"schema":946},"GitLab Code Contributor: Vitaliy Klachkov","Core Team member Vitaliy Klachkov shares how he started contributing to GitLab.","https://about.gitlab.com/blog/contributor-post-vitaliy","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab Code Contributor: Vitaliy Klachkov\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2018-08-08\",\n }",{"title":943,"description":944,"authors":948,"heroImage":809,"date":949,"body":950,"category":680,"tags":951},[677],"2018-08-08","\nWelcome to our new blog series featuring code contributors from the GitLab community! This blog will highlight the wonderful contributions made by GitLab community members and will hopefully inspire others to contribute to GitLab. For the first blog post, we are happy to welcome [Vitaliy “blackst0ne” Klachkov](https://gitlab.com/blackst0ne), who has been chosen as a [release MVP](/community/mvp/) three times!\n\n### How long have you been contributing to GitLab?\n\nI've been contributing since August 2016.\n\n### Why and how did you decide to contribute to GitLab?\n\nI read a news article about a new GitLab release and I didn’t even know what GitLab was back then. There was also a discussion on an example of a Rails-based project with a good codebase, and people suggested taking a look at GitLab.\n\nI was intrigued and decided to take a closer look at GitLab. I actually found\nroom for improvement in the codebase so I started pushing a few merge requests (MRs). I received responses within 1-2 days and I was very impressed. With some of the other communities, I’m used to waiting weeks for feedback.\n\nSo, I kept submitting more merge requests and so far, I have 227 merged MRs. I’m proud that I’m one of the top 50 contributors among 2000+ GitLab [code contributors](http://contributors.gitlab.com/) that include GitLab employees.\n\n### Which areas of the GitLab product do you contribute to?\n\nMostly it has been backend changes, but many of my MRs touched the frontend as well. I spent my time bringing popular features (e.g. [squash and merge to CE](https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html#doc-nav), [mermaid support](https://docs.gitlab.com/ee/user/markdown.html#mermaid), [switch markdown engine to CommonMark](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/14835), [customizable branch name from issues](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/13884), etc.), fixing technical debts (e.g. [migrate all spinach specs to rspec](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?scope=all&utf8=%E2%9C%93&state=all&author_username=blackst0ne&label_name%5B%5D=technical%20debt&label_name%5B%5D=Quality&search=Spinach)), upgrading [GitLab to Rails 5.0](https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=all&utf8=%E2%9C%93&state=all&author_username=blackst0ne&label_name%5B%5D=rails5), and many other improvements.\n\n### Can you tell us what you do professionally?\n\nI am a full-stack web developer at [GEOPHYSTECH LLC](https://geophystech.ru/). The company is focused on seismology, earthquakes, and everything related to earthquake hazards.\n\n### What do you like to do when you're not working?\n\nI’m a big fan of sports or anything that keeps my body moving, such as running, swimming, snowboarding, table tennis, volleyball, ice-blading, football, CrossFit workout, etc.\n\nI also enjoy [chess](https://lichess.org/), reading books/articles, and UX-related things. I’ve been collaborating with GitLab’s UX team.\n\n### What advice do you have for others who may be interested in contributing to GitLab?\n\nContributing to GitLab is easy. If you want the experience of being a part of a popular open source project, you are more than welcome to join the GitLab community! You can also ping me on [Twitter](https://twitter.com/blackst0ne) if you have any questions or need any help as you get started.\n\n### Do you have anything else you’d like to share?\n\nGitLab has some nice [swag](https://shop.gitlab.com/)! I’ve gotten some great ones for my release MVPs.\n\n## Interested in learning how you can contribute?\n\nA good place to start would be the [Contributing to GitLab page](/community/contribute/), where you can learn how you can contribute to GitLab code, documentation, and translation.\n\n_Note: This post is part of [a series featuring people who contribute to GitLab](/blog/tags.html#contributors)._\n",[266,817,682,9],{"slug":953,"featured":6,"template":685},"contributor-post-vitaliy","content:en-us:blog:contributor-post-vitaliy.yml","Contributor Post Vitaliy","en-us/blog/contributor-post-vitaliy.yml","en-us/blog/contributor-post-vitaliy",{"_path":959,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":960,"content":965,"config":971,"_id":973,"_type":13,"title":974,"_source":15,"_file":975,"_stem":976,"_extension":18},"/en-us/blog/creationline-post",{"title":961,"description":962,"ogTitle":961,"ogDescription":962,"noIndex":6,"ogImage":809,"ogUrl":963,"ogSiteName":672,"ogType":673,"canonicalUrls":963,"schema":964},"Meet Creationline team members who contribute to GitLab","Creationline contributes to GitLab as a reseller. Three team members explain how it works.","https://about.gitlab.com/blog/creationline-post","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Meet Creationline team members who contribute to GitLab\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2019-11-27\",\n }",{"title":961,"description":962,"authors":966,"heroImage":809,"date":967,"body":968,"category":680,"tags":969},[677],"2019-11-27","\nFor this edition of the [GitLab contributor blog posts](/blog/tags.html#contributors), I'm\nexcited to introduce Creationline, which is a [GitLab reseller in Japan](/resellers/creationline/). As you read this blog post, you will find Creationline is not a typical reseller. Their team were able to help both their customers and the GitLab community through their contributions. Here's what three Creationline employees had to share with us. \n\n## Decision to partner with Gitlab and contributing as a reseller\n#### [Jean-Baptiste Vasseur](https://gitlab.com/jvasseur), Agile Coach and DevOps Consultant \n\nWhen we explored the [DevOps](/topics/devops/) landscape about 3 years ago, we accidentally came across [GitLab’s handbook](/handbook/). This was a revelation for us! Pushing transparency to a point where job applicants know how GitLab members are expected to behave with candidates, a company culture where people are not afraid to communicate their failures, published company business targets and how the team is planning to achieve them, and of course how an open source software philosophy applied to every aspect of GitLab. We felt connected to so many aspects of GitLab’s company culture that I wanted to find a way to work together.\n\nAs [Creationline](http://www.creationline.com/gitlab) was already reselling licenses for other cloud and DevOps companies, and as GitLab was looking for more partners in different countries at that time, we felt confident we had a very good match and started distributing GitLab licenses in June, 2017.\n\nI usually invest a lot of my time prospecting clients, providing technical and value chain consulting, and contributing to the local community by co-organizing meetups and delivering CI/CD workshops. While I also love writing code – I come from an engineering background – it's a challenge to find the time to make open source contributions. However, while I was consulting for a large IT firm that was developing an internal DevOps package built around GitLab, I had an opportunity to make a valuable contribution to GitLab on the company's behalf. The team had a lot of passion for the project and loved working with the GitLab product, but they got blocked by a missing API and were not comfortable enough with their English to open a merge request.\n\nAs consultants, we did not have the responsibility of adding features or fixing issues on GitLab, but I really wanted to help our client. I explored the source code, figured out the pattern/coding style, and opened my first [merge request](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/22296). Review happened almost immediately, and GitLab team members were very nice and also challenged me to apply some refactoring, which helped me learn even more about the source code.\n\n![Open Source Summit Japan, 2019](https://about.gitlab.com/images/blogimages/creationline-blogpost/Creationline-OSS-Japan.jpg){: .shadow.medium.center}\nCreationline and GitLab team members at Open Source Summit-Japan\n{: .note.text-center}\n\n## Journey from an end user to a regular contributor to an evangelist\n#### [Hiroyuki Sato](https://gitlab.com/hiroponz), GitLab Evangelist\n\nI started to contribute to GitLab back in 2012. At that time I was already using GitLab at work, and I wanted to fix a bug that I was facing. This issue was preventing the source code diff from being displayed on the screen, but it was only occurring when using Japanese. As this issue was not seen in other languages, this was not a high priority bug, but it was impacting us severely. I found it very natural to fix it myself and to open a [merge request](https://github.com/gitlabhq/gitlabhq/pull/2100). In order to solve this, I also had to first fix the gem ‘grit_ext’ that GitLab was using, and created [another merge request](https://github.com/gitlabhq/grit_ext/pull/1).\n\nBoth merge requests got reviewed and merged within three days! This experience was so exciting that I started to contribute more and created [multiple merge requests](https://github.com/gitlabhq/gitlabhq/pulls?q=is%3Apr+author%3Ahiroponz+is%3Aclosed), and eventually I was awarded the [MVP](https://about.gitlab.com/community/mvp/) for GitLab's 5.1 release.\n\nLater on, as I really loved GitLab as a product, I started to explore if there was a way for me to work more closely with GitLab. This is when I met Creationline, which had just become the exclusive reseller in Japan and I decided to join them in April, 2018.\n\nNow, I am involved in pre-sales, marketing, customer support, and I also offer trainings on how to get the best out of GitLab. Of course, I still invest a part of my time to [contribute to GitLab](https://gitlab.com/groups/gitlab-org/-/merge_requests?%0Ascope=all&utf8=%E2%9C%93&state=merged&author_username=hiroponz) to help customers overcome issues/challenges, and this is one of my favorite parts of the job!\n\n## Dogfooding at Creationline\n#### [Yuko Takano](https://gitlab.com/takano_cl), Customer Success Manager\n\nAs a reseller team, we wanted to have more opportunities to use GitLab on a daily basis so we can support our customers better. We also wanted to experience the continuous server side operations, and set up our own instance so that we can capitalize on this experience.\n\nWe started using GitLab inside the GitLab reseller team, and then expanded it to various business functions within our organization. We now use a lot of GitLab features in order to manage source code, visualize our sales and marketing workflow, track translation work, organize OKRs with epics, and we continue to look for other areas to explore.\n\n![GitLab CI workshop](https://about.gitlab.com/images/blogimages/creationline-blogpost/Creationlin-GitLab-workshop.jpg){: .shadow.medium.center}\nCreationline team running the GitLab CI Workshop\n{: .note.text-center}\n\n## Interested in learning how you can contribute?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can\nlearn how you can contribute to GitLab's code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n",[266,682,9,970],"releases",{"slug":972,"featured":6,"template":685},"creationline-post","content:en-us:blog:creationline-post.yml","Creationline Post","en-us/blog/creationline-post.yml","en-us/blog/creationline-post",{"_path":978,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":979,"content":985,"config":992,"_id":994,"_type":13,"title":995,"_source":15,"_file":996,"_stem":997,"_extension":18},"/en-us/blog/everyone-who-has-contributed",{"title":980,"description":981,"ogTitle":980,"ogDescription":981,"noIndex":6,"ogImage":982,"ogUrl":983,"ogSiteName":672,"ogType":673,"canonicalUrls":983,"schema":984},"Visualizing 11 years of GitLab contributions","Check out this animated video, which beautifully visualizes every contribution since our start.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682555/Blog/Hero%20Images/gitlabeveryonecontributesdna.png","https://about.gitlab.com/blog/everyone-who-has-contributed","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Visualizing 11 years of GitLab contributions\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Darwin Sanoy\"}],\n \"datePublished\": \"2022-12-19\",\n }",{"title":980,"description":981,"authors":986,"heroImage":982,"date":988,"body":989,"category":990,"tags":991},[987],"Darwin Sanoy","2022-12-19","\n\nGitLab’s mission is to make it so that **[everyone can contribute](/company/mission/#mission)**. While I have been experiencing this mission for three years, I wondered if there was a way to visualize the effect of having everyone contribute over GitLab's history. It turns out there is. An open source project known as [Gource](https://gource.io/) can create an animated visualization of the commit history of a repository. I ran it against the GitLab repository and it visualizes 11 years of busy developers contributing over 300,000 commits to GitLab - covered in just under 10 minutes of video. Each node in the visualization is a file and the count of various file types is shown on the left.\n\nA big thank you to absolutely everyone who has made contributions to GitLab over the years. Hopefully this visualization helps you have a greater sense of this community.\n\nGitLab has recently published the management principles that help enable the \"everyone can contribute\" mission within GitLab. This new people management framework is called [TeamOps](/teamops/). Everyone can learn and become certified in TeamOps through GitLab’s learning portal.\n\nAs another mile marker of the power of the everyone can contribute mission, GitLab also just celebrated one year as [a public company](/blog/one-third-of-what-we-learned-about-ipos-in-taking-gitlab-public/)!\n\nI hope you enjoy Gource’s video visualization, which is filled with the glow of light - seems very appropriate for the many global cultural festivals at this time of year that use light and fireworks to celebrate their communities!\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe width=\"1870\" height=\"937\" src=\"https://www.youtube.com/embed/QxLzyJDljpg\" title=\"\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\u003C/figure>\n\n\nIf you'd like to become a contributor, check out our [contribution guide](/community/contribute/).\n","culture",[266,9,750],{"slug":993,"featured":6,"template":685},"everyone-who-has-contributed","content:en-us:blog:everyone-who-has-contributed.yml","Everyone Who Has Contributed","en-us/blog/everyone-who-has-contributed.yml","en-us/blog/everyone-who-has-contributed",{"_path":999,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1000,"content":1006,"config":1013,"_id":1015,"_type":13,"title":1016,"_source":15,"_file":1017,"_stem":1018,"_extension":18},"/en-us/blog/external-postgresql-servers-should-be-upgraded-to-latest-version",{"title":1001,"description":1002,"ogTitle":1001,"ogDescription":1002,"noIndex":6,"ogImage":1003,"ogUrl":1004,"ogSiteName":672,"ogType":673,"canonicalUrls":1004,"schema":1005},"Upgrade your external PostgreSQL 12 & 13 servers now","External PostgreSQL 12.7- and 13.3- servers used with GitLab should be upgraded to the latest minor version.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669673/Blog/Hero%20Images/engineering.png","https://about.gitlab.com/blog/external-postgresql-servers-should-be-upgraded-to-latest-version","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"External PostgreSQL 12 and 13 servers should be upgraded to the latest minor version\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Yannis Roussos\"}],\n \"datePublished\": \"2022-06-23\",\n }",{"title":1007,"description":1002,"authors":1008,"heroImage":1003,"date":1010,"body":1011,"category":298,"tags":1012},"External PostgreSQL 12 and 13 servers should be upgraded to the latest minor version",[1009],"Yannis Roussos","2022-06-23","\n\nA bug in certain versions of PostgreSQL, called the `use-after-free bug`, can cause segmentation faults. If you are affected, you should upgrade. The affected PostgreSQL versions are:\n\n- PostgreSQL 12 versions earlier than 12.7. The bug was patched in [PostgreSQL 12.7](https://www.postgresql.org/docs/release/12.7/).\n- PostgreSQL 13 versions earlier than 13.3. The bug was patched in [PostgreSQL 13.3](https://www.postgresql.org/docs/release/13.3/).\n\nWhich versions of GitLab could be affected?\n\n- GitLab EE versions 14.9 and later are affected, if your version of PostgreSQL is an affected version.\n- GitLab CE versions 15.1 and later are affected, if your version of PostgreSQL is an affected version.\n- Omnibus GitLab instances using a bundled PostgreSQL server are not affected as they ship with [patched versions of PostgreSQL](https://docs.gitlab.com/ee/administration/package_information/postgresql_versions.html), and no further action is needed.\n\nWe strongly recommend all instances using an affected PostgreSQL version to upgrade to the latest minor version for PostgreSQL version 12 or 13.\n\nFor more detailed information, review our [issue on this problem](https://gitlab.com/gitlab-org/gitlab/-/issues/364763).\n",[751,9],{"slug":1014,"featured":6,"template":685},"external-postgresql-servers-should-be-upgraded-to-latest-version","content:en-us:blog:external-postgresql-servers-should-be-upgraded-to-latest-version.yml","External Postgresql Servers Should Be Upgraded To Latest Version","en-us/blog/external-postgresql-servers-should-be-upgraded-to-latest-version.yml","en-us/blog/external-postgresql-servers-should-be-upgraded-to-latest-version",{"_path":1020,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1021,"content":1027,"config":1035,"_id":1037,"_type":13,"title":1038,"_source":15,"_file":1039,"_stem":1040,"_extension":18},"/en-us/blog/five-devops-platform-benefits-that-inspire-gitlab-users",{"title":1022,"description":1023,"ogTitle":1022,"ogDescription":1023,"noIndex":6,"ogImage":1024,"ogUrl":1025,"ogSiteName":672,"ogType":673,"canonicalUrls":1025,"schema":1026},"Five benefits that inspire users to become GitLab advocates","Learn how a single tweet led to insight from our advocates on how they use GitLab to improve their work and their own lives.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663383/Blog/Hero%20Images/tanuki-bg-full.png","https://about.gitlab.com/blog/five-devops-platform-benefits-that-inspire-gitlab-users","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"5 DevOps platform benefits that inspire GitLab users to become GitLab advocates\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Omar Fernandez\"}],\n \"datePublished\": \"2021-11-23\",\n }",{"title":1028,"description":1023,"authors":1029,"heroImage":1024,"date":1031,"body":1032,"category":1033,"tags":1034},"5 DevOps platform benefits that inspire GitLab users to become GitLab advocates",[1030],"Omar Fernandez","2021-11-23","\n\nAt GitLab, we believe that a [single DevOps platform helps teams](https://about.gitlab.com/handbook/product/single-application/) to collaborate better and deliver software faster and with better security. In September, GitLab’s CEO Sid Sijbrandij [asked on Twitter](https://twitter.com/sytses/status/1440799819119824898) for volunteers willing to share their stories of advocating for the adoption of GitLab. Over the following days, GitLab team members interviewed 25 GitLab advocates who offered to share their experiences. Among other things, we asked them: \n\n- How did you first encounter GitLab?\n- Why have you advocated for the adoption of GitLab?\n- How has advocating and using GitLab in your organization benefited you? \n\nOur advocate interviews validated that GitLab’s single-application [DevOps Platform](/solutions/devops-platform/) has unlocked value for GitLab users. Below are excerpts of some of these interviews to give you the opportunity to hear directly from GitLab users. In them, you'll learn about five GitLab benefits that converted these users into advocates. \n\n## 1. A single application helps focus on work that matters\n\nGitLab’s single application helps users to focus on work that matters. GitLab reduces the need to context-switch as users no longer need to jump across disparate point-solutions. Users are better able to focus, stay on task, and drive business results.\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\n\u003Ciframe src=\"https://www.youtube.com/embed/pMWXn6NslEE\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\n\u003C/figure>\n\n\u003C!-- blank line -->\n\nSam Briesemeister highlights the benefits of working on one platform, being able to link the work done to a specific issue, and increasing developer productivity. By using GitLab, users save time in their life. \n\n_“What [investing in GitLab] ultimately does is, actually, we’re saving somebody’s time [in] their life. We’re not wasting their life.”_\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\n  \u003Ciframe src=\"https://www.youtube.com/embed/YcsT53c_Nuo\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\n\u003C/figure>\n\n\u003C!-- blank line -->\n\nProfessor Neil Gershenfeld speaks about how GitLab allows his labs to do what used to require five separate solutions, one each for web serving, teaching classes, access control, documentation, and security. \n\n_When asked how GitLab has made your life better, Professor Gershenfeld said: “It’s almost hard to answer because it’s like ‘why do I like air?’ It’s just sort of, most of my work ends up in GitLab. It’s just a natural part of my working day.”_\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\n\u003Ciframe src=\"https://www.youtube.com/embed/nUY8RrOyGPo\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\n\u003C/figure>\n\n\u003C!-- blank line -->\n\nPhilipp Westphalen, one of our [GitLab Heroes](https://about.gitlab.com/community/heroes/members/), speaks about GitLab’s ease of use and how having a single tool instead of multiple separate solutions allows him to focus on getting things done. \n\n_“For me, it feels like home... It’s really easy to use... and you can focus on getting things done.”_\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\n\u003Ciframe src=\"https://www.youtube.com/embed/heFWR23Z5nw\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\n\u003C/figure>\n\n\u003C!-- blank line -->\n\nPavle Djuric also speaks to us about the ability to focus on work and GitLab’s ease of use.\n\n_“[Working in GitLab] makes you feel very professional. You feel like you’re doing your job. You’re way more efficient as a team.”_\n\n## 2. Reducing manual tasks through automation\n\nSeveral advocates spoke about the benefits of automating tasks within GitLab to free up time for more productive activities. \n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\n\u003Ciframe src=\"https://www.youtube.com/embed/HW0ByLmG8sY\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\n\u003C/figure>\n\n\u003C!-- blank line -->\n\nAndrew Jones speaks about using GitLab to reduce repetitive tasks. He can’t imagine going back to the old way of doing things with many manual tasks. \n\n_“It just takes care of the stuff that would normally be laborious, painful repetitive stuff and allows you to focus on your primary function. I couldn’t imagine working without GitLab. I can’t imagine going back to the old way.”_\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\n\u003Ciframe src=\"https://www.youtube.com/embed/oN1cieaeLBk\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\n\u003C/figure>\n\n\u003C!-- blank line -->\n\nJan Mikes tells us about automation and the ability to get things done without context switching or moving across apps. This helps his productivity and efficiency. \n\n_“There’s high demand for CI engineers and since I work as an architect, this is a high-demand skill, to write pipelines, optimize performance, shorten the time from writing the code to deploy to production. And all of this I can deliver and that’s another reason why I love GitLab, because anything that comes to my mind, I figure some way how to do it with GitLab CI.”_\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\n\u003Ciframe src=\"https://www.youtube.com/embed/SvQUM6DL1B4\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\n\u003C/figure>\n\n\u003C!-- blank line -->\n\nMarc-Aurele Brothier speaks to us about how the adoption of GitLab helped his team be more efficient and streamline collaboration. \n\n_“[A customer was] very happy because we could demonstrate [to] them that, with [GitLab], that they could create the release, open a PR, say I want to deploy in our environment, and just accept it, and it was done two minutes later and it was automated. So it’s not anymore like asking someone, sending emails, or sending a request to another team. Just you do it and you get it.”_\n\n## 3. Improved transparency and collaboration\n\nTransparency and Collaboration are two of [GitLab’s values](https://handbook.gitlab.com/handbook/values/), so it was great to hear how adopting GitLab helps teams operate in a more transparent and collaborative manner. \n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\n\u003Ciframe src=\"https://www.youtube.com/embed/1rdtQ3tvDtg\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\n\u003C/figure>\n\n\u003C!-- blank line -->\n\nGerben Geijteman tells us that collaboration and communication are enhanced by the transparency you get in GitLab by having the solution, or code, linked to directly from the issue tracker. This benefits collaboration with other team members and with clients. \n\n_“GitLab for me unifies it all in the same place so everyone is looking at the same code in the same direction with the same quality level.”_\n\n_“In projects where we have direct customer communication, we like to also use GitLab because GitLab gives you a more direct mode of communication. You can say we fixed this issue with this particular line of code at that particular moment in time. And it takes away intermediate layers of communication... and it keeps everything in context.”_\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\n\u003Ciframe src=\"https://www.youtube.com/embed/pWVEnIQjGbE\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\n\u003C/figure>\n\n\u003C!-- blank line -->\n\nSebastian Schmid talks about how, since the adoption of GitLab, different teams in his organization are able to share and reuse source code more easily.\n\n_“Before [GitLab], only the team working on the code was able to see the code... [After starting to use GitLab] they started to use source code from other teams and collaborate in code with other teams.”_ \n\n_“People could start to contribute to our product and they don’t need to have some special skills. They just could write [an] issue, could paste some screenshots and stuff like that, and some engineers could take this and improve the product.”_\n\n## 4. A welcoming community\n\nAnyone can directly contribute to our open source GitLab core and help enhance the GitLab platform. We appreciated hearing advocates talk about their experiences contributing to GitLab and how welcoming the GitLab community has been. \n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\n  \u003Ciframe src=\"https://www.youtube.com/embed/qy9f-7DI_5k\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\n\u003C/figure>\n\n\u003C!-- blank line -->\n\nDave Barr speaks about the value of working on a platform with an open source core and how great it is to see GitLab employees interact with contributors in the same way that they would with other GitLab employees. \n\n_“How you interact with that community is really telling. The way GitLab staff does that is really embracing, welcoming, open to feedback. They provide feedback; it's just like you’re a staff member. The approach they take to community contributions is the same exact approach they take for a staff merge request and that’s a fantastic approach.”_ \n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\n\u003Ciframe src=\"https://www.youtube.com/embed/LNp3ioZr5mg\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\n\u003C/figure>\n\n\u003C!-- blank line -->\n\nGary Bell talks to us about how welcoming, responsive, and understanding the GitLab community is with new people who want to contribute. \n\n_“Personally, I’ve just found the overall GitLab community to be very welcoming and very understanding. Just the patience people have... they’re just welcoming and willing to give the time to help. That’s been absolutely fantastic to feel that, which is something that I’ve not felt when I’ve tried to contribute to other open source projects before.”_\n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\n\u003Ciframe src=\"https://www.youtube.com/embed/4-z3QjPzFPk\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\n\u003C/figure>\n\n\u003C!-- blank line -->\n\nSimilarly, Sven Patrick Meier shares with us his journey from identifying a potential feature, proposing it, and working through the process to get the contribution accepted. \n\n_“[I submitted a contribution] and the maintainers of the project commented on my feature request and said ‘great idea,’ and I provided the template as a basic example. They helped me with so many things, and, right now, I’m right before the first contribution to that awesome product that I use every day.”_ \n\n## 5. Exposure to end-to-end modern software development\n\nUsers talk about how GitLab helps introduce them to modern software development practices. They appreciated GitLab’s monthly releases packed with new features. \n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\n\u003Ciframe src=\"https://www.youtube.com/embed/YMydvPCIg44\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\n\u003C/figure>\n\n\u003C!-- blank line -->\n\nMarcos Ortiz praises GitLab’s ease of use and how it made it easier to onboard team members. Marcos also speaks about how, when you get used to the way of doing things on GitLab, you can internalize beneficial development practices.\n\n_“When you get used to all these practices, load code frequently, to get everything in branch inside your repo story, I believe you can be faster in development.”_ \n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\n\u003Ciframe src=\"https://www.youtube.com/embed/fP50GWZxz48\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\n\u003C/figure>\n\n\u003C!-- blank line -->\n\nIn our discussion with Andy Malkin and Michael Kalange, we hear about how they feel that GitLab is not only on the cutting edge, but also a very reliable part of their work. \n\n_“When I use [GitLab], I feel like I’m on the cutting edge. A lot of time in tech you can feel like you’re using something and you know it’s outdated, but I don’t have that feeling with GitLab. When I’m using GitLab, I feel that you really are pushing the boundaries in terms of what’s the next thing that we need.”_ \n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\n\u003Ciframe src=\"https://www.youtube.com/embed/7gU12X10718\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\n\u003C/figure>\n\n\u003C!-- blank line -->\n\nChris Evans speaks to us about how GitLab's neatly organized user interface helped him learn more about the overall DevOps processes and tools.\n\n_“[I] started off as a network engineer [and] I ended up [in] some sysadmin-related roles but I was never really exposed to the software development lifecycle... but just through choosing GitLab as a project management platform, I was exposed to so many of the tools of the trade for this other industry, software engineering, and I was able to almost learn those in a way without having to use them directly.”_  \n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\n\u003Ciframe src=\"https://www.youtube.com/embed/JhfFlSBQ7tY\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\n\u003C/figure>\n\n\u003C!-- blank line -->\n\nSimilarly, Ion Nistor tells us about how he gets exposed to new areas and tools in DevOps by using GitLab. \n\n_“I like to learn. Many of the things that GitLab brings are related to new technologies and new ways of doing things. GitLab in this sense acted [as a] gateway to new technologies. I have to learn about DevOps more, about containers, and these are benefits for my personal development.”_ \n\n\u003C!-- blank line -->\n\n\u003Cfigure class=\"video_container\">\n\n\u003Ciframe src=\"https://www.youtube.com/embed/yuBeOxqnou4\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\n\u003C/figure>\n\n\u003C!-- blank line -->\n\nDibyadarshi Dash, a past intern at GitLab, highlights how having a single, integrated product to develop software made it easier for him to learn about software development end-to-end. \n\n_“I got a good exposure to what the software development lifecycle looks like because it was all in one platform, all in GitLab. The writing, coding, merging, deploying, testing, everything was in one platform. And I feel that because it was all in one integrated platform, I got a good holistic exposure to the whole cycle and I understood the cycle even better.”_ \n\n## Bringing it all together\n\nThe GitLab advocates reinforced our belief in GitLab’s value as a single DevOps platform. The advocates talked about being able to focus on getting work done, using automation to reduce manual steps, and transparently collaborating with their colleagues. They also highlighted how GitLab helps them get exposed to and learn about the modern software development process end-to-end thanks to our fast innovation and how our welcoming open source community has made it possible for them to contribute features to GitLab.\n","devsecops",[775,9,266],{"slug":1036,"featured":6,"template":685},"five-devops-platform-benefits-that-inspire-gitlab-users","content:en-us:blog:five-devops-platform-benefits-that-inspire-gitlab-users.yml","Five Devops Platform Benefits That Inspire Gitlab Users","en-us/blog/five-devops-platform-benefits-that-inspire-gitlab-users.yml","en-us/blog/five-devops-platform-benefits-that-inspire-gitlab-users",{"_path":1042,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1043,"content":1049,"config":1057,"_id":1059,"_type":13,"title":1060,"_source":15,"_file":1061,"_stem":1062,"_extension":18},"/en-us/blog/five-fast-facts-about-docs-as-code-at-gitlab",{"title":1044,"description":1045,"ogTitle":1044,"ogDescription":1045,"noIndex":6,"ogImage":1046,"ogUrl":1047,"ogSiteName":672,"ogType":673,"canonicalUrls":1047,"schema":1048},"Five fast facts about docs as code at GitLab","Here are five fast facts about how GitLab technical writers use GitLab in a docs-as-code workflow.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749660257/Blog/Hero%20Images/pen.jpg","https://about.gitlab.com/blog/five-fast-facts-about-docs-as-code-at-gitlab","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Five fast facts about docs as code at GitLab\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Suzanne Selhorn\"},{\"@type\":\"Person\",\"name\":\"Susan Tacker\"},{\"@type\":\"Person\",\"name\":\"Diana Logan\"}],\n \"datePublished\": \"2022-10-12\",\n }",{"title":1044,"description":1045,"authors":1050,"heroImage":1046,"date":1054,"body":1055,"category":772,"tags":1056},[1051,1052,1053],"Suzanne Selhorn","Susan Tacker","Diana Logan","2022-10-12","\n\nAt GitLab, we use GitLab as our single platform to document GitLab by using a “docs-as-code” workflow. Sound confusing? \n\nThe GitLab technical writing team uses GitLab to plan, create, review, edit, and publish the [GitLab documentation](http://docs.gitlab.com). And because we use the docs-as-code workflow, we can produce a large amount of content with a small, passionate, efficient team.\n\nIf you aren’t familiar with docs as code, here’s a quick definition: \n\n[Docs as code](https://idratherbewriting.com/trends/trends-to-follow-or-forget-docs-as-code.html#what-is-docs-as-code) is a way to develop and publish product documentation. It uses the same tools and processes as software code development, placing the documentation files along with the code files in a repository for version control. \n\nIf you are wondering whether your organization could adopt a docs-as-code workflow in GitLab, read on for five fast facts that help explain how our team does it.\n\n## We use GitLab to plan both GitLab features and docs content updates\n\nOur product managers, UX designers, engineers, and quality assurance teams work together to plan our feature work. Maybe when you’re planning releases, you use a Kanban board, or you create issues in a third-party tool.\n\nAt GitLab, we use epics and [issues](https://gitlab.com/gitlab-org/technical-writing/-/issues/680) to plan our work, and [issue boards](https://gitlab.com/groups/gitlab-org/-/boards/4340643?label_name%5B%5D=Category%3ADocs%20Site) to track our progress. We value transparency, so all of this information is available to everyone, including discussions about planning. The tech writing team has visibility into the status of development at any time.\n\n![planning issue](https://about.gitlab.com/images/blogimages/planning_issue.png)\n\nIf we have larger doc efforts, we track them in GitLab, make the changes by using GitLab, and mark issues as done in GitLab. If a year passes and we want to remember why we made a change, we search GitLab and find who made the change and why. If you’re working in many different tools right now, imagine what it would be like to view everything in one place. Everything feels faster and more efficient. You skip the time you’d normally spend going through emails and websites and Slack to find lost discussions. It’s all here in GitLab.\n\nAnd if you love your wiki and don’t want to go without it, we have a wiki feature too.\n\n## We use GitLab to give and receive feedback on the docs\n\nIf you’ve been a writer for any amount of time, you know what a pain it can be to get people to review your content.\n\nAt GitLab, our developers write the first draft of content for all our new features. They save the content in the same repository as their code. Feature documentation is part of our development “definition of done.” They assign the draft content to our writers, who review it, add suggestions, and send their ideas and edits back to the authors.\n\nThe writers themselves also open merge requests (MRs) for content changes. And no matter who opens the MR (the writer, a developer, a support engineer, a community contributor), we all have the ability to easily comment on each other’s work.\n\nIn a merge request, it’s as simple as selecting a Suggestion button. You can comment on one line or several. You can provide changes or edits, and the person who authored the merge request can easily apply your change, or create their own competing suggestion, and you can discuss it. To invite others to the conversation, you can type their username in a comment, and they see your comment as a to-do item in GitLab. In this way, you can discuss any change. It’s transparent and inclusive.\n\n![making a suggestion](https://about.gitlab.com/images/blogimages/suggestion.png)\n\nBecause the doc content is in markdown, which is similar to plain text, it’s easy to view the differences between file versions, and to see who committed which change.\n\nMaybe you’ve worked in places where reviews were done in PDFs, or Word docs, or Google docs with comments. When you try this workflow, you'll see how much more efficient the process is. No one is passing around outdated versions of documents. No one is making updates that inadvertently wipe out someone else’s comments.\n\nAnd if anyone ever wants to know why we made a change, it’s easy to view the history of the page or even view who is to “blame” for a specific line. \n\n![who to blame?](https://about.gitlab.com/images/blogimages/blame.png)\n\nYou don’t have to store versions of a PDF document and try to search for who suggested which change. It’s all in GitLab.\n\n## We use GitLab to preview the docs content\n\nAt GitLab, we have tools to generate the docs site content locally, but you can also easily share a view of the docs site right from a merge request. If you’re playing with an idea and you want to show someone, you open a merge request, generate what we call “a review app” and voila, the changed docs site is available at a publicly available URL.\n\n![the review app](https://about.gitlab.com/images/blogimages/view_app.png)\n\nYour changes are visible, and you can iterate on them or commit as-is. Which brings us to another one of the most useful features we have at GitLab.\n\n## We use GitLab to test every content change\n\nMaybe you’re using a third-party tool to test the links in your docs, or to check spelling and grammar rules.\n\nWe are using third-party tools (Nanoc for links, Vale for spelling and grammar), but like everything else, these tools can be incorporated into GitLab, and into the writer workflow.\n\nEach writer has our tools installed locally and can view everything, from the document’s reading level to passive and active voice fixes on their local machine. But for those contributors who don’t have the toolset, we run a version of our tests in a pipeline as part of every commit.\n\n![a lint error](https://about.gitlab.com/images/blogimages/lint_error_2.png)\n\nIf you’re a developer and you don’t consider yourself to be an expert writer, you might find that the pipeline failed on your merge request because of an important grammar or branding rule. We’ve defined a list of many rules, and assigned levels of importance to them. So not only do we have a [style guide](https://docs.gitlab.com/ee/development/documentation/styleguide/) and [word list](https://docs.gitlab.com/ee/development/documentation/styleguide/word_list.html), but we also run tests to ensure our content doesn’t stray too far from those rules.\n\n## We use GitLab to generate the HTML output and we host the output on GitLab Pages\n\nOur CI/CD pipeline converts our markdown content and compiles it into HTML. Then we host this output on GitLab Pages, at the [docs.gitlab.com](http://docs.gitlab.com) website.\n\n![the pipeline](https://about.gitlab.com/images/blogimages/pipeline2.png)\n\nHaving the output generated by a pipeline means that we can update the docs site whenever we want. While the product is released once a month, we update the docs site once every hour. That means docs.gitlab.com always contains the most up-to-date content available, sometimes even pre-release information. Since the development planning and implementation issues are typically open to the public as part of our transparency value, pre-announcing features isn’t an issue. \n\nSo as you can see, for a multitude of reasons, we love our docs-as-code workflow. It can be an adjustment to transition to one tool for all of your doc needs, but GitLab supports the full writer workflow, no matter who writes your content. And we know, because we’ve been using it for years. \n\nLearn more about the tech writing docs-as-code work at GitLab:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/ZlabtdA-gZE\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nTo learn more about contributing to our open source documentation, check out our instructions in “[How to update the docs](https://docs.gitlab.com/ee/development/documentation/workflow.html#how-to-update-the-docs).” We welcome your contributions!\n",[774,9,728],{"slug":1058,"featured":6,"template":685},"five-fast-facts-about-docs-as-code-at-gitlab","content:en-us:blog:five-fast-facts-about-docs-as-code-at-gitlab.yml","Five Fast Facts About Docs As Code At Gitlab","en-us/blog/five-fast-facts-about-docs-as-code-at-gitlab.yml","en-us/blog/five-fast-facts-about-docs-as-code-at-gitlab",{"_path":1064,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1065,"content":1071,"config":1078,"_id":1080,"_type":13,"title":1081,"_source":15,"_file":1082,"_stem":1083,"_extension":18},"/en-us/blog/get-ready-for-commit",{"title":1066,"description":1067,"ogTitle":1066,"ogDescription":1067,"noIndex":6,"ogImage":1068,"ogUrl":1069,"ogSiteName":672,"ogType":673,"canonicalUrls":1069,"schema":1070},"How to get the most out of GitLab Commit","We’re taking over the Williamsburg neighborhood of Brooklyn and opening up our world to you. Here’s everything you need to know.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664134/Blog/Hero%20Images/gitlabcommitbrooklyn.png","https://about.gitlab.com/blog/get-ready-for-commit","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How to get the most out of GitLab Commit\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Emily Kyle\"}],\n \"datePublished\": \"2019-09-13\",\n }",{"title":1066,"description":1067,"authors":1072,"heroImage":1068,"date":1074,"body":1075,"category":298,"tags":1076},[1073],"Emily Kyle","2019-09-13","\nWe’re (almost!) ready – are you? The inaugural GitLab Commit in Brooklyn is just around the corner. We wanted to share some details on the event and how to get the most out of it while you’re onsite and after it’s over.\n\nWhen planning this event we made the strategic choice to avoid convention centers and stuffy hotel ballrooms. We like to be a bit more playful (and out of the box) in how we approach our community and events. We decided to model this event after a block party and on Tuesday September 17 we’ll be taking over 8 venues. On your walk from the subway you’ll notice the street has been “GitLabbed” and will be full of signs. Everything – signs, content, staff – will welcome you. If we did it right it will be quirky, fun, innovative, collaborative, and inclusive. A small block in Brooklyn will _be_ GitLab for a day. We can’t wait to share that vision with everyone attending.\n\nStart by checking in at the Williamsburg Hotel, 96 Wythe Ave, Brooklyn, NY 11249\n(between Nassau St. on the G or Bedford Ave. on the L). Don’t forget to grab breakfast treats and coffee.\nOver the course of the day we will also have sessions and activities in and around the following\nvenues: the [Wythe Hotel](https://wythehotel.com), [Schimanski](https://www.schimanskinyc.com),\n[Brooklyn Bowl](https://www.brooklynbowl.com), [Kinfolk 90](https://kinfolklife.com/locations/kinfolk-90/) & [Kinfolk 94](https://kinfolklife.com/locations/kinfolk-94/). Each venue serves a specific function and has its own personality but each one flows seamlessly into the next one.\n\n![Map of GitLab Commit](https://about.gitlab.com/images/blogimages/gitlabcommitmap.png){: .shadow.small.center.wrap-text}\n\nIt’s a neighborhood takeover!\n{: .note.text-center}\n\n## Remember to schedule\n\nYou can find the schedule [here](https://gitlabcommit2019brooklyn.sched.com). To get the most out of your day on site, we suggest building out your schedule in the sched link just mentioned so you can reserve your slot in each of the tracks. There will be 3 tracks – cloud native, DevOps in action, and powered by GitLab – and each will be color coded to help you navigate throughout the day.\n\n## And it’s not over yet…\n\nWe will close out the day of sessions at the historic Brooklyn Bowl directly following the day’s packed lineup for networking, food & beverages and of course bowling. The party kicks off at 5 pm.\n\n## Other important details\n\nLooking for a well brewed cappuccino or latte? Kinfolk 90 will be serving Commit attendees with a badge from 12pm-5pm at no charge, so drop in between sessions.\n\nHave questions about our product offerings, a nagging support item, want deeper insight into our security offerings, or time to visit with some of our sponsors? The Library at the Williamsburg Hotel will be open all day for some one-to-one interaction.\n\nLastly we have a [few spots still open](https://about.gitlab.com/events/commit/) if you want to get in on this action packed day of learning! There is also still time to sign up for our [London event](/events/commit/#) in October.\n",[266,9,276,775,1077],"frontend",{"slug":1079,"featured":6,"template":685},"get-ready-for-commit","content:en-us:blog:get-ready-for-commit.yml","Get Ready For Commit","en-us/blog/get-ready-for-commit.yml","en-us/blog/get-ready-for-commit",{"_path":1085,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1086,"content":1092,"config":1098,"_id":1100,"_type":13,"title":1101,"_source":15,"_file":1102,"_stem":1103,"_extension":18},"/en-us/blog/gitlab-and-the-three-ways-of-devops",{"title":1087,"description":1088,"ogTitle":1087,"ogDescription":1088,"noIndex":6,"ogImage":1089,"ogUrl":1090,"ogSiteName":672,"ogType":673,"canonicalUrls":1090,"schema":1091},"GitLab and the three ways of DevOps","DevOps isn't just an esoteric philosophy - it actually is a roadmap for faster and safer software releases, if you choose the right tool. Here's how to take the principles of DevOps and get the most out of the One DevOps Platform.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667845/Blog/Hero%20Images/gl15.jpg","https://about.gitlab.com/blog/gitlab-and-the-three-ways-of-devops","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab and the three ways of DevOps\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Vlad Budica\"}],\n \"datePublished\": \"2022-06-15\",\n }",{"title":1087,"description":1088,"authors":1093,"heroImage":1089,"date":1095,"body":1096,"category":1033,"tags":1097},[1094],"Vlad Budica","2022-06-15","\n\nMost of my daily conversations are focused on features and very deep technical concepts, which provide valuable and actionable insight. However, we miss the fact that tools and technology are leveraged to solve business challenges. When talking about features and technology, it's very easy to see the possible financial gain when replacing different tools with a unified platform. But it's missing all the improvement opportunities that will provide value at all the levels of a company from developers to executives.\n\nThe reality is that we're working in very complex systems, making it hard to see the forest from the trees. As an engineer, you're focused on solving the next immediate problem that arises without taking a step back to reevaluate the system itself. In some cases, the problem itself is created by the design of our software development lifecycle (SDLC). As an executive, it's difficult to balance the effort required to address the technical challenges with the pressure that comes from the business in this ever-increasing rhythm of change.\n\nMy goal with this article is to provide a high-level map that contains the most important DevOps principles and a shortcut. I know this is a bold statement as there is a lot of literature on this topic but my approach will be different.\n \nFirst, I'm going to use the [Three Ways](https://itrevolution.com/the-three-ways-principles-underpinning-devops/) as coined in [The DevOps Handbook](https://www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations/dp/1942788002) because those are the three foundational principles of DevOps as they were refined from Lean, the Toyota Production System, Theory of Constraints, Six Sigma, and System Thinking principles. Second, I'll reference GitLab as the tool of choice because I think a good tool lets you focus on the work at hand, and GitLab does just that. \n\n> You’re invited! Join us on June 23rd for the [GitLab 15 launch event](https://page.gitlab.com/fifteen) with DevOps guru Gene Kim and several GitLab leaders. They’ll show you what they see for the future of DevOps and The One DevOps Platform.\n\nHere is a short description of what the Three Ways are, what they're about, and why you should care.\n\n## First Way: Maximize flow\n\nThe First Way is all about making work/value flow better through the whole value stream (left to right), and to do that, we need to have a systems thinking approach and always look at the end-to-end result. In the case of IT, this means we optimize for speed from the moment we had the idea, to generating value with software running in production.\n\nWe need to have a good understanding of the system to find potential bottlenecks and areas of improvement. Our improvements should always lead to better overall performance, be aware of the cases in which local enhancements lead to global degradation, and avoid that.\n\nIn this process, it is crucial to stop defects from passing downstream from one workflow stage to another. Why? Because defects generate waste (of time and resources).\n\n## Second Way: Feedback loops\n\nThe Second Way deals with feedback loops, amplifying and shortening feedback loops so that we get valuable insight into the work we're doing. The feedback can be related to the code that's written or the improvement initiatives. Feedback loops maximize flow from right to left of the value stream.\n\nQuick, strong feedback loops help build quality into the product and ensure that we're not passing defects downstream. The quicker we do this the quicker and cheaper we can solve them, continuously keeping our software in a deployable state. It's easier for a developer to fix a bug when they are working on that change, and the code and the thought process are fresh in their mind. Suppose days or even weeks pass between the moment of the commit and the moment we realize there is a problem with the change. It will be significantly harder to address the problem, not to mention that we probably realized the problem only when trying to deploy the software and we have a service that's not working on our hands. On the flip side, feedback loops enable learning and experimentation, a point on which I’ll return a bit later.\n\nUsually, more developers lead to more productivity but, as presented in [The State of DevOps Report](https://cloud.google.com/blog/products/devops-sre/announcing-dora-2021-accelerate-state-of-devops-report), this is true only for high performers. Why? If we have a team of 50 developers and problems aren't immediately detected, technical debt builds up. Things will only get worse when we have 100 developers because they will generate even more technical debt with every development cycle. A natural tendency would be to add more developers in the hope velocity will get better, but it will degrade, so we add even more developers, and things degrade even more, and deployment frequency starts to suffer as it takes a lot of time to fix all the problems that came from upstream in order to get to a deployable state.\n\n## Third Way: Continuous experimentation and learning\n\nThe Third Way is about creating a culture of trust where continuous experimentation and learning can thrive. This leverages the first two ways in order to be successful.\n\nMaking work flow easily through the value stream enables us to experiment and even take some risks, while failing fast and inexpensively. Feedback loops act as the guardrails that help us keep the risk in check but also facilitate learning because learning happens only when strong fast feedback is available. We can have a scientific approach, experiment with things, and extract the learning and improvement that results from these experiments and their feedback.\n\nThis is an iterative process that will lead to mastery (through increased repetition). This should be coupled with an environment where this local learning becomes global and is integrated into the daily work of all the teams. For this approach to work and start getting some results, 20% of our time should be reserved for these improvement activities. I'm aware how difficult it can be to carve 20% of your time for improvement initiatives when dealing with urgent problems is your full-time job. Protecting this improvement time helps us pay our technical debt and make sure things are not spiraling out of control.\n\n## GitLab and the Three Ways\n\t\nNow that we presented the Three Ways of DevOps, maximizing flow (left to right), feedback loops (maximizing flow right to left) and having a continuous learning process, implementing them requires some effort from a tooling and process perspective.\n\nIt’s time to introduce GitLab into the picture, the only DevOps platform that covers the whole SDLC. Why is this useful for you? Because there is a synergy that happens when all the capabilities you need are provided in the same platform, the result is more than the sum of the components. Additionally, a good tool lets you focus on your work, not on the tool itself, so you can spend more time and effort driving your DevOps transformation. The fact that you’ll spend less money and time integrating different tools is the first immediate return of your investment.\n\nWhen the goal is to maximize flow from left to right, GitLab can facilitate that, starting from idea to production. Having the benefit of being a platform built from the ground up, work can flow from Planning to the commit and source code management stage and forward to CI/CD seamlessly. Any person involved in the SDLC can perform their work from the same UI. All the information they need is available without a need to switch through different UIs while paying the mental context-switching cost associated when using disparate tooling. \n\nGitLab provides different control mechanisms to make sure that if defects are introduced they are isolated and they don’t move downstream. Working in short-lived feature branches, different controls around merging and MR Request Approval rules act as gates. \n\nBy having everything on the same platform it’s easier to understand the whole flow of work, coupling this with our Value Stream Metrics enables everyone involved to get a better understanding of the overall system and find potential bottlenecks and improvement opportunities.\n\n### Improved flow\n\nAs mentioned, flow in one direction - left to right - is not enough to deliver better software products faster. Feedback loops that are quick and provide strong feedback are crucial for great business outcomes. From a developer perspective, the results of the CI pipeline provides immediate feedback about your change. If this pipeline contains security scans it’s even better. Providing feedback from a security standpoint ensures that we’re not deploying vulnerable code and it gives the developer the opportunity to go back and fix it immediately. This is very actionable feedback that also provides a learning opportunity because the security reports come with information about the vulnerabilities, and also where possible, a potential solution to the vulnerability. All this is available for you without any additional work to integrate different tools.\n\nSwitching perspectives, someone that needs to review or approve a code change has everything they need at their fingertips in one place. It’s straightforward to pull in or “@mention” other necessary parties and they’ll get access to all necessary context. A decision can be made immediately and it’s based on accurate and clear feedback that you can trace back to the initial idea. \n\n### Metrics matter\n\nTaking another step back, we get different metrics (Value Stream, Contribution) at the project level. This is one of the advantages that comes with a platform approach, and these insights are very easy to obtain and feed back into the process. When doing software development at scale, more senior managers need this feedback at an even higher level, and, therefore, these are available across multiple teams, projects, or departments. All this information is very valuable from a current perspective, but also it helps guide and shape business decisions. If the velocity isn’t what is needed by the business we can look to remove bottlenecks, improve things or invest in some key areas.\n\nWith these two capabilities in place, we have a framework in which we can iterate quickly and safely. Experimentation becomes easy and very safe, we can test different business hypotheses, and see which ones work best with our customers. This should happen on an ongoing basis because this is the cornerstone of innovation.\n\n### Context is critical \n\nEvery experiment that we perform, every problem that we solve becomes valuable learning that should be accessible to everyone in the organization. Having everything (context, actions, results, learning) in one place enables us to open things up so that everyone can contribute. This requires an environment of trust where everyone feels comfortable to run small experiments that lead to improvements, and where these improvements can diffuse in your entire organization. By having a tool that just works and provides everything you need without any additional work, you gain back capacity that you can use to improve your product, overall system, or organization.\n\nIt’s been a long journey up to this point, with the purpose of taking a look beyond immediate feature comparisons and the immediate financial gain that is realized when replacing multiple tools with one. We looked at the core principles of DevOps as a map in your DevOps transformation and at GitLab as a tool to facilitate that. Improving very complex systems is hard, driving that change through your company is a challenge, knowing that you have a tool that just delivers on your needs you can focus on developing code and on your continuous improvement efforts.\n\nI hope this is useful to everyone involved in the SDLC, from the engineers who need to work with and within the system everyday, to senior leaders who need to deliver business results.\n",[775,266,9],{"slug":1099,"featured":6,"template":685},"gitlab-and-the-three-ways-of-devops","content:en-us:blog:gitlab-and-the-three-ways-of-devops.yml","Gitlab And The Three Ways Of Devops","en-us/blog/gitlab-and-the-three-ways-of-devops.yml","en-us/blog/gitlab-and-the-three-ways-of-devops",{"_path":1105,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1106,"content":1112,"config":1118,"_id":1120,"_type":13,"title":1121,"_source":15,"_file":1122,"_stem":1123,"_extension":18},"/en-us/blog/gitlab-community-forks",{"title":1107,"description":1108,"ogTitle":1107,"ogDescription":1108,"noIndex":6,"ogImage":1109,"ogUrl":1110,"ogSiteName":672,"ogType":673,"canonicalUrls":1110,"schema":1111},"Community forks: A new, easier way to contribute to GitLab","Learn how we tackled a number of pain points and introduced an alternative to personal forks for open-source community contributions.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664087/Blog/Hero%20Images/tanukicover.jpg","https://about.gitlab.com/blog/gitlab-community-forks","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Community forks: A new, easier way to contribute to GitLab\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Lee Tickett\"}],\n \"datePublished\": \"2023-04-04\",\n }",{"title":1107,"description":1108,"authors":1113,"heroImage":1109,"date":1115,"body":1116,"category":298,"tags":1117},[1114],"Lee Tickett","2023-04-04","\nAt GitLab, we believe [everyone can contribute](/company/mission/#mission).\nIn my role, as a member of GitLab's Contributor Success team, I'm focused on ensuring that contributing to GitLab is as easy and rewarding as possible. In this article, I will share a recent experiment in improving the GitLab contributor experience for community members: community forks.\nI'll explain what they are and, more importantly, the positive impact we've seen community forks have on contirbutions to GitLab.\n\n## What is a community fork?\n\nGitLab team members and wider community members have different levels of access to canonical GitLab projects. GitLab team members can contribute directly to the GitLab codebase; wider community members need to work from forks in order to contribute. This leads to two very different experiences. If you'd previously tried to contribute to GitLab from a personal fork, you probably encountered one of the following frustrations:\n\n* You need to fork the project before you can begin working on a code contribution. (This can take a while for big projects such as\n [GitLab](https://gitlab.com/gitlab-org/gitlab) and [www-gitlab-com](https://gitlab.com/gitlab-com/www-gitlab-com/).)\n* Collaboration is \"opt-in\". That is, a contributor must manually opt-in to allow maintainers to push commits to their merge requests,\n and community members cannot push commits to team member branches.\n* Free tier quotas apply to individual contributors' forks. This can create a challenge when frequent contributors use up their free CI minutes allocation.\n* Personal forks need to be regularly updated (rebased) against the canonical projects.\n\nTo address issues like these in the past, we'd developed and introduced solutions like [cost factors](https://docs.gitlab.com/ee/ci/pipelines/cicd_minutes.html#cost-factor-for-community-contributions-to-gitlab-projects). Those worked to alleviate individual pain points, but our team wanted to test another idea, one we thought could address a number of these contribution hurdles at once.\n\nDrawing inspiration from [Moshe Weitzman](https://gitlab.com/weitzman) and a [similar solution from the Drupal project](https://gitlab.com/drupalspoons/webmasters/-/blob/master/docs/onboarding_user.md),\nwe imagined establishing a \"community fork\" of GitLab. Instead of working on innumerable, individual, isolated forks of GitLab,\nwider community members could **all** contribute to a **single, shared fork** of GitLab available to everyone.\n\n## Building the first fork\n\nI spun up an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/378608) and started to bounce ideas around.\nWe were sure to involve the GitLab security team and the wider community before starting an experiment.\nAfter some conversations, I took a [bias for action](https://handbook.gitlab.com/teamops/decision-velocity/#bias-for-action) and created the first community fork.\nI shared this with a few regular community contributors (thank you, [Marco](https://gitlab.com/zillemarco) and [Niklas](https://gitlab.com/Taucher2003) for beta testing and now also maintaining the forks).\nAfter a few weeks, we didn't encounter any problems, so we started spinning up forks of more GitLab projects, and invited more community members to join us.\n\nWe believe community forks have the following effects (you'll note that these tie back to the contribution challenges outlined above):\n\n* **Promote collaboration**\n * Community members and team members can work on the same merge request (pushing commits to eachother's branches).\n * They can also take over stuck/idle merge requests (from each other and from team members).\n* **Remove blockers**\n * Personal CI minute and storage quotas do not apply to the community forks as they are part of the [GitLab for Open Source Program](https://about.gitlab.com/handbook/marketing/developer-relations/community-programs/opensource-program/#gitlab-for-open-source-program)\n which provides GitLab Ultimate tier benefits (including larger quotas).\n* **Improve efficiency**\n * There is no longer a need to create a personal fork to get started contributing.\n * Danger runs automatically, without the need to configure personal access tokens and CI variables.\n * Pull mirroring keeps the community forks up to date, without regular manual rebasing.\n\n## What's next for community forks?\n\nThe experiment was considered a success based on the following:\n\n* The problems identified and effects predicted were confirmed.\n* Adoption has been simple. \n* Feedback has been positive (both from community members and GitLab team members).\n* No blocking issues/concerns have been identified.\n\nThus, we are moving from \"experiment\" to \"production\".\n\nThe community forks concept forms part of my team's Q1 (February - April) objectives and key results (OKRs).\nAs such, we have started updating the documentation and contributor guides and looking at opportunities\nfor automation and promotion (for example, via [`@gitlab-bot`](https://gitlab.com/gitlab-org/quality/triage-ops/-/merge_requests/1993)).\n\nWe're also looking for opportunities to handle forks differently in the product.\nFor example, there are several areas (such as the WebIDE) that only check for personal forks and don't consider other types of fork.\nSome backend [pre-requisite work](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/112167) has already started to facilitate this.\n\nWe have been working on automating and managing the community forks via Terraform.\nThis will make the process quicker, easier, and less prone to human error.\n\nThe Contributor Success team is already [dogfooding](https://handbook.gitlab.com/handbook/values/#dogfooding) the community forks, and promoting internally,\nhoping that eventually all GitLab team members will use the community forks.\nWe'd love other open source projects to experiment with the concept and it become a new \"norm\" in community-driven open source software development.\n\nYou can read more about the community forks in the [meta project](https://gitlab.com/gitlab-community/meta).\nThere you'll also find instructions for requesting access to community forks.\nIf you have additional questions, why not ask our community members over on [Discord](https://discord.gg/gitlab)?\n",[9,266],{"slug":1119,"featured":6,"template":685},"gitlab-community-forks","content:en-us:blog:gitlab-community-forks.yml","Gitlab Community Forks","en-us/blog/gitlab-community-forks.yml","en-us/blog/gitlab-community-forks",{"_path":1125,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1126,"content":1132,"config":1137,"_id":1139,"_type":13,"title":1140,"_source":15,"_file":1141,"_stem":1142,"_extension":18},"/en-us/blog/gitlab-contributor-days",{"title":1127,"description":1128,"ogTitle":1127,"ogDescription":1128,"noIndex":6,"ogImage":1129,"ogUrl":1130,"ogSiteName":672,"ogType":673,"canonicalUrls":1130,"schema":1131},"Why we launched GitLab Contributor Days","Inside our decision to create an event where our contributors could gather in person to collaborate.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668213/Blog/Hero%20Images/innersourcing-improves-collaboration-within-an-organization.jpg","https://about.gitlab.com/blog/gitlab-contributor-days","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Why we launched GitLab Contributor Days\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Lee Tickett\"}],\n \"datePublished\": \"2023-03-29\",\n }",{"title":1127,"description":1128,"authors":1133,"heroImage":1129,"date":1134,"body":1135,"category":298,"tags":1136},[1114],"2023-03-29","\n\nGitLab hosted our first Contributor Days event in March as a fringe event of [CfgMgmtCamp](https://cfgmgmtcamp.eu/ghent2023/), which was held at [FOSDEM](https://fosdem.org/).\n\n## What is GitLab Contributor Days?\n\nGitLab Contributor Days is an in-person, unconference-style event geared toward collaboration. Attendees can work on contributions and engage with the wider community and GitLab team members. Mentors are on hand to help answer questions and collaborate on contributions.\n\n## How did GitLab Contributor Days come to be?\nMy role as a member of the GitLab's Contributor Success team is to improve the contributor journey. In the past, as an external GitLab community member, I wrote about [my own contributor journey](https://about.gitlab.com/blog/lee-tickett-my-gitlab-journey/)\nand [how being a GitLab Hero can elevate your company](https://about.gitlab.com/blog/gitlab-heroes-unmasked-elevating-my-company-using-gitlab/). I know how important it is to foster a sense of community among our contributors.\n\n[GitLab's hackathons](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/hackathon/-/issues/27) accomplish this virtually, but I missed the in-person interaction. So I explored the idea of community building and contributing at in-person events. I started, as all things do at GitLab, with [an issue outlining the GitLab Contributor Days idea](https://gitlab.com/gitlab-org/quality/contributor-success/team-task/-/issues/63) and my team fully supported me.\n\nWe had a rough date and venue in mind, but after seeing how close it was to FOSDEM, [Nick Veenhof](https://gitlab.com/nick_vh), Director of Contributor Success, suggested tying it in as a fringe event to tap into a pool of potential contributors who could drop in while at the event.\n\n## The GitLab Contributor Days experience\n\nFOSDEM provided a great opportunity for GitLab team members to connect face-to-face – many, for the first time.\nSeeing how much everyone loves GitLab and just enjoyed stopping by, smiling, and taking some stickers, gave me that warm fuzzy feeling – very much the reason I became part of the GitLab community in the first place.\n\nOur fluid format worked well and included:\n* Live pairing with [Marco Zille](/company/team/?department=core-team#zillemarco) from the GitLab Core team\n* [Raimund Hook](https://gitlab.com/stingrayza) working on merge requests at the booth\n* Additional code-pairing throughout the event\n\nWe had a number of contributors spend the whole day with us, and plenty of drop-ins. We also garnered ideas to iterate our next event.\n\n## Collaborating on issues\nThe [curated issue list](https://gitlab.com/gitlab-org/quality/contributor-success/contributor-days/-/issues/1) provided a great starting point for attendees to dig in and collaborate with one another. Next time, we might use Post-It notes so contributors can see the collaboration progress in real time. \n\nHere are the livestreams from some of our collaboration sessions:\n\n* [Live stream 1: Frontend form field validation](https://youtu.be/_smqyD2I5UI)\n* [Live stream 2: Issue triaging](https://youtu.be/LumKxEa32cg)\n* [Live stream 3: Getting started with GDK and GitPod](https://youtu.be/uRJwNLnH_z4)\n\n\nIn addition to those already mentioned above, here are some GitLab team members and community members who participated and their contributions:\n\n* [Felix](https://gitlab.com/l33tname): [improve CSV import docs](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111299)\n* [Marcel](https://gitlab.com/kornegoor): [improve CSV import docs](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111339)\n* [Michael](https://gitlab.com/mikeblum): [fix gitlab/v1 API with database disabled](https://gitlab.com/gitlab-org/container-registry/-/merge_requests/1210)\n* [Laurent](https://gitlab.com/ali_o_kan): [improve devise error message](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111445)\n* [Jon](https://gitlab.com/jdyb): [API to list project uploads](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111444)\n* [Declon](https://gitlab.com/ideclon): [expose Discord via the API](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111342)\n\nI'd like to also thank [Toshaan](https://www.linkedin.com/in/toshaan/) and [Kris](https://www.linkedin.com/in/krisbuytaert/) for hosting us.\n\nStay tuned for an announcement of our next Contributor Days event. Until then, join us on [Discord](https://discord.gg/gitlab) for our weekly livestreams, or for our upcoming [hackathon](/community/hackathon/).\n",[9,266],{"slug":1138,"featured":6,"template":685},"gitlab-contributor-days","content:en-us:blog:gitlab-contributor-days.yml","Gitlab Contributor Days","en-us/blog/gitlab-contributor-days.yml","en-us/blog/gitlab-contributor-days",{"_path":1144,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1145,"content":1151,"config":1159,"_id":1161,"_type":13,"title":1162,"_source":15,"_file":1163,"_stem":1164,"_extension":18},"/en-us/blog/gitlab-gdk-remote-development",{"title":1146,"description":1147,"ogTitle":1146,"ogDescription":1147,"noIndex":6,"ogImage":1148,"ogUrl":1149,"ogSiteName":672,"ogType":673,"canonicalUrls":1149,"schema":1150},"Contributor how-to: Remote Development workspaces and GitLab Developer Kit","This tutorial helps you get GDK working inside Remote Development workspaces to begin contributing to GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670563/Blog/Hero%20Images/cloudcomputing.jpg","https://about.gitlab.com/blog/gitlab-gdk-remote-development","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Contributor how-to: Remote Development workspaces and GitLab Developer Kit\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Raimund Hook\"}],\n \"datePublished\": \"2023-07-31\",\n }",{"title":1146,"description":1147,"authors":1152,"heroImage":1148,"date":1154,"body":1155,"category":748,"tags":1156},[1153],"Raimund Hook","2023-07-31","\nOpen source is fundamental to GitLab. We believe that [everyone can contribute](https://about.gitlab.com/company/mission/#mission).\nTypically, we recommend that anyone contributing anything more than basic changes to GitLab run the [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit) (GDK). Because contributors can't always meet the GDK's resource demands, we're working to enable GDK inside the cloud-based GitLab Remote Development workspaces.\n\nIn this article, I'll explain how I used a Remote Development workspace running in my Kubernetes cluster to make working with the GDK faster and easier.\n\n## A preliminary note\nFirst, keep in mind that as of this writing the [Remote Development workspaces](https://about.gitlab.com/direction/create/ide/remote_development/) feature is still in Beta. My example here is therefore very much a proof of concept — and as such, it has some rough edges.\n\nBefore getting started, I followed the \"[Set up a workspace](https://docs.gitlab.com/ee/user/workspace/#set-up-a-workspace)\" prerequisites guide in the GitLab docs. For a more detailed set of instructions, see Senior Developer Evangelist Michael Friedrich's tutorial on [how to set up infrastructure for cloud development environments](https://about.gitlab.com/blog/set-up-infrastructure-for-cloud-development-environments/).\n\n## Getting started with workspaces\nTo start using workspaces, you will need a project configured with a `.devfile.yaml`. GitLab team members have curated [a number of example projects](https://gitlab.com/gitlab-org/remote-development/examples) you can review.\n\nInitially, I tried to do this with a fork of the GitLab project itself, but I ran into [some issues](https://gitlab.com/gitlab-org/gitlab/-/issues/414011) when the workspace begins cloning the repository.\n\nTo figure out what was causing my problems, I looked more closely at what happens behind the scenes when a workspace is created.\n\n## Behind the scenes with Remote Development workspaces\nWhen you create a new workspace, the following happens:\n1. The GitLab agent for Kubernetes creates a new namespace in your cluster. The agent dynamically generates a name for and assumes management of the namespace.\n1. Inside the namespace, a new deployment is created, specifying the container you chose in your `.devfile.yaml` as the image to use.\n1. This deployment is configured with some [init containers](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) that perform some actions:\n 1. Cloning the repository into `/project/${project_path}`.\n 1. Injecting the VS Code server binary into your container.\n1. Once those init containers are complete, your container starts and the workspace becomes available.\n\n## The clone problem\nWhen cloning a repository, `git` tends to do much of the work in memory. This can be a challenge on larger projects/repositories, as it can require significant amounts of RAM. When cloning the GitLab project, for instance, git consumes approximately 1.6GB of RAM. This number is only going to increase with time. Sure, strategies like [shallow clones](https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---depthltdepthgt) can help reduce this, but these are perhaps less suited to active use by a developer as they can increase the amount of time required to perform ongoing git operations.\n\nIn fact, creating a workspace using our `.devfile.yaml` in a fork of the GitLab project failed for this reason. The init container performing the clone is currently hard-limited to 128MiB of RAM, after which the memory management processes on the node kill the container.\n\nTo overcome this limitation, move the `.devfile.yaml` into the a fork of the root of the GDK repository. This project clones more quickly (and does so using fewer resources), so it's a perfect starting point for running GDK itself. Another (bonus) advantage: You're then primed to contribute to the GDK itself, in addition to any of the other GitLab projects that the GDK clones.\n\n## Components of a GDK installation\nGDK clones the following projects from the GitLab 'family':\n* [GitLab](https://gitlab.com/gitlab-org/gitlab)\n* [Gitaly](https://gitlab.com/gitlab-org/gitaly)\n* [GitLab shell](https://gitlab.com/gitlab-org/gitlab-shell)\n\nThis allows you to work on any items in those directories as a part of your \"live\" installation.\n\n## Getting GDK installed and running in a workspace\nOnce I had a workspace up and running, my next step was to get GDK installed and running *in* that workspace. The GDK's documentation presents [several routes for doing this](https://gitlab.com/gitlab-org/gitlab-development-kit/#installation).\n\nA complete installation can take some time, as GDK needs to bootstrap itself and install a number of prerequisites. This is less than ideal in the context of a Remote Development workspace, as one of remote development's primary benefits is enabling access to a development environment rapidly. Requiring a user to bootstrap an environment that takes 50 minutes (or longer) doesn't help achieve this goal.\n\nTo combat this, I built a container image that effectively bootstraps and installs GDK, pre-building the GDK prerequisites and pre-seeding the database. This image and its associated tooling are currently [in review](https://gitlab.com/gitlab-org/gitlab-development-kit/-/merge_requests/3231).\n\n## Pre-building\nPre-building the container and running the bootstrap process on a scheduled basis allows us to perform that process once, without requiring the user to wait for something that can essentially be \"pre-canned\" for their use.\n\nOnce the workspace is running, we still need to \"reinstall\" the GDK environment with the latest version of our GitLab repository, but this step doesn't take quite as long as a complete bootstrap.\n\n## Generating a gdk.yml file\nTo work properly, GDK also requires a [`gdk.yml` file](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/configuration.md#gdkyml). This file tells GDK how to configure GitLab to return the correct URLs and other items. To get GDK running in Remote Development, Rails needs to return URLs in a certain scheme (otherwise your browser won't know where to connect). To help this along, we [inject an environment variable](https://gitlab.com/gitlab-org/gitlab/-/issues/415328) into the workspace container. This variable helps us determine the URL in use (which is dynamically generated for each workspace).\n\nWe [now have a script](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/support/gitlab-remote-dev/remote-dev-gdk-bootstrap.sh?ref_type=heads) in GDK that will generate your `gdk.yml` file based on your workspace.\n\n## Creating our devfile\nThe contents of my `.devfile.yaml` looks like this:\n\n```yaml\nschemaVersion: 2.2.0\ncomponents:\n - name: tooling-container\n attributes:\n gl/inject-editor: true\n container:\n # NB! This image is only in use until https://gitlab.com/gitlab-org/gitlab-development-kit/-/merge_requests/3231 is merged!\n image: registry.gitlab.com/gitlab-org/gitlab-development-kit/gitlab-remote-workspace:stingrayza-gdk-remote-dev-add-container\n memoryRequest: 10240M\n memoryLimit: 16384M\n cpuRequest: 2000m\n cpuLimit: 6000m\n endpoints:\n - name: ssh-2222\n targetPort: 2222\n - name: gdk-3000\n targetPort: 3000\n - name: docs-3005\n targetPort: 3005\n - name: pages-3010\n targetPort: 3010\n - name: webpack-3808\n targetPort: 3808\n - name: devops-5000\n targetPort: 5000\n - name: jaeger-5778\n targetPort: 5778\n - name: objects-9000\n targetPort: 9000\n - name: shell-9122\n targetPort: 9122\n```\n\nThis definition comes straight out of the [Workspace docs](https://docs.gitlab.com/ee/user/workspace/#devfile), and opens a number of ports that GDK uses. (For now, I've only tested the port `gdk-3000`, which is the the link to our instance of GDK.)\n\n## From Workspace to GDK\nOnce we have a project with a `.devfile.yaml`, our final step is to [create a new workspace](https://docs.gitlab.com/ee/user/workspace/#create-a-workspace).\n\nAs a part of this step, your cluster will pull the image as defined in the `.devfile.yaml` and start it up. For the GDK image we pre-built, this can take a few minutes.\n\nOnce the workspace is ready, the last step is to follow the link from the UI to connect to the workspace. This will open up a familiar VS Code IDE, with our GDK fork checked out.\n\nBut wait, where's GDK?\n\nWell, the pre-build did most of the work for us, but we still need to take a few final steps before we can claim that GDK is up and running. These have been built into a script we can run from the integrated terminal within the workspace.\n\nTo open a terminal, we can click on the VS Code Hamburger menu (top left), navigate to `Terminal` and select `New Terminal`.\n\nNow we execute the following script, which completes the setup and copies a couple of files over from the pre-built folders:\n\n```shell\nsupport/gitlab-remote-dev/remote-dev-gdk-bootstrap.sh\n```\n\nThis can take up to 15 minutes, but when it's done it should output the magic words — something like the following (note the 3000 in the URL; we specified that in the `.devfile.yaml` earlier):\n\n```shell\nSuccess! You can access your GDK here: https://3000-workspace-62637-2083197-apglwp.workspace.my-workspace.example.net/\n```\n\n## Connect to your GDK\nFollow the link as displayed using Cmd-click or Ctrl-click. After a couple of moments (GDK boot time), you should reach a familiar GitLab login screen.\n\nCongratulations! GDK is now running inside your Remote Development workspace.\n\nTo log in, type `gdk` in your terminal and you'll see the default admin credentials displayed near the bottom:\n\n```shell\n# Development admin account: xxxx / xxxx\n\nFor more information about GitLab development see\nhttps://docs.gitlab.com/ee/development/index.html.\n```\n\nLog into your GDK with the default credentials, change the admin user password, and you're all set!\n\n## Demo of workspace launch\nHere's a demo of launching a workspace in my personal cluster:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/iXq1NnTjnX0\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## How to contribute to GitLab\nIn this article I explained how to get GDK up and running in Remote Development workspaces. This is not without its challenges, but the end result should mean that contributing to GitLab (especially in resource-constrained environments) is quicker and easier.\n\nDo you want to contribute to GitLab? Come and join in the conversation in the `#contribute` channel on GitLab's [Discord](https://discord.gg/gitlab), or just pop in and say \"hello.\"\n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._",[797,775,1157,1158,9,682],"workflow","cloud native",{"slug":1160,"featured":6,"template":685},"gitlab-gdk-remote-development","content:en-us:blog:gitlab-gdk-remote-development.yml","Gitlab Gdk Remote Development","en-us/blog/gitlab-gdk-remote-development.yml","en-us/blog/gitlab-gdk-remote-development",{"_path":1166,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1167,"content":1173,"config":1178,"_id":1180,"_type":13,"title":1181,"_source":15,"_file":1182,"_stem":1183,"_extension":18},"/en-us/blog/gitlab-heroes-unmasked-elevating-my-company-using-gitlab",{"title":1168,"description":1169,"ogTitle":1168,"ogDescription":1169,"noIndex":6,"ogImage":1170,"ogUrl":1171,"ogSiteName":672,"ogType":673,"canonicalUrls":1171,"schema":1172},"GitLab Heroes Unmasked: How I am elevating my company using GitLab","Tickett Enterprises Limited Director Lee Tickett shares the details of his ongoing journey to use the DevOps platform to its fullest.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667569/Blog/Hero%20Images/heroestickett.jpg","https://about.gitlab.com/blog/gitlab-heroes-unmasked-elevating-my-company-using-gitlab","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab Heroes Unmasked: How I am elevating my company using GitLab\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Lee Tickett\"}],\n \"datePublished\": \"2022-05-12\",\n }",{"title":1168,"description":1169,"authors":1174,"heroImage":1170,"date":1175,"body":1176,"category":1033,"tags":1177},[1114],"2022-05-12","\n_A key to GitLab’s success is our vast community of advocates. Here at GitLab, we call these active contributors [\"GitLab Heroes\"](/community/heroes/). Each hero contributes to GitLab in numerous ways, including elevating releases, sharing best practices, speaking at events, and more. The \"GitLab Heroes Unmasked\" series is dedicated to sharing their stories._\n\nLee Tickett, director at IT development and support consultancy Tickett Enterprises Limited, is a GitLab hero and Core team member who continuously contributes to GitLab and provides exceptional feedback. In late 2020, he [wrote a blog](/blog/lee-tickett-my-gitlab-journey/) about how he came upon GitLab and began to use it as his company's platform.\n\nAt that point, his company was using GitLab in the following ways:\n\n- for version control\n- with a custom merge request approval process\n- as a custom UI for streamlined/standardized project creation\n- as an integration with our bespoke helpdesk platform\n- as a Windows runner with fairly basic CI\n\nThis blog picks up where that blog left off and gives insight into how Tickett Enterprises is making the most of GitLab's One DevOps Platform for its helpdesk, CRM integration, CI/CD, and more.\n\n## Migrating the helpdesk\n\nQuite some time ago, I decided to migrate from the bespoke helpdesk platform and use GitLab for issue tracking. Here's [an epic](https://gitlab.com/groups/gitlab-org/-/epics/5323) I created just over two years ago to start discussing my plans.\n\nI built a bespoke migration tool using C#, which connects directly to the existing\nhelpdesk database and pushes the data into GitLab using the API. This includes:\n\n- groups (each company in our helpdesk will become a group in GitLab with a single `Helpdesk` project)\n- issues (every ticket in our helpdesk will become an issue in GitLab, estimates will be included and quotes converted to weights)\n- notes\n- attachments\n- time logs\n- labels (type, class, department, and \"status\" will be migrated to labels)\n\n### Helpdesk workflow\n\nAfter discussing different approaches with the GitLab team and the community, we came up with the first iteration of our workflow process. The status of tickets in our helpdesk system becomes scoped labels in GitLab. It looks similar to the following:\n\n![Workflow Issue Board](https://about.gitlab.com/images/blogimages/workflow-issue-board.png)\n\nWe have two relatively small teams so we can also leverage boards to distribute and manage\nwork within the team:\n\n![Department Issue Board](https://about.gitlab.com/images/blogimages/department-issue-board.png)\n\nWe will be leveraging the [GitLab Triage](https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage)\nRubyGem and [Triage Ops](https://gitlab.com/gitlab-org/quality/triage-ops) project to handle\nreactive and scheduled automation, such as: \n\n- opening pending issues once they reach their due date (this field has been slightly repurposed)\n- nudging users when issues have been pended, but no due date has been assigned\n- nudging the team when issues have not been triaged (labeled, estimates/quotes attached, etc.)\n\nGitLab triage will run as a scheduled pipeline from inside of GitLab, and Triage Ops (formerly known as Triage Serverless) will run as webhooks in AWS Lambda (triggered by webhooks). We may potentially transition some of our existing customizations from C# to GitLab Triage/Triage Ops, too. \n\n## Building out CRM\n\nOne of the biggest challenges moving our helpdesk over to GitLab was the inability to tie issues to Customers. So, roughly a year ago, I decided to start building out a [Customer Relations Management](https://docs.gitlab.com/ee/user/crm/) (CRM) feature. \n\nYou can see some of the work that has gone into the CRM so far: [CRM Merged MRs](https://gitlab.com/gitlab-org/gitlab/-/merge_requests?scope=all&state=merged&label_name[]=CRM).\n\nIt’s surprising how much work is needed for what seems like a mostly simple feature. Despite careful planning, there were many surprises that caused significant headaches. I was hoping to formally release this in December 2021, but it looks like June 2022 is more feasible now.\n\n### Reporting\n\nCompared to our previous bespoke SQL Server Reporting Services (SSRS) report suite pulling directly from our helpdesk, reporting is very limited. We tried using SSRS with a SQL Server linked to our GitLab Postgres server, but kept hitting walls. We are now moving forward using Google Data Studio (with a direct database connection).\n\nAlthough we still have a way to go, we've managed to achieve some really great results.\n\n![Scheduled Pipelines Report](https://about.gitlab.com/images/blogimages/scheduled-pipelines-report.png)\n\nHere's an example of a report we've started to build to increase the visibility of our scheduled interfaces now that we're leveraging CI/CD more.\n\n### Challenges\n\nOne obstacle we were faced with was the inability to achieve a lot of our goals at the instance level. Some GitLab functionality is at the project level, some at the group, and some at an instance. As a result, we had to create a temporary single root group and create all groups beneath it. \n\n## Moving to Linux/Docker for CI/CD pipelines\n\nWe have almost moved completely to Linux/Docker for our CI/CD pipelines, using several custom images:\n\n- our [custom .NET image](https://gitlab.com/tickett/dotnet.core.selenium) simply adds chromedriver to the default `mcr.microsoft.com/dotnet/core/sdk:latest` image to add Selenium support for UI testing\n- our [custom Android/Gradle image](https://gitlab.com/tickett/docker-android-gradle) provides a stable build environment for our Clover apps (which require v1 APK signing no longer supported in Android Studio).\n\nYou can see sample `.gitlab-ci.yml` templates in the relevant projects.\n\nWe now have our test summary and [coverage visualization](https://docs.gitlab.com/ee/ci/testing/test_coverage_visualization.html) displayed in merge requests, which is a total game changer! \n\n## GitLab for intranet\n\nWe've been using SharePoint for as long as I can remember, and I'm not a fan.\n\nAs great as a WYSIWYG interface is, I believe it brings with it:\n\n- a lack of consistency\n- a pretty awful audit trail\n- no review/approval process\n\nSo let's try and learn from the best. Can we use GitLab pages? Absolutely!\n\nWe picked Hugo purely as it seems the most popular (most forked GitLab pages project template). Similarly, the [Relearn theme](https://themes.gohugo.io/themes/hugo-theme-relearn/) seems to be the most popular for docs. \n\nIt's still a work in progress, but we’re exploring a structure similar to:\n\n```text\nClients\n-Client A\n--System A\n--System B\n-Client B\n--System C\n--System D\nInternal\n-Process A\n-Process B\n```\n\nNot too dissimilar to GitLab, but hugely amplified, we want to pull multiple projects, not just our Hugo repo.\n\nThe following is our `.gitlab-ci.yml`:\n\n```yaml\nimage: registry.gitlab.com/pages/hugo:latest\nvariables:\n GIT_SUBMODULE_STRATEGY: recursive\ngrab-docs:\n tags:\n - docker\n image:\n name: ruby:2.7.5-slim\n script:\n - cd ${CI_PROJECT_DIR}\n - gem install gitlab\n - ruby grab_docs.rb\n artifacts:\n untracked: true\n\ntest:lint:\n tags:\n - docker\n image:\n entrypoint: [\"\"]\n name: davidanson/markdownlint-cli2\n script:\n - cp $MARKDOWN_LINT_CONFIG ./.markdownlint-cli2.jsonc\n - markdownlint-cli2 \"content/**/*.md\"\n needs:\n - grab-docs\n\ntest:\n tags:\n - docker\n script:\n - apk add --update --no-cache git\n - hugo\n except:\n - master\n needs:\n - test:lint\n\npages:\n tags:\n - docker\n script:\n - apk add --update --no-cache git\n - hugo\n artifacts:\n paths:\n - public\n only:\n - master\n needs:\n - grab-docs\n - test:lint\n```\n\nThe first `grab-docs` step runs a custom Ruby script to:\n\n- interrogate our GitLab instance, looping through all groups and projects\n- grab the `README.md` and `/doc` folder\n- add frontmatter for last update date and link to the repo \n- update and fix all markdown paths\n\n```ruby\n#!/usr/bin/env ruby\n\nrequire 'fileutils'\nrequire 'gitlab'\n\n$api = Gitlab.client(endpoint: ENV['PRODUCTION_API_ENDPOINT'], private_token: ENV['GITLAB_API_TOKEN'].to_s)\n$projects = $api.projects(per_page: 50)\n\ndef grab_files(project)\n file = $api.file_contents(project.id, 'README.md')\n return unless file&.start_with?('",[266,9,860],{"slug":1179,"featured":6,"template":685},"gitlab-heroes-unmasked-elevating-my-company-using-gitlab","content:en-us:blog:gitlab-heroes-unmasked-elevating-my-company-using-gitlab.yml","Gitlab Heroes Unmasked Elevating My Company Using Gitlab","en-us/blog/gitlab-heroes-unmasked-elevating-my-company-using-gitlab.yml","en-us/blog/gitlab-heroes-unmasked-elevating-my-company-using-gitlab",{"_path":1185,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1186,"content":1192,"config":1199,"_id":1201,"_type":13,"title":1202,"_source":15,"_file":1203,"_stem":1204,"_extension":18},"/en-us/blog/gitlab-heroes-unmasked-lessons-from-early-mistakes",{"title":1187,"description":1188,"ogTitle":1187,"ogDescription":1188,"noIndex":6,"ogImage":1189,"ogUrl":1190,"ogSiteName":672,"ogType":673,"canonicalUrls":1190,"schema":1191},"Overcoming coding challenges to become a valued GitLab hero","Niklas van Schrick shares his journey from learning a new language to becoming an active contributor to GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668009/Blog/Hero%20Images/wrong-way-2.jpg","https://about.gitlab.com/blog/gitlab-heroes-unmasked-lessons-from-early-mistakes","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab Heroes Unmasked: How a difficult start in coding led to being a valued contributor\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Jamie Rachel\"}],\n \"datePublished\": \"2022-04-26\",\n }",{"title":1193,"description":1188,"authors":1194,"heroImage":1189,"date":1196,"body":1197,"category":1033,"tags":1198},"GitLab Heroes Unmasked: How a difficult start in coding led to being a valued contributor",[1195],"Jamie Rachel","2022-04-26","\n\nA key to GitLab’s success is our vast community of advocates. Here at GitLab, we call these active contributors [\"GitLab Heroes\"](/community/heroes/). Each hero contributes to GitLab in numerous ways, including elevating releases, sharing best practices, speaking at events, and more.  [Niklas van Schrick](https://gitlab.com/Taucher2003), who currently works as a Developer trainee, has been an active GitLab Hero since November 2021. \n\nNiklas upholds the [GitLab values](https://handbook.gitlab.com/handbook/values/), especially for transparency, by sharing his trials and discoveries with self-hosted instances. We all can learn from each other’s mistakes, which leads to collaborating to improve processes and build a better developer experience.\n\nHis journey to becoming a GitLab hero is detailed below.\n\n## A difficult beginning\n\n**Niklas van Schrick:** Every developer has to start somewhere. My journey started in May 2019 with Java and Minecraft. While development in Minecraft is great for fast results, based on my experience it’s not the best idea for a beginner.\n\nIt introduces the problem of learning a framework instead of the actual language and it delayed my learning process. I was able to write some functionality as plugins for a server, but I didn't know a single principle of the underlying language, Java. That led to code that was not easily maintainable. For each new functionality, I was building quickly without properly thinking about the structure of my code.\n\nWhen I was starting out, I learned from another developer. Although it is great to have someone guide you through the process, it can also lead to issues. My mistake was believing everything my mentor told me and not looking for solutions myself. In this way, I learned anti-patterns of code design, which led to a full refactoring of the project at a later time. It also slowed down my learning process further as I was asking for help before searching for solutions myself.\n\n## The importance of joining a developer community\n\n**Van Schrick:** In early 2020, we moved our projects to a self-hosted GitLab instance. It was my first experience with [version control](/topics/version-control/). It was a big advantage because we were able to see previous changes and easily identify the causes of bugs. I recommend using a version control system even in the early stages of your development journey, as it makes many things easier and keeps a history of your work. In the beginning, it is totally fine to just push to master or not even use a remote repository.\n\nA big improvement for me was joining a [developer community](/community/), as there are many developers who are happy to help. I learned many new concepts that were widely used by the developers of that community, and this led to much more maintainable code. You don't even have to actively ask in the community to learn new things.\n\nMost of the time, it is enough to keep up with the messages and read the conversations from others. In a helpful developer community, you always have someone who says, \"Why are you doing it like this? There are better ways to do this,\" and offers suggestions to improve the code.\n\n## Contribute, contribute, contribute\n\n**Van Schrick:** Another big step is to make contributions to open source projects. It allowed me to be part of the code review process from others, and learn from it. My first contribution to an open source project, which was not led by me, was a [typo fix in a GitLab view](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/54834). I was surprised at how well the code review went and how fast it got merged. The positive experience encouraged me to join an open source project as a maintainer, and it has been a great experience. I ended up being an active contributor to the GitLab project and a GitLab Hero.\n\n_GitLab welcomes every new contributor and has [many possibilities for your first contribution](/community/contribute/)._\n",[9,682,266],{"slug":1200,"featured":6,"template":685},"gitlab-heroes-unmasked-lessons-from-early-mistakes","content:en-us:blog:gitlab-heroes-unmasked-lessons-from-early-mistakes.yml","Gitlab Heroes Unmasked Lessons From Early Mistakes","en-us/blog/gitlab-heroes-unmasked-lessons-from-early-mistakes.yml","en-us/blog/gitlab-heroes-unmasked-lessons-from-early-mistakes",{"_path":1206,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1207,"content":1213,"config":1221,"_id":1223,"_type":13,"title":1224,"_source":15,"_file":1225,"_stem":1226,"_extension":18},"/en-us/blog/gitlab-webhooks-get-smarter-with-self-healing-capabilities",{"title":1208,"description":1209,"ogTitle":1208,"ogDescription":1209,"noIndex":6,"ogImage":1210,"ogUrl":1211,"ogSiteName":672,"ogType":673,"canonicalUrls":1211,"schema":1212},"GitLab Webhooks get smarter with self-healing capabilities","Introducing changes to webhook self-healing behavior, which reduce manual intervention and improve reliability. Discover the impact on your integrations and how to prepare.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659756/Blog/Hero%20Images/REFERENCE_-_display_preview_for_blog_images.png","https://about.gitlab.com/blog/gitlab-webhooks-get-smarter-with-self-healing-capabilities","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab Webhooks get smarter with self-healing capabilities\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Magdalena Frankiewicz\"}],\n \"datePublished\": \"2024-11-14\",\n }",{"title":1208,"description":1209,"authors":1214,"heroImage":1210,"date":1216,"body":1217,"category":1218,"tags":1219,"updatedDate":1220},[1215],"Magdalena Frankiewicz","2024-11-14","We're excited to announce upcoming changes to how GitLab handles webhooks, aimed at improving reliability and reducing manual intervention. These changes will affect GitLab.com users in the coming weeks. For GitLab Self-Managed users, the current auto-disabling webhook behavior is behind an existing [ops flag `auto_disabling_webhooks`](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#auto-disabled-webhooks). The changes described here will be introduced behind the same feature flag.\n\nThis improvement is the result of a valuable community contribution by [Phawin Khongkhasawan](https://gitlab.com/lifez), exemplifying the power of our open source community in driving GitLab forward.\n\n## What's changing?\n\n- Currently, webhooks that result in 4xx errors become permanently disabled after multiple failures. With this update, all webhooks, regardless of the error type (4xx or 5xx), will have the ability to self-heal.\n- Failing webhooks will be temporarily disabled with an increasing backoff period, up to a maximum of 1 day. After a webhook fails for 40 times successively, it becomes permanently disabled.\n- All types of errors (4xx, 5xx, network errors, etc.) will be treated the same way, allowing for more predictable behavior and easier troubleshooting.\n- Webhooks that are currently permanently disabled will be migrated to be temporarily disabled with 40 failures, so they will remain permanently disabled.\n\n## Why this change matters\n\nReduced manual intervention: You'll no longer need to manually re-enable webhooks that have been disabled due to temporary issues.\n* **Improved reliability:** Webhooks will automatically attempt to recover from transient errors, ensuring your integrations remain functional.\n* **Better handling of temporary issues:** This change accounts for scenarios like temporary outages, deployments, or configuration changes that might cause temporary webhook failures.\n\n## What you need to do\n\n**1. Review your webhooks:** Take this opportunity to review your existing webhooks. If you have any that you no longer need, consider deleting them.\n\n**2. Update your monitoring:** If you rely on webhook status for monitoring, update your processes to account for the new behavior where webhooks may self-heal.\n\n**3. Test your integrations:** Once the change is rolled out, test your integrations to ensure they behave as expected with the new webhook handling.\n\n## Timeline and rollout\n\nThis feature is expected to be rolled out in GitLab 17.11.\n- For GitLab.com users, the changes will be applied automatically.\n- For Self-Managed and Dedicated users, the changes will only affect instances that have the auto_disabling_webhooks ops flag enabled.\n\n## Feedback and support\n\nWe value your feedback! If you encounter any issues or have suggestions regarding this change, please comment on our [webhook feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/503733).\n\nFor any questions or concerns, please reach out to [GitLab Support](https://about.gitlab.com/support/) or consult our [webhooks documentation](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html).\n\nStay tuned for more updates, and thank you for being a part of the GitLab community!","bulletin-board",[266,9,481,750],"2025-03-24",{"slug":1222,"featured":6,"template":685},"gitlab-webhooks-get-smarter-with-self-healing-capabilities","content:en-us:blog:gitlab-webhooks-get-smarter-with-self-healing-capabilities.yml","Gitlab Webhooks Get Smarter With Self Healing Capabilities","en-us/blog/gitlab-webhooks-get-smarter-with-self-healing-capabilities.yml","en-us/blog/gitlab-webhooks-get-smarter-with-self-healing-capabilities",{"_path":1228,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1229,"content":1235,"config":1241,"_id":1243,"_type":13,"title":1244,"_source":15,"_file":1245,"_stem":1246,"_extension":18},"/en-us/blog/gnome-follow-up",{"title":1230,"description":1231,"ogTitle":1230,"ogDescription":1231,"noIndex":6,"ogImage":1232,"ogUrl":1233,"ogSiteName":672,"ogType":673,"canonicalUrls":1233,"schema":1234},"GNOME: two years after the move to GitLab","Extensive CI/CD adoption and easier contributions are just a couple of the benefits of #movingtogitlab for GNOME.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671276/Blog/Hero%20Images/gitlab-gnome.png","https://about.gitlab.com/blog/gnome-follow-up","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GNOME: two years after the move to GitLab\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Nuritzi Sanchez\"}],\n \"datePublished\": \"2020-09-08\",\n }",{"title":1230,"description":1231,"authors":1236,"heroImage":1232,"date":1238,"body":1239,"category":680,"tags":1240},[1237],"Nuritzi Sanchez","2020-09-08","\n\n_It's been a little over two years since the [GNOME project moved to GitLab](/blog/welcome-gnome-to-gitlab/). We wanted to check in to see what’s happening at GNOME these days and see if they had noticed an impact from their migration on their community and their software development lifecycle. To find out the latest, we spoke with [Carlos Soriano](https://www.linkedin.com/in/carlos-soriano-sanchez-4b361240/) and [Sri Ramkrishna](https://www.linkedin.com/in/sriram-ramkrishna/) from GNOME and combined their responses._ \n\n### How are you using GitLab at GNOME? \n\nGNOME is using GitLab’s [Community Edition](/install/ce-or-ee/), which is entirely open source.\n\nAll teams at GNOME have been using GitLab for over a year, including non-coding teams like engagement and design, and the board of directors. The GNOME Foundation’s staff is also using GitLab for things like grant writing and running the foundation. \n\nGNOME is using most features that GitLab has to offer, such as [CI/CD](/topics/ci-cd/) for testing, issue tracking, kanban boards, and labels. Labels and CI/CD are two of the most important features being used across the entire organization. \n\nIn addition to this, GNOME is using GitLab Pages for some of the landing pages for projects, and also to host documentation.\n\nThe only team that hasn’t fully been able to use GitLab is the GNOME translation team since they need a different set of permissions and roles than GitLab provides. For them, Bugzilla was more flexible, and so some of their workflow is still there and in other tools. However, they are using GitLab for issue tracking and coordination. \n\nHere's how [GNOME has set up its GitLab instance](https://gitlab.gnome.org/explore/groups).\n\n### What are some of the changes that you’ve noticed in your community? \n\nThe perception at GNOME is that the move to GitLab has made it easier for people to contribute to GNOME. \n\nOne noticeable difference is that a lot of people are now using the GNOME GitLab instance to host their own projects that are somehow related to GNOME but aren’t part of the core software produced by GNOME. This has increased GNOME’s developer community. \n \nAnother noticeable difference in the community is that, since moving to GitLab, there is more awareness around what CI/CD is and how important it is to the development process. CI/CD is being used extensively throughout the project. \n\nThere is now also more transparency at GNOME, which is both a blessing and a curse. More people from the wider community are able to see what’s happening in the development cycle, and are chiming in on issues and merge requests. This has caused friction at times when things like designs were picked up by the wider community that weren’t ready for comments. \n\nUnfortunately, GNOME does not currently have metrics to share about the changes they’ve seen within their community; however, the overall sentiment has been positive towards the move to GitLab. GNOME is on the path to being a more data-driven organization than it has been in the past, and hopes to share more concrete data in the future. \n\n### What are some of the changes in GNOME’s software development lifecycle?\n\nThe biggest change in GNOME's software development lifecycle is that they can now build images for testing pipelines, something that couldn't be done before moving to GitLab. In the future, they hope to allow people to preview upcoming releases. \n\nDespite the positive changes in testing practices due to the move to GitLab, QA and wider community testing are still challenges for GNOME. (To be fair, GitLab's Global 2020 DevSecOps Survey found [QA/test remain challenging for everyone.](/developer-survey/)) Coordinating teams and members within a large free software project like GNOME is similar to doing so at a large commercial organization -- mostly around coordinating milestones and features spanning multiple teams. This means that GNOME has to hack around the limits of the GitLab Community Edition with homegrown tools.\n\nAnother big change to GNOME’s software development lifecycle is that there is now a closer relationship between designers and maintainers because there is more transparency on what the design team is doing. \n\nThe move to GitLab has also shortened the cycle for developing [Flatpak](https://flatpak.org/), a software deployment and package management technology created by members of the GNOME community. The community can now automatically build Flatpak bundles and test changes against those instead of committing things to code. This shortens the feedback for QA, design, and releasing the software. \n\n### What do you think GitLab is doing well in supporting open source communities and what else would you like to see?\n\nOne of the things that GNOME appreciates most about GitLab is its transparency. It helps to know the roadmap and see what is being worked on in order to form proper expectations and plan ahead. \n\nGNOME is also happy that GitLab is continuing to grow its Developer Relations team and has invested in hiring an open source program manager. They are encouraged that GitLab now has a dedicated resource to understand the specific needs of open source communities on GitLab and craft a strategy to enable growth in this segment.\n\nUsing the Community Edition adds some challenges for open source communities since they often have to ask for features to be ported down. There are common features that are important to a lot of open source projects and communities and it is important to identify those and port them down. Having someone who can start conversations around these features is important. \n\nAnother area of opportunity for GitLab is to foster a closer relationship between the GitLab team and the community. GNOME would find it especially helpful to get to know GitLab engineers and product managers, in order to feel more comfortable collaborating with them. \n\nWhile there is more work to be done on this, GitLab is actively taking this feedback into account and is rolling out changes to the [GitLab forum](https://forum.gitlab.com/). Instead of being just a place to ask technical questions and find answers, there will soon be more of a social component as well.\n\n### What kind of organizations would you recommend GitLab for?\n\nLarge open source organizations that require coordination among various contributors will benefit from using GitLab. The project or organization doesn’t have to be super big, but when you have 20-40 people, or if your project is something that the industry depends on, GitLab is a great choice due to its features that enable project management, issue tracking, and CI for testing. \n\nAlso, if you’re into open source software, then GitLab is your best option from a feature to feature comparison. \n\n### What’s new at GNOME and what are some of the new things on the horizon?\n\nGNOME is continuing to invest in expanding its contributor base. Not only are they working on initiatives to improve and scale newcomer onboarding, but they are also hosting a [Community Engagement Challenge](https://www.gnome.org/news/2019/08/gnome-foundation-launches-coding-education-challenge/), along with Endless, to get a younger generation into open source. The Challenge has multiple stages and includes over $65,000 USD in cash and prizes. Phase One winners were recently announced at this year’s [GUADEC](https://events.gnome.org/event/1/), GNOME’s annual core conference. \n\nThis year’s GUADEC was done remotely due to the pandemic and was a huge success! If you missed it, be sure to check out the [GUADEC YouTube channel](https://www.youtube.com/user/GUADEC/) for videos of the talks. Coming soon will be the annual [GNOME.Asia Summit](https://www.gnome.asia/), and the [Linux App Summit](https://linuxappsummit.org/), which will be co-hosted again with [KDE](https://kde.org/). GNOME also hopes to hold a first-ever Pan African GNOME Summit (PAGS) in the upcoming year. \n\nFrom a technical standpoint, GNOME is trying to remove their over-reliance on mailing lists by using GitLab projects instead. The release team now makes “freeze break” requests in a GitLab project, and the security team uses a web form that opens a confidential issue in a GitLab project through the GitLab Service Desk feature.\n\nAfter enthusiastically adopting CI pipelines, GNOME projects are now trying to optimize their workflows to minimise time spent, bandwidth, and energy consumption.\n\nLast but not least, some GNOME members are working on implementing community health metrics in order to evolve into a more data-driven organization. The [App Ecosystem working group at CHAOSS](https://chaoss.community/participate/) was founded earlier this year as a result, and includes members from GNOME and KDE, among others. New members are encouraged to join!\n\n",[266,682,9],{"slug":1242,"featured":6,"template":685},"gnome-follow-up","content:en-us:blog:gnome-follow-up.yml","Gnome Follow Up","en-us/blog/gnome-follow-up.yml","en-us/blog/gnome-follow-up",{"_path":1248,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1249,"content":1255,"config":1263,"_id":1265,"_type":13,"title":1266,"_source":15,"_file":1267,"_stem":1268,"_extension":18},"/en-us/blog/google-summer-of-code-2024-contribute-to-gitlab-and-git-to-prepare",{"title":1250,"description":1251,"ogTitle":1250,"ogDescription":1251,"noIndex":6,"ogImage":1252,"ogUrl":1253,"ogSiteName":672,"ogType":673,"canonicalUrls":1253,"schema":1254},"Google Summer of Code 2024: Contribute to GitLab and Git to prepare","Learning how to contribute to GitLab and Git can help you get ready to apply for Google's program for open source development.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663000/Blog/Hero%20Images/tanukilifecycle.png","https://about.gitlab.com/blog/google-summer-of-code-2024-contribute-to-gitlab-and-git-to-prepare","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Google Summer of Code 2024: Contribute to GitLab and Git to prepare\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Nick Veenhof\"},{\"@type\":\"Person\",\"name\":\"Christian Couder\"}],\n \"datePublished\": \"2023-12-20\",\n }",{"title":1250,"description":1251,"authors":1256,"heroImage":1252,"date":1259,"body":1260,"category":680,"tags":1261},[1257,1258],"Nick Veenhof","Christian Couder","2023-12-20","Google Summer of Code ([GSoC](https://summerofcode.withgoogle.com/)), a program that helps bring new contributors into open source software development, is just around the corner. So now is the time to start learning [how to contribute to GitLab](https://about.gitlab.com/community/contribute/) or Git and prepare ideas for GSOC 2024. GitLab has participated in GSOC for more than five years of the program's 20-year history, and the mentorship opportunity aligns well with our \"[Everyone can contribute](https://handbook.gitlab.com/handbook/company/mission/)\" mission.\n\nIn 2023, GitLab team members mentored GSoC contributors working on GitLab and Git open source projects throughout the 12-week program. One example was the “Unify ref-filter formats with other --pretty formats” Git project. \n\n## Implementing new formatting options for Git commands\n\nKousik Sanagavarapu was selected as a 2023 GSOC contributor and was mentored by [Christian Couder](https://gitlab.com/chriscool), staff backend engineer on the GitLab Gitaly::Git team.\n\nKousik’s work focused on implementing some [new formatting options for Git commands](https://summerofcode.withgoogle.com/programs/2023/projects/rck3kmq2) like `git branch`, `git tag` and `git for-each-ref`. These commands use a formatting mechanism called the “ref-filter” format. The formatting options Kousik worked on were already available for other commands like `git log`, that use a different formatting mechanism called the “pretty” format. So the work involved porting these options from the “pretty” format to the “ref-filter” format.\n\nThanks to Kousik’s work, it’s now possible to use a number of new placeholders like %(signature), %(authoremail:mailmap), or %(describe) in the –format option of `git branch`, `git tag`, and `git for-each-ref` to get more information about the commits that branches, tags, or refs in general point to. [Read the documentation](https://git-scm.com/docs/git-for-each-ref/2.43.0#_field_names) for a description of these placeholders.\n\nThese improvements are available in the recently released Git 2.43.\n\n## How GSOC works\n\nOpen source organizations who participate – such as GitLab and Git – have to propose projects and provide mentors. Selected contributors are helped by the mentors and paid by Google during 12 or more weeks while they work on their projects. Contributors are evaluated three times by mentors: after a “Community Bonding” period, in the middle of the coding period, and after the coding period for a final evaluation. \n\n## How to participate as a contributor\n\nTo apply to become a contributor for GSOC 2024, check out the [GSoC website](https://summerofcode.withgoogle.com/) and the [Google Open Source blog](https://opensource.googleblog.com). Interested parties should register [when selected organizations are announced](https://opensource.googleblog.com/2023/02/mentor-organizations-announced-for.html), which will happen in a few months. \n\nContributors will then be selected by the mentors after they have made a small contribution and after they have prepared an application document that details how they plan to achieve the proposed project they want to work on.\n\nProspective contributors can start learning about GitLab or Git right now to be fully ready to make a small contribution and prepare an application. [As Google says](https://opensource.googleblog.com/2023/02/mentor-organizations-announced-for.html), “The most successful applications come from contributors who start preparing now.” \n\nGitLab has a lot of documentation and tutorials [to learn how to contribute](https://about.gitlab.com/community/contribute/), while Git has a [Hacking Git page](https://git.github.io/Hacking-Git/) with a lot of helpful links.\n\n## How GitLab team members participate\n\nGitLab participates in GSOC as an open source organization and team members from different functional areas volunteer to mentor contributors and propose projects for them to work on. \n\nIn 2023, GitLab team members mentored contributors on a number of GitLab-related projects, including Pajamas Migration with the GitLab Foundations Team and improving the documentation for the contributor journey to GitLab.\n\n## How Git developers participate\n\nThe Git project also participates in GSoC as an open source organization, and Git developers who are interested in mentoring propose projects, and then select GSoC contributors.\n\nLast summer, in addition to the \"Unify ref-filter formats with other --pretty formats\" project, Git developers proposed the \"[More Sparse Index integrations](https://summerofcode.withgoogle.com/programs/2023/projects/Rkbc1Abe)\" project.\n\n## Mentoring and GitLab \n\nGitLab’s mission is “Everyone can contribute” and we understand that helping potential contributors through mentoring can achieve this goal. In addition to participating in external programs like GSOC and [Outreachy](https://about.gitlab.com/blog/outreachy-sponsorship-winter-2020/), GitLab has internal mentoring programs, including a [CEO Shadow program](https://handbook.gitlab.com/handbook/ceo/shadow/) and a [Mentorship program for women](https://handbook.gitlab.com/handbook/company/culture/inclusion/tmrg-gitlab-women/mentorship-program/).\n\nLearn more about [mentoring at GitLab](https://handbook.gitlab.com/handbook/people-group/learning-and-development/mentor/).",[682,266,9,1262,817],"git",{"slug":1264,"featured":6,"template":685},"google-summer-of-code-2024-contribute-to-gitlab-and-git-to-prepare","content:en-us:blog:google-summer-of-code-2024-contribute-to-gitlab-and-git-to-prepare.yml","Google Summer Of Code 2024 Contribute To Gitlab And Git To Prepare","en-us/blog/google-summer-of-code-2024-contribute-to-gitlab-and-git-to-prepare.yml","en-us/blog/google-summer-of-code-2024-contribute-to-gitlab-and-git-to-prepare",{"_path":1270,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1271,"content":1277,"config":1285,"_id":1287,"_type":13,"title":1288,"_source":15,"_file":1289,"_stem":1290,"_extension":18},"/en-us/blog/gsoc-at-gitlab",{"title":1272,"description":1273,"ogTitle":1272,"ogDescription":1273,"noIndex":6,"ogImage":1274,"ogUrl":1275,"ogSiteName":672,"ogType":673,"canonicalUrls":1275,"schema":1276},"Google Summer of Code at GitLab – some intern highlights","GitLab team members mentored student interns and helped them develop open source projects during Google Summer of Code.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682129/Blog/Hero%20Images/gsoc_cover.jpg","https://about.gitlab.com/blog/gsoc-at-gitlab","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Google Summer of Code at GitLab – some intern highlights\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Aakriti Gupta\"}],\n \"datePublished\": \"2021-09-01\",\n }",{"title":1272,"description":1273,"authors":1278,"heroImage":1274,"date":1280,"body":1281,"category":298,"tags":1282},[1279],"Aakriti Gupta","2021-09-01","\n\nGitLab participated in [Google Summer of Code](https://summerofcode.withgoogle.com/) for the first time this year. We hosted four student interns to work with us on four different projects under the supervision of two or three mentors each.\n\nFor the past 16 years, Google has hosted the Summer of Code to introduce students to the world of open source. Over the summer, student interns work on a project with an open source organization and are closely mentored by the developers of the open source project. More than [200 organizations](https://summerofcode.withgoogle.com/organizations/) participated this year.\n\nWe started off the summer with a two-week long community bonding period to get our students familiar with how we work at GitLab and helped them set-up their local development environments. During the 10-week program we worked through scoped projects with regular check-ins and [a final demo](https://youtu.be/--Neg5pwwnI) to conclude the program.\n\n## Meet the students\n\n### Alejandro Rusi\n[Alejandro](https://gitlab.com/rusi-ruse), a CS student from Argentina, worked on [enabling Courseware as Code](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/gitlab-gsoc-2021/-/issues/4) through his project. Check out his [video presentation here](https://youtu.be/qgQQ4MgnKR4) and read [more about the project here](https://alejandro-rusi.gitlab.io/2021/05/31/toward-courseware). Alejandro said: \n\n> They quickly made me feel welcome and part of Gitlab. All of the topics to choose from were very interesting, and all mentors seemed great.\n>\n> I would like to highlight a moment during GSoC where I wasn't able to do my normal workload due to a personal problem, and my mentors where incredibly supportive and understanding.\n\n### Anshuman Singh\n\n[Anshuman](https://gitlab.com/singhanshuman), a CS student who joined us from India, collaborated with the Static Analysis team to work on [writing vulnerability detection rules for SAST](https://gitlab.com/groups/gitlab-org/-/epics/6089). Anshuman said: \n\n> For a beginner, it is normal to feel insecure about achieving specified tasks in your group.\n>\n> I am glad that my mentors Julian and Ross were there at every step of the program to provide support and clear my doubts about anything. It was such an enriching experience for me. I am glad to be the part of GitLab for this Google Summer of Code edition. :)\n\n### Cyrine Gamoudi\n\nA computer engineering student from Tunisia, [Cyrine](https://gitlab.com/CyrineG1) worked with the Static Analysis team on [porting SAST and Secret Detection rails platform code to GitLab CE](https://gitlab.com/gitlab-com/marketing/community-relations/contributor-program/gitlab-gsoc-2021/-/issues/6).\n\n> The project went very smoothly. I was able to achieve almost all of the planned milestones and I'm currently still in contact with my mentors, working on what was left. I enjoyed getting an inside look into how open source projects are maintained as well as how they evolve through time. It was also interesting to see the impact of historical architectural decisions on what could and could not be done later on.\n\n### Shubham Kumar\n\nNow in his final year of schooling, [Shubham](https://gitlab.com/imskr) from India helped the Geo team [improve our backup and restore features](https://shubhamkumar.live/blog/Improving-Backup-and-Restore-For-GitLab-GSoC-2021/).\n\n> Mentorship was amazing. Mentors helped me a lot whenever I had problem. Contributing to GitLab is very welcoming. I absolutely loved it.\n\n## GitLab mentors share their thoughts \n\n### What went well?\n\n- External organization\n - The folks at Google were well organized, the entire schedule was available right at the beginning and the reminder emails were very informative and well timed.\n - We used it to create our own calendar and that was very helpful.\n- Asynchronous working style\n\n> Having recorded meetings and an agenda doc was really helpful, especially for cases where one mentor went on holidays it was easy to catch up on things. Writing up a planning epic with our student Anshuman was really helpful to make sure that we were on the same page and to clearly define the project deliverables. - [Julian Thome](/company/team/#julianthome), senior vulnerability research engineer at GitLab. \n>\n> Related to this, GitLab's default mode of working that favors asynchronous communication and the written form feels very well-aligned with GSoC and working across time zones. Even without a large amount of overlap between working for myself and our mentee, it felt very effective and like we had a strong foundation in place to support communication and workflows (just point to our existing handbook and docs). - [Lucas Charles](/company/team/#theoretick), staff backend engineer, Secure, at GitLab.\n\n - It was really useful to have two mentors on the project. This way it was easier sharing responsibilities and managing other priorities, especially when one mentor was out.\n\n### What could be improved? \n\n- We had considerable engagement on the project proposal issues but not as many applications.\n- GitLab is huge and a complex object model for students to hold onto.\n- Running GitLab locally requires a lot of resources.\n- The fork contribution model wasn't efficient for some projects.\n\n\n- Define the required skills for the project better\n> Since GSoC is 10 short weeks, making sure that the student has acquired all the required skills for the project before it starts would have allowed us to reduce the overall mentoring workload and to use mentoring time more efficiently by focusing on the project objectives. Next year, we can make better use of the \"Community Bonding\" period by giving the students more guidance and some time upfront to learn the required technologies/languages so that they are fully prepared before the coding phase begins. - Julian\n\n- A clear \"victory task,\" possibly in the frontend, would have made some of the projects more \"visible\" and would have felt more complete.\n\n## Wrapping up\n\n[Tetiana Chupryna](/company/team/#brytannia), senior backend engineer, Secure, at GitLab sums up the experience of the mentors really well: \n\n> This program gave me a feeling of deep fulfilment as I was able to look at GitLab through the eyes of a community contributor and I hope that this project was useful for our student in her career, and she will return to GitLab one day as a contributor (we were lucky to have her on this project). So it was a summer well spent 🍎.\n\nWe hope GitLab can be back at Google Summer of Code next year!\n\n[Cover image](https://unsplash.com/photos/7RQf2X6aXXI) by [Raphaël Biscaldi](https://unsplash.com/@les_photos_de_raph)\n{: .note}\n\n",[266,9,1283,682,1284],"google","remote work",{"slug":1286,"featured":6,"template":685},"gsoc-at-gitlab","content:en-us:blog:gsoc-at-gitlab.yml","Gsoc At Gitlab","en-us/blog/gsoc-at-gitlab.yml","en-us/blog/gsoc-at-gitlab",{"_path":1292,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1293,"content":1299,"config":1306,"_id":1308,"_type":13,"title":1309,"_source":15,"_file":1310,"_stem":1311,"_extension":18},"/en-us/blog/how-gitlab-empowers-translators-with-more-context",{"title":1294,"description":1295,"ogTitle":1294,"ogDescription":1295,"noIndex":6,"ogImage":1296,"ogUrl":1297,"ogSiteName":672,"ogType":673,"canonicalUrls":1297,"schema":1298},"How GitLab empowers translators with more context","Learn about the new translation context enhancement feature in GitLab. Join our translation community and help translate GitLab to your language.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097922/Blog/Hero%20Images/Blog/Hero%20Images/gitlabflatlogomap_gitlabflatlogomap.png_1750097921899.png","https://about.gitlab.com/blog/how-gitlab-empowers-translators-with-more-context","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How GitLab empowers translators with more context\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Oleksandr Pysaryuk\"}],\n \"datePublished\": \"2024-12-09\",\n }",{"title":1294,"description":1295,"authors":1300,"heroImage":1296,"date":1302,"body":1303,"category":680,"tags":1304},[1301],"Oleksandr Pysaryuk","2024-12-09","GitLab is continuously translated by our global community of translators and proofreaders. Through [Crowdin](https://docs.gitlab.com/ee/development/i18n/translation.html), they help make our product more accessible to the world by translating it into 78 languages. GitLab translation community members are volunteer translators, working professionals who are GitLab users, and even [university students contributing to translators as part of their classroom projects](https://about.gitlab.com/blog/behind-the-scenes-of-gitlab-korean-translation/).\n\n### How the GitLab open-core model supports translators\n\nWhile this community collaboration is powerful, translators often face a crucial challenge: understanding the full context of the text that they are translating.\n\nGreat translation isn't just about converting words – it's about preserving meaning, intent, and usability in a target language. Software translation requires a unique blend of skills. Great translators usually specialize in multiple linguistic domains as well as the technical domain of the product itself. They perform myriad translation-adjacent tasks such as:\n\n* ensuring accuracy and consistency of technical terminology\n* creating new glossary terms for new concepts\n* adhering to the style and tone\n* navigating the complexity of [CLDR pluralization rules](https://www.unicode.org/cldr/charts/46/supplemental/language_plural_rules.html)\n* understanding the translatability of composite messages and how to provide feedback to improve the source by making it localizable\n\nTranslators spend lots of time researching context, asking questions, and reading [GitLab product documentation](https://docs.gitlab.com/). Without proper context, even simple phrases can be mistranslated, potentially confusing or disrupting user workflows. What sets [GitLab apart is its open-core model](https://about.gitlab.com/blog/gitlab-is-open-core-github-is-closed-source/), which allows translators to access most of the product development context directly at the source. This transparency empowers them to actively contribute as true [co-creators of the GitLab global product](https://handbook.gitlab.com/handbook/company/mission/#mission).\n\n### Introducing our new context-enhancement feature\n\nTo support these needs and empower translators with context, GitLab has developed a new feature: we now [embed into each translatable string a contextual link](https://docs.gitlab.com/ee/development/i18n/translation.html#context) (more specifically, a link to our global in-product search) that lets translators locate all instances of that string in the codebase. These links allow translators to rely on [Git blame](https://docs.gitlab.com/ee/user/project/repository/files/git_blame.html) to trace every string's history – from its current location in code, through commits in merge requests, and all the way up to the original planning discussions.\n\nFor example, when you are translating **Rotate**, the **AccessTokens|** [namespace](https://docs.gitlab.com/ee/development/i18n/externalization.html#namespaces) suggests that the context is, well, *access tokens*. However, there is no additional visual context for what **Rotate** means, and translators are left to wonder, guess, and provide the best possible assumption in a target language.\n\nWith the new context enhancement, here is what translators are now able to do:\n\n1. Click the URL in the **See where this string is used in code** section.\n\n![see where this string is used in code section](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750097928929.png)\n\n2. Review the [result of the code search](https://gitlab.com/search?project_id=278964&search=%22%28%5B%5E%3A%5D%28+%29%2B%3F%7C_%5C%5C%28%29%5B%27%5C%22%60%5DAccessTokens%5C%5C%7CRotate%5B%27%5C%22%60%5D%22+%28file%3A%5C.js%24+or+file%3A%5C.vue%24+or+file%3A%5C.rb%24+or+file%3A%5C.erb%24+or+file%3A%5C.haml%24%29+%28file%3A%5Eee%2Fapp%2F+or+file%3A%5Eee%2Flib%2F+or+file%3A%5Eee%2Fconfig%2F+or+file%3A%5Eee%2Flocale%2F+or+file%3A%5Eapp%2F+or+file%3A%5Elib%2F+or+file%3A%5Econfig%2F+or+file%3A%5Elocale%2F%29®ex=true), and click the **View blame** icon:\n\n![Screen with View blame icon](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image6_aHR0cHM6_1750097928930.png)\n\n3. Follow the link with the relevant merge request ([Introduce rotation of personal tokens in UI](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/169954)):\n\n![Link with relevant merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image7_aHR0cHM6_1750097928932.png)\n\n4. On the **Commits** page, follow the link to the actual merge request:\n\n![Commits page with link](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750097928934.png)\n\n5. Watch the screen recording that the software engineer added to the merge request:\n\n![screen recording in merge request](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image5_aHR0cHM6_1750097928936.png)\n\n6. Research even further by going to:\n a. The linked issue [Introduce renew expired token capability in UI](https://gitlab.com/gitlab-org/gitlab/-/issues/241523) or its parent epic [Rotate Token through the UI](https://gitlab.com/groups/gitlab-org/-/epics/14563):\n\n![linked issue and parent epic](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750097928938.png)\n\nb. The [related merge request that updates the GitLab product documentation](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/172916):\n\n![related merge request to update GitLab product documentation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097929/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750097928940.png)\n\nAll these research steps will lead translators to better understand the technical concept of *access token rotation* and why the token rotation functionality was added, how it works, and what problem it solves for users.\n\nWith this rich research trail, translators get the maximum amount of context that will help provide the technically accurate and linguistically correct translation for the seemingly simple word **Rotate**.\n\nThis approach goes far beyond traditional translation aids like providing screenshots or exploring the product user interface. Translators can now fully understand the context by:\n\n* deriving context from paths and naming conventions used in code\n* viewing screenshots or video recordings that are added to original merge requests\n* reading original planning and development discussions\n* following the engineering, copywriting, and product management decision-making process that has led to specific wording\n\n### More AI-powered contextual features coming up\n\nThe GitLab Localization team isn't stopping here. We are working on [more context-enhancement features](https://gitlab.com/groups/gitlab-com/localization/-/epics/81), including AI-powered tools to help translators understand string usage and placement. Imagine a system where translators could interact with an agent by asking questions or proactively receiving immediate code-aware responses about where and how strings are used in the product UI.\n\n> ### Join our [community on Crowdin](https://docs.gitlab.com/ee/development/i18n/) as a translator or a [proofreader](https://docs.gitlab.com/ee/development/i18n/#proofreading), try these new context features, and let us know how we can make the [translation experience and our product even better](https://gitlab.com/gitlab-com/localization/localization-team/-/issues/259).\n",[266,817,1305,9],"product",{"slug":1307,"featured":6,"template":685},"how-gitlab-empowers-translators-with-more-context","content:en-us:blog:how-gitlab-empowers-translators-with-more-context.yml","How Gitlab Empowers Translators With More Context","en-us/blog/how-gitlab-empowers-translators-with-more-context.yml","en-us/blog/how-gitlab-empowers-translators-with-more-context",{"_path":1313,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1314,"content":1320,"config":1326,"_id":1328,"_type":13,"title":1329,"_source":15,"_file":1330,"_stem":1331,"_extension":18},"/en-us/blog/how-modern-devops-practices-are-changing-the-operations-role",{"title":1315,"description":1316,"ogTitle":1315,"ogDescription":1316,"noIndex":6,"ogImage":1317,"ogUrl":1318,"ogSiteName":672,"ogType":673,"canonicalUrls":1318,"schema":1319},"How modern DevOps practices are changing the operations role","Today, the ops role is about far more than just keeping the lights on. Here's how modern DevOps practices are expanding ops' responsibilities.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663982/Blog/Hero%20Images/2022-devsecops-survey-blog-header.png","https://about.gitlab.com/blog/how-modern-devops-practices-are-changing-the-operations-role","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How modern DevOps practices are changing the operations role\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n \"datePublished\": \"2022-10-19\",\n }",{"title":1315,"description":1316,"authors":1321,"heroImage":1317,"date":1322,"body":1323,"category":1033,"tags":1324},[834],"2022-10-19","\nRemember NoOps, the idea that automation would eliminate the operations role completely? Fast forward a few years and the idea of NoOps today seems almost laughable. In today’s modern DevOps teams it’s safe to say it’s really _“AlltheOps_,” at least based on the results of our [2022 Global DevSecOps Survey](/developer-survey/).\n\n## An expanding role\n\n[No DevOps job is static](/blog/the-changing-roles-in-devsecops/), but ops pros are experiencing truly dramatic changes to their work lives. In fact, ops pros reported seven areas of responsibility now added to their plates thanks to modern DevOps practices:\n\n- Managing the cloud\n- Managing the hardware/infrastructure\n- Maintaining the toolchain\n- DevOps coaching\n- Responsibility for automation\n- Overseeing all compliance and audits\n- Platform engineering\n\nManaging the cloud and hardware/infrastructure were the two tasks most frequently named, and they were split nearly evenly down the middle, with roughly 50% of ops pros focusing on one or the other task primarily. Another area – [maintaining the toolchain](/blog/too-many-toolchains-a-devops-platform-migration-is-the-answer/) – is apparently now a job shared with developers, as devs also told us they were spending more time on toolchain maintenance and integration than ever before. That’s not surprising: 44% of teams reported they use between two and five tools, while 41% use between six and 10 tools. That’s a lot of tools, which is clearly one reason for the added ops support. \n\nCompliance and audits are another “new to Ops” area of focus, and this added emphasis comes at a time when organizations everywhere are trying to avoid security breaches with [an increased focus on compliance](/blog/the-importance-of-compliance-in-devops/). It’s a time-consuming process: The majority of ops pros told us they spend between one-quarter and half their time [on audits and compliance](/blog/what-you-need-to-know-about-devops-audits/), a 15% increase since 2021. Almost 25% of ops pros spend between half and three-quarters of their time on these tasks. \n\n## Keeping the balls in the air\n\nThe rising use of [DevOps platforms](/topics/devops-platform/) (75% of our respondents said their organizations already use a DevOps platform or plan to add one this year) is driving operations team members toward [platform engineering](/topics/devops/what-is-a-devops-platform-engineer/). Operations pros are also doubling down on tasks that were likely more informal in the past: DevOps coaching and responsibility for automation. The focus on automation is clearly paying off: In 2022, just shy of 25% of ops pros said their modern DevOps practices were fully automated, up 5 points from 2021 and nearly 17 points from 2020. All told, 68% of ops pros said their DevOps teams were “completely” or “mostly” automated.\n\nAnd while ops is adding new responsibilities thanks to modern DevOps, developers are picking up tasks that have traditionally belonged to operations:\n\n- Nearly 77% of devs can provision their own environments.\n- Roughly 38% of developers instrument the code.\n- Another 38% monitor and respond to the infrastructure. \n- 36% of devs said they’re on-call for in-app production alerts.\n\nThe role-swapping doesn't stop there: Nearly 50% of ops pros said they're solely responsible for security on their DevOps teams, up 20% from last year. To put that into perspective, 53% of security respondents told us they felt security was *everyone's* responsiblity.\n\n## Ops, modern DevOps, and TMI\n\nOps pros’ new roles have created some surprising by-products, namely loads of data that teams aren’t necessarily set up to manage effectively. In fact, many of today’s operations teams have a “too much information” problem. A full 39% of ops pros said the DevOps data they need exists but accessing and managing it is difficult. Another 27% said they’re “overwhelmed” by the amount and scope of the data while 14% don’t know what data they need or say their organizations don’t track it. Less than 20% of ops pros say they have the data they need and it’s easy to work with.\n\nHow do you see the ops role changing in the modern DevOps world? Let us know in the comments.\n",[775,1325,9],"developer survey",{"slug":1327,"featured":6,"template":685},"how-modern-devops-practices-are-changing-the-operations-role","content:en-us:blog:how-modern-devops-practices-are-changing-the-operations-role.yml","How Modern Devops Practices Are Changing The Operations Role","en-us/blog/how-modern-devops-practices-are-changing-the-operations-role.yml","en-us/blog/how-modern-devops-practices-are-changing-the-operations-role",{"_path":1333,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1334,"content":1340,"config":1346,"_id":1348,"_type":13,"title":1349,"_source":15,"_file":1350,"_stem":1351,"_extension":18},"/en-us/blog/how-to-start-a-great-oss-project",{"title":1335,"description":1336,"ogTitle":1335,"ogDescription":1336,"noIndex":6,"ogImage":1337,"ogUrl":1338,"ogSiteName":672,"ogType":673,"canonicalUrls":1338,"schema":1339},"How to start a great OSS project","In a modern DevOps world it's never been more critical to embrace open source. Here's everything you need to know to get started.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679362/Blog/Hero%20Images/contribute-open-source-jobs.jpg","https://about.gitlab.com/blog/how-to-start-a-great-oss-project","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How to start a great OSS project\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Mike Vanbuskirk\"}],\n \"datePublished\": \"2022-10-18\",\n }",{"title":1335,"description":1336,"authors":1341,"heroImage":1337,"date":1343,"body":1344,"category":680,"tags":1345},[1342],"Mike Vanbuskirk","2022-10-18","\nIf you spend any time coding, you've probably considered starting an OSS project at some point. Of course, the natural temptation is to immediately sit down and start writing code. That's a great approach that many projects have started from, but what about when it's time to let others contribute?\n\nAn OSS project is as much about community as it is code, and the key to building a good project is providing an inviting, productive place for that community to work and create. How can new contributors be onboarded smoothly? What kind of maintenance and automation will allow the project to scale beyond the scope of its original creator's time and resources? This article hopes to answer a few of these questions and provide first-time project maintainers with a solid foundation for launching a great OSS project.\n\n## Create a great README.md\n\nA README file is the \"entry point\" to an OSS project. Most distributed version control software hosting platforms like GitLab make the README file the first thing a visitor sees when viewing the repo. A good README manages to convey important information about a project while focusing on ease of navigation and reading and grabs the attention of potential contributors and users.\n\nTo start, maintainers should familiarize themselves with [Markdown](https://www.markdownguide.org), the markup language used for most OSS project documentation files like README. Markdown is a simple, elegant tool for crafting content and it's helpful to be aware of its features and capabilities.\n\nFor the README file itself, there are some things maintainers can include that will help drive productive participation and engagement.\n\n### Overview of the project\n\nA great way to draw attention to your project is to lead with a UI or CLI screenshot of the software. Even better: record some basic usage and convert it to a GIF using an OSS (of course!) tool like [Terminalizer](https://github.com/faressoft/terminalizer). The overview should also include the \"why\" of the project; it should be clear what problem or problems the project solves, and what drove the maintainer to create the project.\n\n### How to install and use it\n\nOSS project users can often become OSS project contributors; a well-run and well-documented project goes a long way towards bringing more contributors into the fold. Users should be presented with clear, concise, and most importantly correct instructions for installing and using the software contained in the project. Potential users and contributors are likely to be put off by confusing, complex, or non-functional installation instructions.\n\n### Links to documentation\n\nNot all project documentation does or even should fit inside the README file. Your project likely depends on one or more programming languages, as well as the many development tools, libraries, and modules in the language ecosystem. The README should serve as a project portal; linking to third-party documentation as needed, rather than as a comprehensive collection of all relevant documentation in one place.\n\n### Links to Code of Conduct\n\nThe global OSS project community is made up of a great many individuals, representing a rich, diverse spectrum of backgrounds and identities. With that in mind, an OSS project needs to provide a welcoming, inclusive Code of Conduct with firm and clear rules around expected behavior and decorum. One option is [Contributor Covenant](https://www.contributor-covenant.org/). A shared understanding of what defines good conduct is a pillar of a good community.\n\n### Links and instructions for reporting bugs or requesting features\n\nIf OSS project users become contributors, a great way to foster this transition is to make it easy to report bugs or request features. Ideally, this is where your README file links to your CONTRIBUTING.md file as well.\n\nA great example of an OSS project with an awesome README is [Leapp](https://github.com/Noovolari/leapp#readme); here’s another [example on GitLab](https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/README.md). This [Hacker News discussion](https://news.ycombinator.com/item?id=30106264) further demonstrates the power of the OSS project community in helping drive better engagement.\n\n## Creating a great CONTRIBUTING.md is important too\n\nThe CONTRIBUTING.md file represents another very important piece of documentation in an OSS project. Ideally, a CONTRIBUTING file should contain clear instructions for how individuals can get started contributing to your project. It's also important to be cognizant of first-time contributors to your project versus first-time contributors to OSS. For first-time OSS participants, it can be helpful to include links [like this](https://opensource.guide/how-to-contribute/).\n\nThe focus should be on technical detail; clear, concise instructions for how to clone, build, test, and commit are just some of what should be included. An adequate amount of detail and context is important, especially around what pre-requisite knowledge is expected and where it can be gained. The goal is to provide a deterministic path for contributors, with the end-state being a well-formed Merge Request. The [GitLab document](https://about.gitlab.com/community/contribute/) provides an excellent example.\n\nThe documentation for contributing should include:\n\n### An introductory message\n\nThis should be a warm and welcoming message that encourages individuals to participate, but also gives them the right foundation and context for creating successful and helpful commits.\n\n### How to set up a development environment\n\nDevelopment environments can be tricky to get right. Contributors may be working from a variety of different operating systems, IDEs, and hardware. Focus on making your project as environment agnostic as possible. Containerization tools like [Docker](https://www.docker.com) can help by isolating dependencies within the boundaries of a container environment. Ideally, as the project grows, you can take advantage of CI/CD automation to standardize things like linting and testing in a controlled environment or provide a one-click deployment option via something like [GitPod](https://www.gitpod.io).\n\n### How to run tests\n\nEarly in the project lifecycle, testing will probably be a minimal, non-comprehensive affair. Contributors will need to have clear guidance on setting up local development and testing to ensure their commits don't break existing functionality. Tests are another aspect of contributions that benefit heavily from automation.\n\n### Links to resources, including a style guide, the primary discussion medium, etc...\n\nContributors will almost always need to refer to additional resources to help them complete their work. The Contributing doc is a great place to link helpful and relevant documentation, including style guides, as well as third-party information. You should also highlight where the primary discussion medium for the project is hosted, which can be something like Slack, Discord, or within the repository itself.\n\n### Specific instructions on reporting bugs, and submitting changes/features\n\nBe specific and explicit with instructions for bugs, changes, and features. Providing this up-front reduces the amount of time that might be spent requesting basic formatting changes or additional information that's typically always needed on these topics.\n\n### Less experienced contributors? Suggest first-time issues\n\nContributing to OSS can be very intimidating for first-time contributors. It can be extremely helpful not just for your project, but for the entire OSS ecosystem to label issues that are ideal for first-time contributions. GitLab uses the [quick win](https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=created_date&state=opened&label_name%5B%5D=quick%20win&first_page_size=20) label to highlight such issues.\n\nSome criteria that make for good first issues:\n- User-facing documentation updates\n- Adding unit tests\n- Well-scoped bug fixes, with an obvious end-state or success metric\n- Writing good code comments. Python docstrings are great for defining class and method behavior and are read by a variety of tools.\n\n## Choose a good license\n\nAn often overlooked, but no less important, part of starting an OSS project is choosing a good license. The sometimes verbose legal language of OSS licenses, as well as the scare stories of them being applied inappropriately, can be intimidating to first-time contributors.\n\nFortunately, tools like [Choose a license](https://choosealicense.com/) are available, allowing maintainers to make an informed choice about which license model is the best fit for the project.\n\nThe MIT and Apache licenses are common choices for OSS projects, but each project and maintainer are unique. Something else to consider is that a lot of OSS contributors often work professionally as software engineers, and may be subject to rules that prohibit or limit OSS contributions based on intellectual property concerns.\n\n## Use templates to make OSS maintenance easier\n\nEarly in the life of your OSS project, there are likely to only be a few contributors. The inflow of pull requests, issues and feature work will generally be pretty manageable at this stage. The need for automation and well-defined processes won't be immediately obvious, but once the project scales it's very easy to feel overwhelmed without some structure in place.\n\nTemplates are a great way to help establish some formal processes for dealing with common workflows in OSS projects. For most version control platforms, templates are Markdown documents that allow maintainers to pre-define the format and structure of things like issues, pull requests, and merge requests. There are some good examples of [issue templates here](https://gitlab.com/gitlab-org/gitlab/-/tree/master/.gitlab/issue_templates), as well as [templates for merge requests](https://gitlab.com/gitlab-org/gitlab/-/tree/master/.gitlab/merge_request_templates).\n\nGiving contributors a clear picture of the required information up front saves a lot of time and headache, and avoids the dance of maintainers having to frequently ask follow-up questions on issues to get a clear picture of the actual technical problem at hand. Once your project hits a critical mass of participation, it's very important to have a good structure of templates in place to allow you, and eventually other maintainers to leverage their time.\n\nAnother easy win for ease of maintenance is committing a well-formed gitignore file that's relevant to the type of project and language choice. The [SCM Git docs](https://git-scm.com/docs/gitignore) provide great documentation.\n\n## Automate your OSS project\n\nLeveraging maintainer resources and time is the key to successfully growing an OSS project. Beyond templates, some platforms allow maintainers to automate significant portions of the building and deployment of their projects.\n\nOne piece of automation that should be familiar to anyone with experience in a DevOps environment is Continuous Integration/Continuous Delivery(CI/CD) pipelines. CI/CD tools enable engineers to define a repeatable workflow that can lint, analyze, test, and deploy code while providing fast feedback on the outcome of each step. For example: a project using Python could integrate [pyflakes](https://gitlab.com/dnsmichi/api-playground/-/blob/main/.gitlab-ci.yml) into its CI workflow, ensuring all contributions are tested with a common standard for linting and syntax. Even [Markdown code can be tested](https://gitlab.com/gitlab-de/playground/markdown-lint-challenge/-/blob/main/.gitlab-ci.yml) this way! If maintainers want to take this pattern even further, a tool like [MKDocs can be integrated into a CI/CD workflow](https://gitlab.com/dnsmichi/opsindev.news/-/blob/main/.gitlab-ci.yml) as well to automatically generate documentation for the project. For busy maintainers, automating the typically tedious process of writing and updating documentation is a huge win.\n\nWith automation deployed, status badges can be a great way to provide contributors with a holistic view of the state of things like test coverage, build status, CI/CD health, and the current release version. The status badges on [this project](https://gitlab.com/gitlab-de/use-cases/iac-tf-vuln-module) provide both users and contributors with an at-a-glance understanding of pipeline health, and the most current release version of the module.\n\nFor anyone thinking about starting a project or already maintaining an open source project, the [GitLab for Open Source](https://about.gitlab.com/solutions/open-source/) program provides maintainers access to Ultimate features for free, which includes many valuable Security features as well as additional CI minutes.\n\n## Great OSS projects aren't just code\n\nCode is of central importance to open source software. However, an OSS project is more than just code. It's a community of diverse individuals participating in a shared goal. To help achieve that goal, it's crucial to provide a well-maintained space for that community to participate.\n\nSaying thanks for every contribution, welcoming everyone, and encouraging them to stay with feedback can also help make the project an inviting space. Along the way, you'll find new maintainers, and friends as well.\n\n_GitLab developer evangelist Michael Friedrich made significant contributions to this post._\n",[775,682,9],{"slug":1347,"featured":6,"template":685},"how-to-start-a-great-oss-project","content:en-us:blog:how-to-start-a-great-oss-project.yml","How To Start A Great Oss Project","en-us/blog/how-to-start-a-great-oss-project.yml","en-us/blog/how-to-start-a-great-oss-project",{"_path":1353,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1354,"content":1360,"config":1367,"_id":1369,"_type":13,"title":1370,"_source":15,"_file":1371,"_stem":1372,"_extension":18},"/en-us/blog/how-we-built-a-stack-overflow-community-questions-analyzer-and-you-can-too",{"title":1355,"description":1356,"ogTitle":1355,"ogDescription":1356,"noIndex":6,"ogImage":1357,"ogUrl":1358,"ogSiteName":672,"ogType":673,"canonicalUrls":1358,"schema":1359},"How We Built a Stack Overflow Community Questions Analyzer","We wanted to better understand what Stack Overflow GitLab Community members wanted to know, so we automated a way to keep track of it all. Here's a step-by-step look at how we did it.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667552/Blog/Hero%20Images/gitlabonstackoverflow.png","https://about.gitlab.com/blog/how-we-built-a-stack-overflow-community-questions-analyzer-and-you-can-too","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How we built a Stack Overflow Community questions analyzer (and you can too)\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"William Arias\"}],\n \"datePublished\": \"2022-04-28\",\n }",{"title":1361,"description":1356,"authors":1362,"heroImage":1357,"date":1364,"body":1365,"category":748,"tags":1366},"How we built a Stack Overflow Community questions analyzer (and you can too)",[1363],"William Arias","2022-04-28","\nBeing part of the GitLab collective is an opportunity to learn first hand about the challenges the community using the DevOps Platform is facing. As a [Collective Member](https://stackoverflow.com/collectives/gitlab) logging between 2-3 times a week in StackOverflow reading the questions and discussion posted about GitLab and manually sorting them by 'Recent Activity', 'Trending' and using Dates, I asked myself: how can we leverage this wealth of data and discover feedback, while finding the most frequent topics where the community has questions? \n\nThis would be an opportunity to get a quick overview of topics where the community regularly needs help; this would also make it easier for us to create relevant content for them. Manually sorting and extracting the text of each question wouldn’t be sustainable, so creating an automated way would be the most efficient way to proceed.\n\n## Experimenting with data-oriented content creation\n\nFinding out what the community is working on, and what they need help with while using GitLab, can help us to create better educational content that could expand their understanding of GitLab. To achieve this goal, the solution I created after a few iterations is depicted below:\n\n![Alt text for your image](https://about.gitlab.com/images/blogimages/fontes.png)\n\nWhere the Bill Of Materials consists mainly of:\n\n- GitLab DevOps Platform\n- Stackoverflow API\n- Kubernetes Cluster\n- Open Source Python libraries:\n- scikit-learn (TF-IDF)\n- Streamlit (front-end)\n- Spacy \n\nI leveraged the GitLab DevOps Platform to organize the projects using groups:\n\n![Alt text for your image](https://about.gitlab.com/images/blogimages/organize.png)\n\nThe Loader project pulls questions about GitLab from the StackOverflow API, pre-processes the text and makes it usable for a second project: a Visualizer to create customized dashboards. \n\nThe automated process executed using the DevOps Platform is outlined below: \n\n![Alt text for your image](https://about.gitlab.com/images/blogimages/automatedprocess.png)\n\n- Pull data from [StackOverflow API](https://api.stackexchange.com/docs)\n- Preprocess the response extracting relevant fields from returned JSON\n- Build a corpus and calculate TF-IDF\n- Scan for security vulnerabilities\n- Review Application and display its resulting dashboards using [Streamlit](https://streamlit.io/)\n- Deploy the built application to a Kubernetes cluster\n\nLoader and Visualizer projects have their own codebase and pipelines, which is helpful if different teams need to work separately on them. However, one project can require the other, which raises the need for cross-project automation. \n\n![Alt text for your image](https://about.gitlab.com/images/blogimages/pipeline.png)\n\nThis scenario means a [multi-project pipeline](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html) is useful to automate the whole process. The multi-project pipeline enables use cases such as:\n\n- As an NLP Developer I want to work on the NLP Pipeline in the Loader Project and automatically trigger the creation of a new visualization \n- As a Streamlit Developer I want to work independently in the buttons and data visualization without touching any NLP Pipeline backend \n\nThe outlined process above is automatically run defining the steps in a [multi-project pipeline](https://docs.gitlab.com/ee/ci/pipelines/downstream_pipelines.html) sharing artifact:\n\n![Alt text for your image](https://about.gitlab.com/images/blogimages/demo1-gif.gif)\n\n## Finding the most frequently occurring words\n\nThe Feature Engineering step will help me to analyze the text in the whole dataset of GitLab questions. Using a simple yet powerful technique – TF-IDF – we aim to find the most relevant terms utilized by the community. By using this technique in the pipeline execution, I represent words in numerical values and later rank them in order of importance. This approach serves as a baseline for further improvements. More detail about this algorithm can be found [here](https://en.wikipedia.org/wiki/Tf%E2%80%93idf).\n\n## Did we achieve any success?\n\nOne run of the multi-pipeline in our solution results in dashboards such as this one:\n\n![Alt text for your image](https://about.gitlab.com/images/blogimages/demo2-gif.gif)\n\nAs an end-user of these dashboards I can immediately conclude that the main source of questions are around GitLab CI, pipelines and usage of Docker images. Not bad for a first run! Having the data processed enables us to ask more questions and use data to answer it, such as, what are the questions from the highest [StackOverflow reputation](https://stackoverflow.com/help/whats-reputation) users ? \n\n![Alt text for your image](https://about.gitlab.com/images/blogimages/questions.png)\n\nCould these questions be inspiration for tutorials for the most advanced users, or the implementation of a new feature? \n\nBecause everyone can contribute, let's take a look at the users who just started gaining their StackOverflow reputation:\n\n![Alt text for your image](https://about.gitlab.com/images/blogimages/contributors.png)\n\nThe question about access and reading/writing permissions in Portuguese is interesting. It makes me wonder about content localization and GitLab meetups in Portuguese-speaking countries. Not surprisingly, there were also \tquestions about GitLab CI too as the text processing and ranking found most relevant in the corpus. \n\nDid we achieve any success? Yes, using a baseline technique such as TF-IDF sped up by DevOps practices allowed us to find out relevant terms and help us to understand where the majority of the community needs help in their DevOps journey. I have automated many steps that will allow me to focus on data exploration and possible implementation of more complex NLP Techniques rather than infrastructure allocation or manual input of commands and tests.\n\n![Alt text for your image](https://about.gitlab.com/images/blogimages/demo-reduced.gif)\n\nAs a Technical Marketing Manager, I want to create content that is relevant to enable or inspire the community to succeed. \n\nA personal take away: Educating about the latest GitLab DevOps platform capabilities and the problems they solve is important and so is keeping an eye on the content that might not be related to a new feature but is needed right now.\n\nAre we done? No, quoting Da Vinci's altered quote about [Art](https://www.artshub.com.au/news/features/art-is-never-finished-only-abandoned-262096-2370305/#:~:text=Lottie%20Consalvo%20in%20her%20studio,writers%2C%20and%20creatives%20would%20recognise) but with software: \"Software is never finished, only abandoned.\"\n\nThere is room for improvement and adding capabilities to this project. We continue iterating, listening to the community, and we encourage you to clone these projects, try it yourself, and adjust it with the topics that make sense to you. Create a merge request to improve the codebase and suggest new dashboards ideas!\n\nExplore the [group of projects](https://gitlab.com/tech-marketing/ad-fontes) and take a look at the [dashboard](https://bit.ly/3jeTFQp).\n",[775,266,9],{"slug":1368,"featured":6,"template":685},"how-we-built-a-stack-overflow-community-questions-analyzer-and-you-can-too","content:en-us:blog:how-we-built-a-stack-overflow-community-questions-analyzer-and-you-can-too.yml","How We Built A Stack Overflow Community Questions Analyzer And You Can Too","en-us/blog/how-we-built-a-stack-overflow-community-questions-analyzer-and-you-can-too.yml","en-us/blog/how-we-built-a-stack-overflow-community-questions-analyzer-and-you-can-too",{"_path":1374,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1375,"content":1381,"config":1388,"_id":1390,"_type":13,"title":1391,"_source":15,"_file":1392,"_stem":1393,"_extension":18},"/en-us/blog/integrating-with-gitlab-secure",{"title":1376,"description":1377,"ogTitle":1376,"ogDescription":1377,"noIndex":6,"ogImage":1378,"ogUrl":1379,"ogSiteName":672,"ogType":673,"canonicalUrls":1379,"schema":1380},"How open source contributions accelerate GitLab Secure","Community contributions and an open integration framework allows anyone to extend GitLab Secure","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668622/Blog/Hero%20Images/group-rowing-collaboration.jpg","https://about.gitlab.com/blog/integrating-with-gitlab-secure","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How open source contributions accelerate GitLab Secure\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Taylor McCaslin\"}],\n \"datePublished\": \"2020-10-22\",\n }",{"title":1376,"description":1377,"authors":1382,"heroImage":1378,"date":1384,"body":1385,"category":680,"tags":1386},[1383],"Taylor McCaslin","2020-10-22","\nWhen you think about security you probably imagine locks, gates, and closed systems. This is the more traditional approach to security but modern security is much more open and collaborative. If you want to build the most secure systems, there is nothing better than building those systems in the open. Open security practices allow you to get fast feedback from a broad audience with diverse perspectives, helping you build better more holistic solutions. That's our approach to building [GitLab Secure](/stages-devops-lifecycle/secure/) at GitLab. We're leveraging amazing open source security projects, the collective contribution of the wider community, and providing an open integration system for anyone to build on top of GitLab security scanners.\n\n## Shifting left\n\nTraditional security approaches are opaque and late in the development life cycle. Security scans are performed by isolated security experts long after developers write code, often after it's deployed to production. GitLab aims to make security an integrated and continuous process. That's why we've built [GitLab Secure directly integrated into the DevOps life cycle](/solutions/security-compliance/). We are taking security tools and \"shifting left\" to make these tools more accessible to developers earlier in the development life cycle and integrated directly into developers' workflows.\n\n![Traditional Security vs DevSecOps with GitLab](https://about.gitlab.com/images/blogimages/traditional-security-vs-integrated.png)\n\nWe created a detailed survey to learn more about the [2020 DevSecOps Landscape](/developer-survey/#security). The results of the survey indicated that security is still a significant hurdle for most organizations that use DevOps, and show:\n\n- Only 13% of companies give developers access to the results of [application security](/topics/devsecops/) tests\n- Over 42% said testing happens too late in the lifecycle\n- 36% reported it was hard to understand, process, and fix any discovered vulnerabilities\n- 31% found prioritizing vulnerability remediation an uphill battle\n\nThese statistics illustrate why we are building security scanning directly into GitLab with our Secure features. We want to provide integrated security tools to broaden access and make it easier for everyone using GitLab to write more secure code.\n\n## Integrating security tools into everyday workflows\n\nGitLab Secure enables accurate, automated, and continuous assessment of your applications and services, allowing users to proactively identify vulnerabilities and weaknesses to minimize security risk. Secure is not an additional step in your development process nor an additional tool to introduce to your software stack. It is woven into your DevOps cycle, which allows you to adapt security testing and processes to your developers (and not the other way around).\n\nToday [GitLab Secure](/stages-devops-lifecycle/secure/) offers support for a variety of security scanning tools including:\n- [Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)\n- [Dynamic Application Security Testing (DAST)](https://docs.gitlab.com/ee/user/application_security/dast/)\n- [Container Scanning](https://docs.gitlab.com/ee/user/application_security/container_scanning/)\n- [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)\n- [License Scanning](https://docs.gitlab.com/ee/user/compliance/license_compliance/index.html)\n- [Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/)\n- [API Fuzzing](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/)\n- [Coverage Fuzzing](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/)\n\nAll of these tools provide unique approaches to finding security problems. No one tool is best at everything, so we wanted to provide a way to leverage many tools in an integrated way, so you're always getting the most relevant security results. Take a look at how GitLab Secure integrates all these tools into common developer workflows on GitLab:\n\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/XnYstHObqlA\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n## Democratizing security\n\nWith GitLab Secure, we've laid the foundation for bringing security tools directly into developers' workflows. At GitLab, we believe in a world where [everyone can contribute](/company/culture/#everyone-can-contribute). [Collaboration](https://handbook.gitlab.com/handbook/values/#collaboration) and [transparency](https://handbook.gitlab.com/handbook/values/#transparency) are part of our core values. This approach changes the way we build security features. That's why as part of our [community stewardship promise](/company/stewardship/#promises) we've made all our open source based [SAST scanners available for all users](/releases/2020/08/22/gitlab-13-3-released/#sast-security-analyzers-available-for-all), we offer [open source projects and nonprofits free access to our best features](/solutions/open-source/join/), and we've created a [security scanner integration framework](https://docs.gitlab.com/ee/development/integrations/secure.html) to allow anyone to contribute security scan tools. Our entire [product strategy and vision](/direction/secure/) is also open source, so everyone can understand our vision for an integrated, accessible, and democratic approach to security. Together we can build a more open and modern security approach that helps developers everywhere write more secure code.\n\n## Integrate with GitLab Secure\n\nOut of the box, GitLab provides a variety of pre-integrated and actively managed open source security tools, such as [SAST's 16 analyzers](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) that all support automatic language detection to always run the most relevant security tool. While GitLab will continue to update and build first-party integrations we wanted to ensure that GitLab contributors and integration partners could easily extend GitLab Secure for third-party tools. Our [open integration framework](https://docs.gitlab.com/ee/development/integrations/secure.html) makes it easy for anyone to leverage all of the [features of GitLab Secure](/pricing/feature-comparison/) with any scanning tool they may want to integrate. You can see all the tools GitLab users have requested support for and even add your own request in our [tracking epic](https://gitlab.com/groups/gitlab-org/-/epics/297).\n\n## Community contributions\n\nWith our open integration framework we've seen members of the [GitLab community](/community/) contribute additional security scanners, help maintain the existing open source scanners we offer and expand the list of supported languages and frameworks we support. Our community contributors are helping every GitLab user have access to more accurate, sophisticated, and relevant security results. Here are some recent community contribution highlights:\n\n- [Mobile SAST support via MobSF](https://gitlab.com/gitlab-org/gitlab/-/issues/233777) (contribution by [@williams.brian-heb](https://gitlab.com/williams.brian-heb)) - [GitLab 13.5 Release MVP](/releases/2020/10/22/gitlab-13-5-released/#mvp)\n- [Adding Helm Chart support](https://gitlab.com/gitlab-org/gitlab/-/issues/36755) (contribution by [@agixid](https://gitlab.com/agixid))\n- [Performance improvements to Fuzz testing](https://gitlab.com/gitlab-org/security-products/analyzers/fuzzers/pythonfuzz/-/merge_requests/1) (contribution by [@jvoisin](https://gitlab.com/jvoisin))\n- [Updates to secret detection](https://gitlab.com/gitlab-org/gitlab/-/issues/205172) (contribution by [@tnir](https://gitlab.com/tnir))\n- [Dependency scanning buxfixes](https://gitlab.com/gitlab-org/gitlab/-/issues/205172) (contribution by [@fcbrooks](https://gitlab.com/fcbrooks))\n- [Updates to Security Scanner underlying operating systems](https://gitlab.com/gitlab-org/gitlab/-/issues/216781) (contribution by [@J0WI](https://gitlab.com/J0WI))\n- [Contributions for .NET Framework Support](https://gitlab.com/gitlab-org/security-products/analyzers/security-code-scan/-/merge_requests/14) (contribution by [@agixid](https://gitlab.com/agixid))\n- [See the full list of Secure community contributions](https://gitlab.com/gitlab-org/gitlab/-/issues?scope=all&utf8=%E2%9C%93&state=all&label_name[]=Community%20contribution&label_name[]=devops%3A%3Asecure)\n\nThe open source nature of GitLab allows the community to help improve, maintain, and contribute features within GitLab. This is the ultimate value of open source. Even if we don't offer something, you can always extend or modify the behavior of GitLab to accomplish your goal. When compared to closed-source Security vendors, this is a huge benefit. The impact these contributions have is massive as GitLab Secure is used by tens of thousands of customers and performs hundreds of thousands of security scans every month. If you are interested in contributing, check out our [contributor program](/community/contribute/) and [contributor documentation](https://docs.gitlab.com/ee/development/contributing/).\n\n## Integration partners\n\nCommunity contributions aren't the only way GitLab Secure is being extended. We have a variety of integration partners who provide security integrations that further expand the suite of security tools available to GitLab users. Check out the [GitLab Security integrations](/partners/#security) our partners offer. If you are a security vendor interested in integrating with GitLab, [join our partner program](/handbook/alliances/integration-instructions/) today.\n\n## Looking ahead\n\nWe've come a long way in the past few years with GitLab Secure and we're not done yet. Our [vision is bold (and open source)](/direction/secure/) and [our investment in security is large](https://internal.gitlab.com/handbook/product/investment/). [Security is a team effort](/direction/secure/#security-is-a-team-effort) and we hope you'll join us on our mission to help developers write more secure code.\n\n## Read more about GitLab SAST:\n\n* GitLab [Secure Direction](/direction/secure/)\n* Learn more about [integrating with GitLab Secure](https://docs.gitlab.com/ee/development/integrations/secure.html)\n* View the latest [October 2020 GitLab security trends](/blog/gitlab-latest-security-trends/)\n\nCover image by [Mitchell Luo](https://unsplash.com/@mitchel3uo) on [Unsplash](https://unsplash.com/s/photos/rowing-team)\n{: .note}\n",[108,775,1387,266,9,682],"security",{"slug":1389,"featured":6,"template":685},"integrating-with-gitlab-secure","content:en-us:blog:integrating-with-gitlab-secure.yml","Integrating With Gitlab Secure","en-us/blog/integrating-with-gitlab-secure.yml","en-us/blog/integrating-with-gitlab-secure",{"_path":1395,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1396,"content":1402,"config":1408,"_id":1410,"_type":13,"title":1411,"_source":15,"_file":1412,"_stem":1413,"_extension":18},"/en-us/blog/join-the-new-gitlab-collective-on-stack-overflow",{"title":1397,"description":1398,"ogTitle":1397,"ogDescription":1398,"noIndex":6,"ogImage":1399,"ogUrl":1400,"ogSiteName":672,"ogType":673,"canonicalUrls":1400,"schema":1401},"Join the new GitLab Collective on Stack Overflow!","Now you can learn and share your best tips and tricks about version control, CI/CD, all-remote, DevOps platforms and more on the new GitLab Collective on Stack Overflow. Here's how to get started.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668402/Blog/Hero%20Images/code-gitlab-tanuki.png","https://about.gitlab.com/blog/join-the-new-gitlab-collective-on-stack-overflow","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Join the new GitLab Collective on Stack Overflow!\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Matt Nguyen\"}],\n \"datePublished\": \"2021-11-08\",\n }",{"title":1397,"description":1398,"authors":1403,"heroImage":1399,"date":1405,"body":1406,"category":726,"tags":1407},[1404],"Matt Nguyen","2021-11-08","\nWe’re very excited to announce the GitLab community has a new home on Stack Overflow: the GitLab Collective.\n \nWe know we already have a great relationship with our contributors and the open source community but [the GitLab Collective](https://stackoverflow.com/collectives/gitlab) on Stack Overflow will take that to the next level. Our collective will be a place contributors and developers can learn and share about version control, CI/CD, DevSecOps, all-remote, DevOps platforms and more.\n \n“Community is at the core of GitLab’s mission,” says [Brendan O’Leary](/company/team/#brendan), senior developer evangelist at GitLab. “With a contributor community of more than 2,600 people, we have a strong community aligned with our mission – to create a world where everyone can contribute. We believe the GitLab Collective will be a place where we can discover feedback and create opportunities for the GitLab community to contribute to Stack Overflow’s community.”\n\nFinding your way around the GitLab Collective is easy: look for the “gitlab” tag, or add “gitlab” to a more specific product search, like “gitlab-ci.” Ask questions, dive into in-depth technical data, or browse through how-to guides and articles. Contributions to the GitLab Collective will be tracked on a leaderboard, and if you’re a top contributor, we might tap you as a “Recognized Member” (basically a GitLab-approved guide who can help with questions and make recommendations).\n\n![GitLab on Stack Overflow](https://about.gitlab.com/images/blogimages/gitlabonstackoverflow.png){: .shadow}\n\n## What comes next\n\nIf you’re already a Stack Overflow user, please head to the GitLab Collective and start answering questions (you can ask questions too!). If you’re not a Stack Overflow user, we’d highly recommend you [join the community](https://stackoverflow.com). And remember you’ll earn reputation points on Stack Overflow by participating. \n\nRight now we’re in the process of creating the documentation that will outline how to become a “Recognized Member” on the GitLab Collective on Stack Overflow. As a Recognized Member, people can recommend answers and write articles on the GitLab Collective to help the community and show off their expertise. Recognized Members will also get a special badge on Stack Overflow that denotes them as a Recognized Members. More to come on this program so watch this space!\n",[266,817,9],{"slug":1409,"featured":6,"template":685},"join-the-new-gitlab-collective-on-stack-overflow","content:en-us:blog:join-the-new-gitlab-collective-on-stack-overflow.yml","Join The New Gitlab Collective On Stack Overflow","en-us/blog/join-the-new-gitlab-collective-on-stack-overflow.yml","en-us/blog/join-the-new-gitlab-collective-on-stack-overflow",{"_path":1415,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1416,"content":1422,"config":1428,"_id":1430,"_type":13,"title":1431,"_source":15,"_file":1432,"_stem":1433,"_extension":18},"/en-us/blog/join-us-for-hacktoberfest-2021",{"title":1417,"description":1418,"ogTitle":1417,"ogDescription":1418,"noIndex":6,"ogImage":1419,"ogUrl":1420,"ogSiteName":672,"ogType":673,"canonicalUrls":1420,"schema":1421},"Join us for Hacktoberfest 2021!","GitLab is participating in this year's Hacktoberfest, and your contributions to open source projects hosted on GitLab.com will count. No tricks, just treats here!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749671856/Blog/Hero%20Images/gitlab-hacktoberfest_blog-dark.png","https://about.gitlab.com/blog/join-us-for-hacktoberfest-2021","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Join us for Hacktoberfest 2021!\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Christos Bacharakis\"}],\n \"datePublished\": \"2021-10-01\",\n }",{"title":1417,"description":1418,"authors":1423,"heroImage":1419,"date":1425,"body":1426,"category":680,"tags":1427},[1424],"Christos Bacharakis","2021-10-01","\nIt’s October 2021, and we have quite a few treats in store. In addition to celebrating the 10th anniversary of the GitLab open source project, GitLab Inc. will be participating in Hacktoberfest, an event dedicated to increasing contributions to open source projects that's now in its eighth year. This has been widely requested by the open source community for years, so we’re thrilled to see GitLab support rolled out!\n\nThanks to [DigitalOcean](https://www.digitalocean.com/blog/hacktoberfest-is-back-2021/), the organization behind Hacktoberfest, people can now contribute to open source projects that are hosted on GitLab.com.\n\nIt’s easy, sign up on [the Hacktoberfest website](https://hacktoberfest.digitalocean.com) using your GitLab account and explore the available projects to contribute. \n\nProject maintainers who want their projects to participate in Hacktoberfest should follow the steps described on the Hacktoberfest website.\n\n## Contributing to GitLab\n\nAt GitLab, we want to make it easy for everyone to contribute by offering diverse opportunities to participate. Back-end or front-end, localization or tech writing, getting started or experienced contributor, GitLab team members have hand picked a series of issues and epics available for everyone to contribute to during Hacktoberfest.\n\nFind these opportunities through the Hacktoberfest website, or by [searching for projects that have added the “Hacktoberfest” topic](https://gitlab.com/explore/projects?topic=hacktoberfest) on GitLab.\n\nMore information can be found on the [GitLab Hacktoberfest event page](https://about.gitlab.com/events/). If you need help, you can always reach out via [our gitter channel](https://gitter.im/gitlab/gitlab), where GitLab team members and GitLab contributors hang out.\n\n## Treats galore!\n\nTo celebrate the launch of Hacktoberfest on the GitLab ecosystem, we’re offering GitLab swag to the five contributors with the highest number of accepted merge requests to the [GitLab open source project](https://gitlab.com/gitlab-org/gitlab). Merge requests to GitLab created in October 2021 and merged by the 15th of November will count towards this initiative. \n\nWe’re also sending GitLab swag to all contributors whose first merge request [to the GitLab open source project](https://gitlab.com/gitlab-org/gitlab) is created and merged during that time, so newcomers are very welcome!\n\nWe are excited to join DigitalOcean during the launch of Hacktoberfest on GitLab, and look forward to your contributions. If you’d like to share your story with us, please reach out via contributors@gitlab.com or the [Contributors Gitter Channel](https://gitter.im/gitlabhq/contributors).\n\nHappy contributing!\n",[266,9,276],{"slug":1429,"featured":6,"template":685},"join-us-for-hacktoberfest-2021","content:en-us:blog:join-us-for-hacktoberfest-2021.yml","Join Us For Hacktoberfest 2021","en-us/blog/join-us-for-hacktoberfest-2021.yml","en-us/blog/join-us-for-hacktoberfest-2021",{"_path":1435,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1436,"content":1441,"config":1446,"_id":1448,"_type":13,"title":1449,"_source":15,"_file":1450,"_stem":1451,"_extension":18},"/en-us/blog/katrin-contributor-post",{"title":1437,"description":1438,"ogTitle":1437,"ogDescription":1438,"noIndex":6,"ogImage":809,"ogUrl":1439,"ogSiteName":672,"ogType":673,"canonicalUrls":1439,"schema":1440},"Meet GitLab Contributor Katrin Leinweber","Katrin Leinweber shares her experience contributing to GitLab documentation and translations.","https://about.gitlab.com/blog/katrin-contributor-post","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Meet GitLab Contributor Katrin Leinweber\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2019-07-17\",\n }",{"title":1437,"description":1438,"authors":1442,"heroImage":809,"date":1443,"body":1444,"category":680,"tags":1445},[677],"2019-07-17","\n\nFor this edition of the [GitLab contributor blog posts](/blog/tags.html#contributors), I'm\nexcited to introduce [Katrin Leinweber](https://gitlab.com/katrinleinweber). Let's get to know more about her!\n\n### Can you tell us where you live and what you like about your area?\n\nI live in [Hanover, Germany](https://www.google.com/maps/place/Hanover,+Germany/@52.3815678,9.6148482,10.97z/data=!4m5!3m4!1s0x47b00b514d494f85:0x425ac6d94ac4720!8m2!3d52.3758916!4d9.7320104),\nwhich is transitioning from a car manufacturing hub to a more modern and diversified city.\nThe city is reasonably bicycle friendly with large parks and gardens, which are worth a visit.\nI don't find Hanover too touristy, which is probably a plus for us citizens.\n\n### How long have you used GitLab and why did you want to make a contribution?\n\nI started using GitLab CE at my university in April 2015 as a backup server for my PhD thesis,\ndata analysis scripts, etc. [My first merge request](https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/6531)\nwas simply fixing a typo in a blog post.\n\n### You also help translating GitLab into German. How is that different from making contributions via MRs and why is translating GitLab important to you?\n\nLocalization is one of the tasks that got me into contributing to open source software projects in general.\nEven though I myself don't need a localized UI, I think it's valuable to many people to be able to\nuse a complex software in their native language. Since I think that GitLab has\n[valuable uses beyond programming](https://openbiblio.social/@katrinleinweber/102258903864249981),\nI hope lowering the barrier to entry for non-programmers will help support those use cases.\nAlso for me, doing quick translations is a sort of productive procrastination.\n\n![Canoeing on Hanover's river Leine (image credit Corinna John, [NABU Laatzen](https://www.nabu-laatzen.de/)](https://about.gitlab.com/images/blogimages/Katrin_Leinweber.jpg){: .shadow.medium.center}\nCanoeing on Hanover's river Leine\n{: .note.text-center}\n\n### What has been your experience contributing to GitLab?\n\nTechnically, it's pretty straightforward and something people should be familiar with if\nthey've contributed to other projects or used tools like GitHub. Every time I contribute,\nI feel like I'm living (in) the future where projects allow people to change something of theirs.\n\nHowever, we shouldn't forget that \"No, this Wiki page is only editable by colleagues in the XYZ department\"\nis still the default in so many work environments. So the future isn't quite here for everyone yet.\n\nOne of the things that bothers me about GitLab's contribution process is the fact that even simple changes\n– like documentation updates – get pushed into the same CI pipeline as code changes in many cases.\nIt seems like a waste of electricity. Maybe not in terms of absolute kWh, but since the risk of anything\nbreaking due to a typo fix or an updated hyperlink is almost zero, those kWh are effectively wasted.\nThere should be a smarter way to minimize human effort in preventing build breakages than to use\nmore CPU cycles for testing. We all know that humanity can't afford to waste resources anymore.\n\nIn that vein, I wouldn't mind seeing GitLab also supporting the renewable energy industry as\nI don't see that listed in the\n[market segmentation page](/handbook/marketing/strategic-marketing/market-segmentation/#oil--gasenergy) yet.\n\n### Do you participate in other open source projects? If yes, what do you like about other communities and what are some of the things that GitLab can learn?\n\nI do, for example in [The Carpentries](https://carpentries.org/teach/), which provides Open Educational\nResources and basic programming training for researchers. I find the GitLab community is\nquite thoughtful about sharing what they learn about successfully pushing the product and\nthe company forward. So I think other open source projects will find lots of advice in GitLab's\nblog and handbook that is worth considering.\n\n### What do you like to do when you're not working?\n\nI enjoy gardening and going cycling, hiking, and canoeing.\n\n### Anything else you want to share with the community?\n\nWherever appropriate, use [`[skip ci]`](https://docs.gitlab.com/ee/ci/pipelines/#skip-a-pipeline)\nmore often in your commit messages and MR titles.\n\n## Interested in learning how you can contribute?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can\nlearn how you can contribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n_Note: This post is part of [a series featuring people who contribute to GitLab](/blog/tags.html#contributors)._\n",[266,682,9],{"slug":1447,"featured":6,"template":685},"katrin-contributor-post","content:en-us:blog:katrin-contributor-post.yml","Katrin Contributor Post","en-us/blog/katrin-contributor-post.yml","en-us/blog/katrin-contributor-post",{"_path":1453,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1454,"content":1460,"config":1466,"_id":1468,"_type":13,"title":1469,"_source":15,"_file":1470,"_stem":1471,"_extension":18},"/en-us/blog/lets-all-search",{"title":1455,"description":1456,"ogTitle":1455,"ogDescription":1456,"noIndex":6,"ogImage":1457,"ogUrl":1458,"ogSiteName":672,"ogType":673,"canonicalUrls":1458,"schema":1459},"Let's all search!","We spoke with you about our search tools. Now we've got some issues we'd like your help on.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679339/Blog/Hero%20Images/AdvancedSearch.png","https://about.gitlab.com/blog/lets-all-search","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Let's all search!\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Will Leidheiser\"}],\n \"datePublished\": \"2022-12-01\",\n }",{"title":1455,"description":1456,"authors":1461,"heroImage":1457,"date":1463,"body":1464,"category":680,"tags":1465},[1462],"Will Leidheiser","2022-12-01","\n\nEarlier this year, our research team set out to learn how users search for GitLab content and to better understand their experience with our [global search](https://docs.gitlab.com/ee/user/search/) and [advanced search](https://docs.gitlab.com/ee/user/search/advanced_search.html) tools. We spoke with 12 GitLab users individually over the course of a four-week span to get their [feedback on our search capabilities](https://gitlab.com/groups/gitlab-org/-/epics/8193). \n\n![Getting feedback from GitLab users](https://about.gitlab.com/images/blogimages/2022-11-21-lets-all-search/Talking_to_GitLab_users.png){: .shadow.medium.center}\nA researcher talking with GitLab users to gather their feedback.\n{: .note.text-center}\n\n## Research insights\n\nOur research identified that the discoverability of our search could be better. Some users had never tried out our search capabilities because they did not know we had a search bar inside of GitLab. The search bar [did not visually stand out](https://gitlab.com/groups/gitlab-org/-/epics/8275) to some GitLab users, so this led them to try other means (e.g., using their web browser URL history or using another external application) to find content. In addition, we learned that even long-time users of the GitLab search bar were [unaware of the kinds of content it could find](https://gitlab.com/groups/gitlab-org/-/epics/8274). As we encouraged users to try out the search tools for our study, they would uncover new information either through exposure or by reading our documentation.\n\nOur research helped the Global Search Product team at GitLab with future roadmap planning. Now, we need the support of our community to make iterative improvements to GitLab search tools. We have identified **two** actionable insight issues that you can contribute to directly to improve the search experience for all GitLab users. \n\n## Community contribution issues\n\n- In order to make the search bar stand out, we're proposing a change to [improve the contrast of the search bar](https://gitlab.com/gitlab-org/gitlab/-/issues/330925) in the GitLab navigation header. This change would greatly support the accessibility of our site and would assist users when looking for a way to search for content.\n\n![Update to improve the contrast of our search bar](https://about.gitlab.com/images/blogimages/2022-11-21-lets-all-search/Focus.png){: .shadow.medium.center}\nA visual mock-up of improved contrast for the GitLab search bar.\n{: .note.text-center} \n\n- Improve the search experience by [providing hints](https://gitlab.com/gitlab-org/gitlab/-/issues/364402) about the kinds of content that the GitLab search bar can find. This change would prompt users with different ideas of what they can do with the search bar, so they can learn about our functionality without having to read through documentation.\n\n![Hints in the search bar](https://about.gitlab.com/images/blogimages/2022-11-21-lets-all-search/Placeholder_Options.png){: .shadow.medium.center}\nSome examples of hints that would be shown in the GitLab search bar.\n{: .note.text-center}\n\n## Let's contribute\n\nWondering where to start? Check out [this blog post](/blog/first-time-open-source-contributor-5-things-to-get-you-started) and [our development guide](/community/contribute/development/) and become an all-star contributor!\n\nNeed guidance or help? Feel free to leave a comment directly on one of the issues linked above, or find support in the \"get help\" section [in our contributing guide](/community/contribute/#getting-help).\n\n**Let's all contribute to GitLab's search!**\n",[9,266,682,704,705],{"slug":1467,"featured":6,"template":685},"lets-all-search","content:en-us:blog:lets-all-search.yml","Lets All Search","en-us/blog/lets-all-search.yml","en-us/blog/lets-all-search",{"_path":1473,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1474,"content":1479,"config":1484,"_id":1486,"_type":13,"title":1487,"_source":15,"_file":1488,"_stem":1489,"_extension":18},"/en-us/blog/marcel-amirault-contributor-post",{"title":1475,"description":1476,"ogTitle":1475,"ogDescription":1476,"noIndex":6,"ogImage":809,"ogUrl":1477,"ogSiteName":672,"ogType":673,"canonicalUrls":1477,"schema":1478},"GitLab Code Contributor: Marcel Amirault","Recent MVP Marcel Amirault shares why he started contributing to GitLab.","https://about.gitlab.com/blog/marcel-amirault-contributor-post","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab Code Contributor: Marcel Amirault\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2019-04-12\",\n }",{"title":1475,"description":1476,"authors":1480,"heroImage":809,"date":1481,"body":1482,"category":680,"tags":1483},[677],"2019-04-12","\n\nI'm excited to continue the [series of GitLab contributor blog posts](/blog/tags.html#contributors)\nwith [Marcel Amirault](https://gitlab.com/Ravlen), [the MVP for the 11.9 release](/community/mvp/).\nLet's get to know more about him!\n\n### Can you tell us where you live and share anything interesting about your area?\n\nI'm originally from Halifax, in eastern Canada, but I now live in [Kagoshima, Japan](https://www.google.com/maps/place/Kagoshima,+Japan/@31.523208,130.2782569,10z/data=!3m1!4b1!4m5!3m4!1s0x353e615200e3c53d:0x9adcfdad5d5c5885!8m2!3d31.5968539!4d130.5571392) (and yes, I have seen wild tanuki!).\nKagoshima is famous for being right next to one of the world's most active volcanos, Sakurajima,\nwhich regularly dusts the city in ash. You have to keep an eye on the wind before you decide\nto put out your laundry, or else you'll have some ashy-grey clothes pretty quickly.\nIt's also known for inspiring some famous movies. Hometown hero Saigō Takamori and the\nlocal Satsuma clan were the inspirations for \"The Last Samurai,\" and Yakushima Island was\nthe inspiration for the forest in \"Princess Mononoke.\"\n\n![Picture of Sakurajima](https://about.gitlab.com/images/blogimages/Marcel-blogpost/kagoshima.png){: .shadow.small.center}\n*\u003Ccenter>\u003Csmall>Sakurajima in the distance\u003C/small>\u003C/center>*\n\n### Can you tell us what you do professionally?\n\nOriginally, I worked in IT Support, peaking as a Network Technician at a telecom company\nin eastern Canada. I loved the job, but I wanted to live abroad for a while before settling into my career.\nI decided to teach English in Japan \"for six months,\" but fell in love with the country and have\nbeen here ever since. I currently teach English as a second language to Japanese students, and\nhave taught all ages and types of students over the years. I write, proofread, and teach curricula\nfor various types of students, ranging from people preparing for their first trip abroad, to seminars\nin hospitals for medical professionals. From time to time I proofread documents brought to me,\nsuch as applications to international programs, or scientific papers being prepared for submission for peer review.\n\n![Marcel in the classroom](https://about.gitlab.com/images/blogimages/Marcel-blogpost/marcel-teaching.jpg){: .shadow.small.center}\n\n### When did you first contribute to GitLab and why did you decide to contribute?\n\nAbout a year ago, I started a Rails course to try to get back into the IT world, and needed to\nchoose a place to store my Git repo. A friend suggested GitLab, and I dove right in.\nWhile reading the documentation, I sometimes found small mistakes that the English teacher\nin me couldn't ignore, so I started submitting MRs for small things like typos or obvious grammar mistakes.\nIn fact, [my first MR](https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/11848) was to correct grammar.\nFrom there, the MRs got a little bigger, and a little more involved, and it's something I enjoy doing when things are slow at work.\n\n### What was the most difficult part of contributing for you in the beginning?\n\nThere was no significant hurdle to starting, because contributing to documentation was not\nintimidating at all, and I never had to worry about complicated reviews.\nWhen I first submitted a small change to the language in a section of the UI though, I suddenly\nhad a lot of reviews and suggestions, and started to realize how a small change could have a large impact.\nUnderstanding the impact that one person could have on a major project was something I had to learn.\nThankfully, a lot of GitLab team-members offered help and explained things for me, which I really appreciated.\n\n### Which areas of GitLab have you contributed to most and how do you find issues that you want to work on?\n\nUpdating technical documentation was a natural fit for me. I enjoy learning, so I frequently\nread the GitLab documentation, but my \"English teacher eyes\" can't ignore language that can be improved.\nI take advantage of free time at work, and I'm fortunate to have free access to computers and\na flexible boss (as long as my lesson quality is maintained). As a result, I'm often able to fill\nthe gaps between lessons by working on documentation issues. When I'm struggling to stay\nawake because my kids kept me up at night and I have a gap in my schedule, working on an\ninteresting bit of documentation wakes me up as much as a strong cup of coffee!\nI usually find documentation that can be improved on my own as I read through, but I\nsometimes search for [`Accepting Merge Requests` issues for Documentation](https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Accepting%20merge%20requests&label_name[]=Documentation) if I need a new project to work on. Recently I have given myself \"challenges,\"\nlike \"Find ALL examples of a certain grammar mistake project wide, and fix them\" or\n\"Find ALL examples where CE and EE documentation have diverged accidentally, and realign them when possible.\"\n\n### What do you enjoy doing when you're not working?\n\nI like doing home improvements when I can, and really like outdoor carpentry like putting up\nfences or wooden decks. I'm a big fan of hiking and camping, but it has been hard to get out\nto camping places in the past few years as my kids are still young. We are hoping to bring them\non their second ever camping trip this spring/summer. Finally, my friends and I try to get together\nabout once every month or two for poker or board gaming. Some of my favorite games are\nSettlers of Catan, Carcassonne, Puerto Rico, Pandemic, San Juan, and Guillotine.\n\n![Marcel and his children](https://about.gitlab.com/images/blogimages/Marcel-blogpost/marcel-family.png){: .shadow.small.center}\n\n### What advice do you have for others who may be interested in contributing to GitLab?\n\nDon't be shy! If you are worried about your contribution, feel free to make your MR a [draft](https://docs.gitlab.com/ee/user/project/merge_requests/drafts.html)\n(document last updated by me! 😉), and ask for help. Everyone is super friendly and always willing to give advice!\n\n### Interested in learning how you can contribute?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn\nhow you can contribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n_Note: This post is part of [a series featuring people who contribute to GitLab](/blog/tags.html#contributors)._\n",[266,817,682,9],{"slug":1485,"featured":6,"template":685},"marcel-amirault-contributor-post","content:en-us:blog:marcel-amirault-contributor-post.yml","Marcel Amirault Contributor Post","en-us/blog/marcel-amirault-contributor-post.yml","en-us/blog/marcel-amirault-contributor-post",{"_path":1491,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1492,"content":1498,"config":1504,"_id":1506,"_type":13,"title":1507,"_source":15,"_file":1508,"_stem":1509,"_extension":18},"/en-us/blog/open-sourcing-the-gitter-mobile-apps",{"title":1493,"description":1494,"ogTitle":1493,"ogDescription":1494,"noIndex":6,"ogImage":1495,"ogUrl":1496,"ogSiteName":672,"ogType":673,"canonicalUrls":1496,"schema":1497},"Open-sourcing the Gitter mobile apps","Learn how we open sourced the Android and iOS Gitter apps.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666717/Blog/Hero%20Images/cover-image.jpg","https://about.gitlab.com/blog/open-sourcing-the-gitter-mobile-apps","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Open-sourcing the Gitter mobile apps\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Eric Eastwood\"}],\n \"datePublished\": \"2019-11-22\",\n }",{"title":1493,"description":1494,"authors":1499,"heroImage":1495,"date":1501,"body":1502,"category":748,"tags":1503},[1500],"Eric Eastwood","2019-11-22","\nBefore we acquired Gitter most every part of Gitter was private/closed-source. The main [webapp](https://gitlab.com/gitlab-org/gitter/webapp) was open-sourced in June 2017 and got both mobile [Android](https://gitlab.com/gitlab-org/gitter/gitter-android-app)/[iOS](https://gitlab.com/gitlab-org/gitter/gitter-ios-app) apps open sourced in September 2018. If you would like to come help out, feel free to send us a merge request! This blog post will go over some the technical details of making the projects available for anyone to contribute.\n\nHere is the basic overview:\n\n1. Find secrets in the current state of the project (don't worry about the commit history) and move to some config that isn't tracked in the repo.\n1. Find/remove secrets throughout the whole repo commit history.\n1. Make the project public 🎉\n1. Caveats:\n - Because we are rewriting the git history, I don't know of a way to keep merge requests/pull requests because the MRs reference the old commit hashes.\n\nQuick navigation:\n\n- [Jump to open sourcing Android](#android)\n- [Jump to open sourcing iOS](#ios)\n\n## Android\n\nIf you want to check out the full project and final result, you can check out the [project on GitLab](https://gitlab.com/gitlab-org/gitter/gitter-android-app) ([open-sourced 2018-8-8](https://twitter.com/gitchat/status/1027293167471812611)).\n\nTo start out, we used the [GitHub to GitLab project import](https://docs.gitlab.com/ee/user/project/import/github.html) to move the private GitHub project over to GitLab. We named it `gitter-android-app2` so that later on we could create the actual clean public project without any of the orphaned git references that may potentially leak.\n\n### Finding secrets\n\n[`truffleHog`](https://github.com/dxa4481/truffleHog) will search for high entropy strings (like tokens/passwords) through the entire git repo history. It's also useful to find all the potential areas where secrets may still exist in the current state of the project. Some sticky points we encountered while using include:\n\n- \"I wish we could just search the current state of the project instead of all git history (the `--max_depth=2` argument will just make it search the diff of the latest commit)\" [dxa4481/truffleHog#92](https://github.com/dxa4481/truffleHog/issues/92).\n- \"The output will show the entire diff for the triggered commit which is a bit burdensome to see exactly what is wrong. The JSON output `--json` is sometimes easier to understand\" [https://github.com/dxa4481/truffleHog/issues/58](https://github.com/dxa4481/truffleHog/issues/58) or [dxa4481/truffleHog#102](https://github.com/dxa4481/truffleHog/issues/102).\n\n### Moving secrets to untracked config\n\nOnce we figure out where all of the secrets are we need a config/variable solution that isn't tracked by git but still lets them be available when building. We also wanted the solution to work in GitLab CI for some sanity builds/testing. There are lots of good articles on this topic:\n\n- [Remove private signing information from your project](https://developer.android.com/studio/build/gradle-tips#remove-private-signing-information-from-your-project)\n- [Keeping Your Android Project’s Secrets Secret](https://medium.com/@geocohn/keeping-your-android-projects-secrets-secret-393b8855765d)\n- [Hiding Secrets in Android Apps](https://rammic.github.io/2015/07/28/hiding-secrets-in-android-apps/)\n- [Keeping secrets in an Android Application](https://joshmcarthur.com/2014/02/16/keeping-secrets-in-an-android-application.html)\n- [Android: Loading API Keys and other secrets from properties file using gradle](https://gist.github.com/curioustechizen/9f7d745f9f5f51355bd6)\n- [How can I keep API keys out of source control?](https://arstechnica.com/information-technology/2013/12/how-can-i-keep-api-keys-out-of-source-control/)\n\nOur solution is completely based on the information in these articles. We chose to go the route of defining things in a `secrets.properties` file which can easily be read in the Gradle build script which handles the build even when using Android Studio. If the `secrets.properties` file doesn't exist (like in CI), it will try to read the secrets from [environment variables which can easily be supplied in the project settings](https://docs.gitlab.com/ee/ci/variables/).\n\n`secerts.properties`\n\n```properties\n# Visit https://developer.gitter.im/apps (sign in) and create a new app\n# Name: my-gitter-android-app (can be anything)\n# Redirect URL: https://gitter.im/login/oauth/callback\noauth_client_id=\"...\"\noauth_client_secret=\"...\"\noauth_redirect_uri=\"https://gitter.im/login/oauth/callback\"\n```\n\n`build.gradle`\n\n```gradle\napply plugin: 'com.android.application'\n\n// Try reading secrets from file\ndef secretsPropertiesFile = rootProject.file(\"secrets.properties\")\ndef secretProperties = new Properties()\nif (secretsPropertiesFile.exists()) {\n secretProperties.load(new FileInputStream(secretsPropertiesFile))\n}\n// Otherwise read from environment variables, this happens in CI\nelse {\n secretProperties.setProperty(\"oauth_client_id\", \"\\\"${System.getenv('oauth_client_id')}\\\"\")\n secretProperties.setProperty(\"oauth_client_secret\", \"\\\"${System.getenv('oauth_client_secret')}\\\"\")\n secretProperties.setProperty(\"oauth_redirect_uri\", \"\\\"${System.getenv('oauth_redirect_uri')}\\\"\")\n}\n\nandroid {\n ...\n\n defaultConfig {\n ...\n\n buildConfigField(\"String\", \"oauth_client_id\", \"${secretProperties['oauth_client_id']}\")\n buildConfigField(\"String\", \"oauth_client_secret\", \"${secretProperties['oauth_client_secret']}\")\n buildConfigField(\"String\", \"oauth_redirect_uri\", \"${secretProperties['oauth_redirect_uri']}\")\n }\n ...\n}\n```\n\nUse the config variables in the Java app:\n\n```java\nimport im.gitter.gitter.BuildConfig;\n\nBuildConfig.oauth_client_id;\nBuildConfig.oauth_client_secret;\nBuildConfig.oauth_redirect_uri;\n```\n\n#### Removing compiled assets\n\nWe use a `WebView` to display the HTML markdown messages in the chat room. This view uses assets built from the main [`webapp` project](https://gitlab.com/gitlab-org/gitter/webapp). Because these assets had some inlined production [`webapp`](https://gitlab.com/gitlab-org/gitter/webapp) secrets that whole directory needed to be removed.\n\nInitially, we opted to have the developer build these assets with their own secrets and symlink the build output directory. The [community made this even simpler](https://gitlab.com/gitlab-org/gitter/gitter-android-app/merge_requests/113), so now there is just a Gradle task to run which fetches the latest build we have available from the `webapp` GitLab CI.\n\n### Removing secrets from the repo history\n\nFrom your `truffleHog` results earlier, you should know where secrets were stored throughout the history. We can use [BFG Repo-Cleaner](https://rtyley.github.io/bfg-repo-cleaner/) to remove and rewrite the repo history quickly.\n\nWhen using BFG, I wanted just to rewrite all of the sensitive values in `app/src/main/res/values/settings.xml` instead of completely removing them, but rewriting isn't an option with BFG so I went ahead with deleting it and recreated it in a commit afterwards. 🤷\n\nFor the Android app, here are the BFG commands I used,\n\n- Remove `app/src/main/assets/www/`\n - `java -jar \"bfg.jar\" --delete-folders www`\n- Remove `app/src/main/res/values/settings.xml`\n - `java -jar \"bfg.jar\" --delete-files settings.xml`\n- Remove sensitive strings where we can't just remove the whole file (collected from `truffleHog` results)\n - `java -jar \"bfg.jar\" --replace-text \"gitter-android-bad-words.txt\"`\n\nAfter you think you removed all the secrets, it's best to run `truffleHog` again just to make sure no secrets are leftover. 😉\n\n### Make it public\n\nNow it's time to update your `readme` with some setup instruction so the community knows how to contribute.\n\nThis is the scary part 😅. Go to **Project settings** > **General** > **Permissions** > set **Project visibility** as **Public**. You can [read more about project access here](https://docs.gitlab.com/ee/public_access/public_access.html).\n\nCurious about how to setup builds in GitLab CI? [Learn more from this blog post](/blog/setting-up-gitlab-ci-for-android-projects/), which was what we used to set it up for our projects.\n\nYou can even learn how we [automated the release process so we can publish straight to the Google Play Store from GitLab CI via fastlane 🚀](/blog/android-publishing-with-gitlab-and-fastlane/).\n\n## iOS\n\nIf you want to see the full project and final result, you can check out the [project on GitLab](https://gitlab.com/gitlab-org/gitter/gitter-ios-app) ([open-sourced 2018-9-18](https://twitter.com/gitchat/status/1041795909103898625)).\n\nThe same concepts apply from the Android section. We create a separate private project, `gitter-ios-app2`, where we can work and later on, we can create the actual clean public project(`gitter-ios-app`) without any of the orphaned git references that could leak.\n\n### Finding secrets\n\n`truffleHog` didn't work well in the iOS project because there was a bunch of generated XCode files that had file hashes (high entropy strings which truffleHog looks for) – which meant every commit was listed. 🤦‍ Instead of trying to find something to filter the results down or get another tool, I decided just search manually. Here is the list of things we looked for:\n\n- `token`\n- `secret`\n- `key`\n- `cert`\n- `api`\n- `pw`\n- `password`\n\nI used this directory filter when `Ctrl + f` those strings above to avoid finding things outside of the repo itself (copy-paste for Atom editor): `!Common/,!Libraries,!Gitter/www,!Pods/,!xctool`\n\n### Moving secrets to untracked config\n\nThe iOS app uses a few git sub-modules which we also had to check for secrets before making them public. It turned out only one of the sub-modules – [`troupeobjccommon`](https://gitlab.com/gitlab-org/gitter/troupeobjccommon) – had secrets of it's own so I ran through the same secret removal process.\n\nWe had the same OAuth secrets in the main part of the iOS app, but since `troupeobjccommon` was also trying to handle OAuth secret settings, we opted for putting the new logic in `troupeobjccommon` to avoid having to refactor whatever other downstream code that uses the same submodule (like the macOS desktop app).\n\nHere are some articles around handling secrets in an iOS project,\n\n- [Secret variables in Xcode AND your CI for fun and profit 💌](https://medium.com/flawless-app-stories/secret-variables-in-xcode-and-your-ci-for-fun-and-profit-d387a50475d7)\n- [Secrets Management in iOS Applications](https://medium.com/@jules2689/secrets-management-in-ios-applications-52795c254ec1)\n\nSince iOS apps can only be built on macOS and we don't have any macOS GitLab CI runners, our solution doesn't have to be CI compatible. You can track [this issue for shared macOS GitLab CI runners](https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/5720).\n\n`Gitter/GitterSecrets-Dev.plist`\n\n```xml\n\u003C?xml version=\"1.0\" encoding=\"UTF-8\"?>\n\u003C!DOCTYPE plist PUBLIC \"-//Apple//DTD PLIST 1.0//EN\" \"http://www.apple.com/DTDs/PropertyList-1.0.dtd\">\n\u003Cplist version=\"1.0\">\n\u003Cdict>\n \u003C!--\n Visit https://developer.gitter.im/apps (sign in) and create a new app\n Name: my-gitter-ios-app (can be anything)\n Redirect URL: https://gitter.im/login/oauth/callback\n -->\n \u003Ckey>OAuthClientId\u003C/key>\n \u003Cstring>\u003C/string>\n \u003Ckey>OAuthClientSecret\u003C/key>\n \u003Cstring>\u003C/string>\n \u003Ckey>OAuthCallback\u003C/key>\n \u003Cstring>https://gitter.im/login/oauth/callback\u003C/string>\n\u003C/dict>\n\u003C/plist>\n```\n\n[`troupeobjccommon`](https://gitlab.com/gitlab-org/gitter/troupeobjccommon) is in Objective-C\n\n`TRAppSettings.h`\n\n```h\n#import \u003CFoundation/Foundation.h>\n\n@interface TRAppSettings : NSObject\n\n+ (TRAppSettings *) sharedInstance;\n\n- (NSString *) clientID;\n\n- (NSString *) clientSecret;\n\n- (NSString *) oauthScope;\n\n@end\n```\n\n`TRAppSettings.m`\n\n```objc\n@interface TRAppSettings ()\n\n@property (strong, nonatomic) NSUserDefaults *secrets;\n\n@end\n\nstatic TRAppSettings *sharedAppSettingsSingleton;\n\n@implementation TRAppSettings {\n int firstRunPostUpdate;\n}\n\n+ (void)initialize\n{\n static BOOL initialized = NO;\n if(!initialized)\n {\n initialized = YES;\n sharedAppSettingsSingleton = [[TRAppSettings alloc] init];\n }\n\n NSLog(@\"Pulling secrets from SECRETS_PLIST = %@.plist\", SECRETS_PLIST);\n}\n\n+ (TRAppSettings *) sharedInstance\n{\n return sharedAppSettingsSingleton;\n}\n\n- (id)init {\n NSString *troupeSecretsPath = [[NSBundle mainBundle] pathForResource:\"GitterSecrets-Dev\" ofType:@\"plist\"];\n if(troupeSecretsPath == nil) {\n NSString *failureReason = [NSString stringWithFormat:@\"Gitter secrets file not found in bundle: %@.plist. You probably need to add it to the `Gitter/Supporting Files` in Xcode navigator\", SECRETS_PLIST];\n NSException* exception = [NSException\n exceptionWithName:@\"FileNotFoundException\"\n reason:failureReason\n userInfo:nil];\n\n NSLog(@\"%@\", failureReason);\n\n [exception raise];\n }\n NSDictionary *troupeSecrets = [NSDictionary dictionaryWithContentsOfFile:troupeSecretsPath];\n\n self.secrets = [NSUserDefaults standardUserDefaults];\n [self.secrets registerDefaults:troupeSecrets];\n}\n\n- (NSString *) clientID {\n return [self.secrets stringForKey:@\"OAuthClientId\"];\n}\n\n- (NSString *) clientSecret {\n return [self.secrets stringForKey:@\"OAuthClientSecret\"];\n}\n\n- (NSString *)oauthScope {\n return [self.secrets stringForKey:@\"OAuthCallback\"];\n}\n```\n\nUsage in the Swift app:\n\n```swift\nprivate let appSettings = TRAppSettings.sharedInstance()\n\nappSettings!.clientID()\nappSettings!.clientSecret()\nappSettings!.oauthScope()\n```\n\n### Adding in GitLab CI\n\nIf you're interested in setting up automated builds and publish releases to the Apple App Store from GitLab CI, you can learn how [blog post about using fastlane](/blog/ios-publishing-with-gitlab-and-fastlane/).\n\n### Removing secrets from the repo history\n\nWe didn't have a complete picture of what to remove because `truffleHog` didn't work well, so we didn't use BFG Repo-Cleaner. To remove secrets from the git repo history, we just squashed all of the history into a single commit.\n\n## Life after open sourcing apps\n\nWe have some [thoughts of deprecating the Android/iOS apps](https://gitlab.com/gitlab-org/gitter/webapp/issues/2281) but the community has been great to keep the apps alive so far. We released a couple versions of each app including [dark theme](https://gitlab.com/gitlab-org/gitter/gitter-android-app/merge_requests/2) and [GitLab sign-in](https://gitlab.com/gitlab-org/gitter/gitter-android-app/merge_requests/112) for Android and a bunch of technical debt and fixes for iOS, including removing the deprecated [`SlackTextViewController`](https://gitlab.com/gitlab-org/gitter/gitter-ios-app/merge_requests/8) (and we are intensely working on incorporating the new [`SlackWysiwygInputController`](https://goo.gl/7NDM3x) 😜).\n\nThe [Android](https://gitlab.com/gitlab-org/gitter/gitter-android-app)/[iOS](https://gitlab.com/gitlab-org/gitter/gitter-ios-app) apps could benefit from a lot of polish and fixes, so if you see anything particularly annoying, we would love to review and merge your updates!\n\nCover image by [Nate Johnston](https://unsplash.com/@natejohnston) on [Unsplash](https://unsplash.com/photos/DkCydKeaLV8).\n{: .note}\n",[682,817,9,108],{"slug":1505,"featured":6,"template":685},"open-sourcing-the-gitter-mobile-apps","content:en-us:blog:open-sourcing-the-gitter-mobile-apps.yml","Open Sourcing The Gitter Mobile Apps","en-us/blog/open-sourcing-the-gitter-mobile-apps.yml","en-us/blog/open-sourcing-the-gitter-mobile-apps",{"_path":1511,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1512,"content":1518,"config":1525,"_id":1527,"_type":13,"title":1528,"_source":15,"_file":1529,"_stem":1530,"_extension":18},"/en-us/blog/personal-profile",{"title":1513,"description":1514,"ogTitle":1513,"ogDescription":1514,"noIndex":6,"ogImage":1515,"ogUrl":1516,"ogSiteName":672,"ogType":673,"canonicalUrls":1516,"schema":1517},"GitLab user profiles have just become more personal","Find out the more about our latest additions to GitLab user profiles. You control the data that is displayed","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682144/Blog/Hero%20Images/ben-sweet-2LowviVHZ-E-unsplash.jpg","https://about.gitlab.com/blog/personal-profile","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab user profiles have just become more personal\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Orit Golowinski\"}],\n \"datePublished\": \"2021-09-30\",\n }",{"title":1513,"description":1514,"authors":1519,"heroImage":1515,"date":1521,"body":1522,"category":726,"tags":1523},[1520],"Orit Golowinski","2021-09-30","\n\nThe GitLab [user profile](https://docs.gitlab.com/ee/user/profile/) contains information about you and your GitLab activity. You can select what information to display.\n\nWe recently added a few new settings to make you user profile more personal:\n\n- [User pronouns](https://gitlab.com/gitlab-org/gitlab/-/issues/333042)\n- [User pronunciation guides](https://gitlab.com/gitlab-org/gitlab/-/issues/25742)\n- [User local times](https://gitlab.com/gitlab-org/gitlab/-/issues/335459)\n\n## User pronouns\n\nYou can now set pronouns to your GitLab user profile. The pronoun appears:\n\n- Next to your user name in your public profile.\n- On the snapshot view of your user profile when someone hovers over your name on an issue or\n merge request.\n\nBesides being more inclusive, GitLab wants to help you use the correct pronouns when replying\nto comments to respect people's identity. You can:\n\n- Decide whether or not to add pronouns to your profile.\n- Self-identify and enter whatever pronouns you want, without having to select from a pre-defined list.\n\n[Read more](https://docs.gitlab.com/ee/user/profile/#add-your-gender-pronouns) about adding\npronouns to your profile.\n\n## User pronunciation\n\nYou can now add a pronunciation guide to your user profile. In distributed teams where team\nmembers are from different countries, it can be difficult to determine how to say someone's\nname correctly. You can now help people know how to pronounce your name.\n\n[Read more](https://docs.gitlab.com/ee/user/profile/#add-your-name-pronunciation) about adding a\npronunciation guide to your profile.\n\n## User local time\n\nYour local time is now displayed on your profile. Previously, you could set your time\nzone but your local time was not visible throughout GitLab. This improvement helps\nothers know when you are likely to be available.\n\n[Read more](https://docs.gitlab.com/ee/user/profile/#set-your-time-zone) about adding a\nlocal time zone to your profile.\n\n## Additional settings for user profiles\n\nIn the upcoming milestone, we are planning to [add your timezone to the snapshot view of the GitLab user profile](https://gitlab.com/gitlab-org/gitlab/-/issues/337935).\n\nIn GitLab, [everyone can contribute](/community/contribute/). If you would like to see even\nmore additions to user profiles, you can:\n\n- Open an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issue%5Bmilestone_id%5D=#) with your request.\n- Upvote an existing issue. \n- Even [code it yourself](/community/contribute/development/)!\n\nCover image by [Ben Sweet](https://unsplash.com/@benjaminsweet?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](lhttps://unsplash.com/s/photos/profile?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyTextink)\n{: .note}\n\n",[1524,705,9],"UI",{"slug":1526,"featured":6,"template":685},"personal-profile","content:en-us:blog:personal-profile.yml","Personal Profile","en-us/blog/personal-profile.yml","en-us/blog/personal-profile",{"_path":1532,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1533,"content":1539,"config":1547,"_id":1549,"_type":13,"title":1550,"_source":15,"_file":1551,"_stem":1552,"_extension":18},"/en-us/blog/public-project-minute-limits",{"title":1534,"description":1535,"ogTitle":1534,"ogDescription":1535,"noIndex":6,"ogImage":1536,"ogUrl":1537,"ogSiteName":672,"ogType":673,"canonicalUrls":1537,"schema":1538},"Changes to GitLab.com public project CI/CD minute quotas","How cryptomining has shaped our pipeline consumption visibility approach and our forward-looking changes.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666275/Blog/Hero%20Images/ci_minutes.jpg","https://about.gitlab.com/blog/public-project-minute-limits","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Changes to GitLab.com public project CI/CD minute quotas\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Jackie Porter\"}],\n \"datePublished\": \"2021-11-11\",\n }",{"title":1534,"description":1535,"authors":1540,"heroImage":1536,"date":1542,"body":1543,"category":726,"tags":1544},[1541],"Jackie Porter","2021-11-11","\nIn the upcoming milestones, we will be extending CI/CD minute usage quotas to GitLab.com public projects not part of GitLab [open source programs](/handbook/marketing/developer-relations/community-programs/opensource-program/). \n\nIn the first half of 2021, GitLab.com and other CI/CD providers faced a large uptick in the abuse of free pipeline minutes to mine for cryptocurrencies. To discourage and reduce abuse, we [annouced](/blog/prevent-crypto-mining-abuse/) several changes to help ensure service continued to be reliable for our customers and users. The most recent change was made on 2021-07-17 to \"include public projects in pipeline minutes quota for free users.\" \n\n### Why add a usage quota to public projects?\n\nPreviously, GitLab provided public projects on GitLab.com with a very high number of shared runner minutes to facilitate community contributions to open source. This means cryptominers are able to use GitLab.com shared runners to process large quantities of pipelines and consume an inordinate amount of minutes. These behaviors negatively impact the performance and the availability of GitLab.com shared runners. By adding a quota to the pipelines, the abusers are no longer able to process and consume minutes because there is a limit in place. \n\n[CI/CD minute quotas](https://docs.gitlab.com/ee/subscriptions/gitlab_com/index.html#ci-pipeline-minutes) enable CI/CD minute accumulation, which also gives you transparency into pipeline minute billing. Accumulation of CI/CD minutes in GitLab empowers you to make informed decisions about how to optimize your pipelines and CI/CD usage. \n\n### How does this usage quota impact you?\n\n* **Self-managed users** are not impacted by these changes as CI/CD minutes are only relevant for GitLab.com users. \n\n* **Members of GitLab's [open source program](/handbook/marketing/developer-relations/community-programs/opensource-program/)** [are not subject to the new quotas](https://gitlab.com/groups/gitlab-org/-/epics/6895) for public project CI/CD minutes. As noted in the [program description](https://about.gitlab.com/solutions/open-source/), `Features of [GitLab Ultimate](/pricing/ultimate/), including 50,000 CI/CD minutes, are free to qualifying open source projects through the GitLab for Open Source Program.`, calculated at a [program-specific cost factor](https://docs.gitlab.com/ee/ci/pipelines/cicd_minutes.html#cost-factor).\n\n* **All other GitLab.com public project users** (who account for 5% of our usage) will receive a notification email when they reach their CI/CD quota. Namespace owners will then have the option of upgrading the account to a higher [plan](https://about.gitlab.com/pricing/) or [purchasing additional CI/CD minutes](https://docs.gitlab.com/ee/subscriptions/gitlab_com/index.html#purchase-additional-ci-minutes). Self-managed runners can still be used even when a project reaches quota limits. \n\nFor more information on CI/CD minutes and billing, please refer to the [customer FAQ](/pricing/faq-compute-credit/).\n\n### What's Next?\n\nTo further protect GitLab.com from cryptomining abuse, in the next few months you'll notice some changes to GitLab.com [CI/CD minute quotas](https://docs.gitlab.com/ee/subscriptions/gitlab_com/index.html#ci-pipeline-minutes) and the types of projects that accumulate pipeline minutes. \n\nTo address your questions and feedback on these changes going forward, we have created a space in the [GitLab Community Forum](https://forum.gitlab.com/t/pipeline-minute-quotas-on-gitlab-com/58976), which is actively monitored by GitLab team members and product managers involved with this change.\n",[1545,1546,9],"CI","CD",{"slug":1548,"featured":6,"template":685},"public-project-minute-limits","content:en-us:blog:public-project-minute-limits.yml","Public Project Minute Limits","en-us/blog/public-project-minute-limits.yml","en-us/blog/public-project-minute-limits",{"_path":1554,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1555,"content":1561,"config":1567,"_id":1569,"_type":13,"title":1570,"_source":15,"_file":1571,"_stem":1572,"_extension":18},"/en-us/blog/pursuing-faster-time-to-merge-for-wider-community-contributions",{"title":1556,"description":1557,"ogTitle":1556,"ogDescription":1557,"noIndex":6,"ogImage":1558,"ogUrl":1559,"ogSiteName":672,"ogType":673,"canonicalUrls":1559,"schema":1560},"Pursuing faster time-to-merge for wider community contributions","How introducing more explicit contribution stages lowered the time it takes to merge a community contribution.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663397/Blog/Hero%20Images/logoforblogpost.jpg","https://about.gitlab.com/blog/pursuing-faster-time-to-merge-for-wider-community-contributions","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Pursuing faster time-to-merge for wider community contributions\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Nick Veenhof\"}],\n \"datePublished\": \"2022-09-13\",\n }",{"title":1556,"description":1557,"authors":1562,"heroImage":1558,"date":1563,"body":1564,"category":680,"tags":1565},[1257],"2022-09-13","\n\nOne of GitLab's core strategies is to [build on our open core\nstrength](/company/strategy/#2-build-on-our-open-core-strength). We believe that building a\nstrong community of contributors is key to the long-term success of GitLab. We believe in a [dual-flywheel\nstrategy](/company/strategy/#dual-flywheels) that focuses on both product contributions from\nwithin our GitLab engineering team and community contributions. \n\nOur goal is to grow to 1000 contributors per month. The saying is that \"All roads lead to Rome,\" but of course not all of those roads are the most efficient ways to get there. To succeed, contributing to GitLab must be a rewarding and incentivizing experience that\nmotivates contributors to come back. One of the strategic choices we made in the [contributor\nsuccess](https://about.gitlab.com/handbook/marketing/developer-relations/contributor-success/) team is the route of being as\nresponsive and clear as we can about the next steps, using processes and automation. \n\n## Problem statement\n\nSo where do we start? On average GitLab has over [550 open merge\nrequests](https://gitlab.com/groups/gitlab-org/-/merge_requests?scope=all&state=opened&label_name[]=Community%20contribution).\nWe wanted to focus on the _ready enough_ problem. When is an MR ready for review? And when is an MR still in development? In\nboth cases collaboration is required, but having a formal handoff — meaning this contribution is ready for a review — helps in\nunderstanding who is blocked from moving forward. Before a merge request can find its way into GitLab, it needs to get a\nreview from at least one maintainer.\n\nHow do we know when to ask specific maintainers of our product areas to put their focus on reviewing these merge requests? When is a merge request _ready enough_ for a thorough review? What does _ready enough_ even mean?\n\nSome OSS communities use crowdsourced reviews for contributions to make sure the project maintainers don’t need to take on everything by themselves. For example, in the Drupal community there is the concept of [Reviewed and Tested by the Community](https://www.drupal.org/community/contributor-guide/task/triage-the-drupal-core-rtbc-queue). At GitLab we have MR coaches and community help to make sure everything is as ready as can be before involving the maintainers.\n\nThe GitLab bot and our MR coaches try to assist the wider community contributors on their way. We also had a ping-pong label that tried to signify if a community contributor had reacted and it was ‘ping ponged 🏓’ back to the GitLab team members. This pingpong label didn’t take the context into account. It was a great iterative and [boring solution](https://handbook.gitlab.com/handbook/values/#boring-solutions) to know who was up next (the author or the reviewer). But it had a lot of false-positives and caused confusion to both the maintainers and the community contributors.\n\nSo where do we go from here? How do we get a better grasp on this _ready enough_ problem? Let’s start by asking for help from our recommended reading list, [High-Output Management](/handbook/leadership/high-output-management/). Author Andrew S. Grove states: “A very important way to increase productivity is to arrange the work flow inside our black box so that it will be characterized by high output per activity, which is to say high-leverage activities.”\n\n## Introducing workflow labels\n\nFor a while, GitLab team members were using workflow labels to signify the state of a merge request. It wasn’t always used across all teams, but they were available. More specifically we’re looking at the following labels:\n\n- `workflow::ready for review`\n- `workflow::in dev`\n- `workflow::blocked`\n\nEach wider community contributor is now [able to change these labels themselves](https://docs.gitlab.com/ee/development/contributing/#contribution-flow). By using `@gitlab-bot ready`, it sets the state to `workflow::ready for review` and assigns a reviewer. The reviewer is able to set it back to `workflow::in dev` if there are still items to be addressed. Other wider community members can also leave comments or suggestions for improvement, and then [set the label](https://about.gitlab.com/handbook/engineering/quality/triage-operations/#reactive-label-command) back to `workflow::in dev`, or set other labels to help triage these merge requests.\n\n## What have we learned so far?\n\nWe started using this system over two months ago. We now know that around 20% of MRs on average are in a \"ready for review\"\nstate. Those contributors are blocked and waiting for an answer to either continue to improve the merge request or get\nit merged if there are no more comments left. We also noticed that some merge requests were not getting a lot of\nattention. We did an async retrospective and feedback session with the GitLab team members and the wider community in order to find an answer on how we can\n[improve the time it takes before a review is made](https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/13718) for\ncontributions that were ready for a review. We’re still processing that feedback, but are looking to try some of these\nsuggestions, learn from them, and iterate. Even though GitLab cannot promise timely reviews, we can certainly try to\nbuild in mechanisms, and understand where we see limits, to navigate towards better processes. When we started out, we\nhad a median time of 17 days that an MR was in the ready for review state. Today that median time has been reduced to five days!\n\nThe median Open Community MR Age (OCMA) has also dropped from 139 days in April to 78 days in August. Maybe it is a\ncoincidence that we reached an all-time high of 126 contributors in August? Either way, all of the steps allowed our amazing wider\ncommunity contributors to get 440 merge requests merged in a single month! I’m certain this change contributed, among other\nchanges and initiatives, to that record. We will keep learning as we progress. It certainly allowed us to take a peek\ninto our little black box.\n\n## What’s next?\n\nNext up is to continue our iterations and move further towards automation. Right now it is up to the reviewer to set the\nstatus back to `workflow::in dev` whenever there is something left to address. We notice that this is not always changed\nback when it’s actually needed. It is also causing false-positives with reviewers and our wider community members.\nThe Contributor Success team is looking into how this can be automated. If you’d like to help, the automation happens in\nthe [Triage Ops project](https://gitlab.com/gitlab-org/quality/triage-ops/) and the Contributor Success [issue\nqueue](https://gitlab.com/gitlab-com/quality/contributor-success/-/issues) is open for everyone!\n\nWe’re also looking into a new program called [Leading\nOrganizations](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/110700) which rewards recurring\ncontributors, and their organizations, with a review time objective of four business days. This would lead us to even\nshorter review cycle times and give those organizations that contribute to GitLab a competitive advantage to stay\nleaders in their domain. The faster we can innovate together, the faster our dual flywheel will spin. Together we go to\ninfinity and beyond. Together we can build software fast.\n\n\n\n\n",[1566,9,682],"code review",{"slug":1568,"featured":6,"template":685},"pursuing-faster-time-to-merge-for-wider-community-contributions","content:en-us:blog:pursuing-faster-time-to-merge-for-wider-community-contributions.yml","Pursuing Faster Time To Merge For Wider Community Contributions","en-us/blog/pursuing-faster-time-to-merge-for-wider-community-contributions.yml","en-us/blog/pursuing-faster-time-to-merge-for-wider-community-contributions",{"_path":1574,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1575,"content":1581,"config":1588,"_id":1590,"_type":13,"title":1591,"_source":15,"_file":1592,"_stem":1593,"_extension":18},"/en-us/blog/remote-development-beta",{"title":1576,"description":1577,"ogTitle":1576,"ogDescription":1577,"noIndex":6,"ogImage":1578,"ogUrl":1579,"ogSiteName":672,"ogType":673,"canonicalUrls":1579,"schema":1580},"Behind the scenes of the Remote Development Beta release","Discover the epic journey of GitLab's Remote Development team as they navigate last-minute pivots, adapt, and deliver new features for users worldwide.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679888/Blog/Hero%20Images/remotedevelopment.jpg","https://about.gitlab.com/blog/remote-development-beta","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Behind the scenes of the Remote Development Beta release\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"David O'Regan\"}],\n \"datePublished\": \"2023-08-16\",\n }",{"title":1576,"description":1577,"authors":1582,"heroImage":1578,"date":1584,"body":1585,"category":748,"tags":1586},[1583],"David O'Regan","2023-08-16","\nIn May 2023, the Create:IDE team faced an epic challenge – to merge the [Remote Development Rails monolith integration branch](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/105783) into the `master` branch of the GitLab Project. This was no small ask, as the merge request was of considerable size and complexity. In this blog post, we'll delve into the background, justifications, and process behind this endeavor.\n\nThe merge request titled \"Remote Development feature behind a feature flag\" was initiated by the Create:IDE team, aiming to merge the branch \"remote_dev\" into the \"master\" branch in the Rails monolith GitLab project. The MR contained `4` commits, `258` pipelines, and `143` changes that amounted to a total of `+7243` lines of code added to the codebase.\n\nInitially, the MR was created to reflect the work related to \"Remote Development\" under the \"Category: Remote Development.\" It was primarily intended to have CI pipeline coverage for the integration branch and was not meant for individual review or direct merging. The plan was to merge this code into the master branch via the [\"Remote Development Beta - Review and merge\" Epic](https://gitlab.com/groups/gitlab-org/-/epics/10258).\n\n![SUM](https://about.gitlab.com/images/blogimages/remote-development/SUM.png){: .shadow.medium}\n\n### How the Remote Development project started\nAs a team, we embarked on an ambitious journey to create a greenfield feature: the [Remote Development](https://docs.gitlab.com/ee/user/project/remote_development/) offering at GitLab. This feature had a vast scope, many unknowns, and required solving numerous new problems. To efficiently tackle this task, we decided to work on an integration branch using a [low-ceremony process](https://stackoverflow.com/questions/68092498/what-does-low-ceremony-mean). This decision enabled us to develop and release the feature in an impressively short time frame of less than four months.\n\nWorking on an integration branch provided us the flexibility to make significant progress, but it was always intended to eventually break down the work into smaller, iterative MRs that would follow the standard [GitLab review process](https://docs.gitlab.com/ee/development/code_review.html). We had a [detailed plan](https://gitlab.com/gitlab-org/remote-development/gitlab-remote-development-docs/-/blob/main/doc/integration-branch-process.md#master-mr-process-summary) for this process, but we realized that following the original plan would not allow us to meet our goal of releasing of the feature in GitLab 16.0.\n\n### Merging the integration branch MR without breaking it up\nDuring the development of the Remote Development feature, our team faced several challenges that led us to adopt a new approach for merging the integration branch into the master. First, as part of our [velocity-based XP/Scrum style process](https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#-remote-development-iteration-planning), we realized that meeting the 16.0 release goal would require us to cut scope. A velocity report, \"[Velocity-based agile planning report](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/118436),\" highlighted that breaking down and reviewing individual MRs would take too long, considering the impending due date and the likelihood of last-minute scope additions.\n\nSecond, we [made the decision](https://gitlab.com/gitlab-org/gitlab/-/issues/398227#note_1361192858) to release workspaces as a **beta feature for public projects** for customers in [GitLab 16.0](/releases/2023/05/22/gitlab-16-0-released/#remote-development-workspaces-available-in-beta-for-public-projects). This approach reduced the complexity of the rollout plan and allowed us to get valuable feedback earlier, but required us to enable the feature by default earlier than planned. To align with this decision, we determined that merging the integration branch after review was the best course of action. An announcement was made to explain the change in plan, and we set specific timelines for the review process to ensure smooth coordination.\n\n> Hello Reviewers/Maintainers 👋 We have opened up a Zoom room through all of next week as an easy sync place for us all to collaborate and triage questions. As the MR is quite large, it might be overwhelming to determine where to begin. To help, we will aim to furnish a summary of what we have included, such as two new database tables and a couple of GraphQL/REST APIs. We will also be available through the week in the Zoom room and without it being too prescriptive of a approach, I would suggest we do a sync walkthrough of the MR first and then kick off the reviews.\n\nAddressing the concerns about risk, team members discussed the challenges and potential solutions. While there were apprehensions, we were confident in the overall quality of the feature. A disciplined plan for merging MRs was initially considered, but based on our velocity metrics, it was evident that meeting the public beta release goal required a new strategy.\n\nDespite the deviations from our usual practices, we acknowledged the urgency to deliver the initial release on time. The decision was not taken lightly, and we ensured that the merge had extensive [test coverage](https://docs.gitlab.com/ee/ci/testing/test_coverage_visualization.html) and [feature flags](https://docs.gitlab.com/ee/operations/feature_flags.html) in place to address any potential issues. We accepted that some aspects would be overlooked in the initial MR review cycle, but we committed to addressing them in subsequent iterations.\n\n### Keeping the pipeline green and stable for the merge\nTo ensure the successful merge of the integration branch containing the Remote Development feature, our team made significant efforts to keep the pipeline green and stable. As the MR was quite large and contained critical functionality, it was crucial to maintain a high level of quality and reduce the risk of introducing regressions.\n\nTo address these challenges, the team adopted a disciplined approach to [CI/CD](https://about.gitlab.com/topics/ci-cd/). Throughout the development process, CI pipelines were carefully monitored, and any failing tests or issues were promptly addressed. The team conducted rigorous testing and code reviews to identify and fix potential bugs and ensure that the changes did not negatively impact the existing functionality of the codebase.\n\nAdditionally, extensive test coverage was put in place to ensure that the new feature worked as expected and did not cause unintended side effects. The team utilized GitLab's [test coverage visualization](https://docs.gitlab.com/ee/ci/testing/test_coverage_visualization.html) capabilities to track the extent of test coverage and identify areas that required additional testing.\n\n![PIPE](https://about.gitlab.com/images/blogimages/remote-development/PIPE.png){: .shadow.medium}\n\n## The merging process\nAs part of the Remote Development team, we took a strategic approach to the merging process. We identified three categories of follow-up tasks that needed to be addressed after the release:\n\n1. **To-dos:** This category encompassed follow-up issues that required further attention.\n2. **Disabled linting rules:** Any issues related to disabled linting rules were included in this category.\n3. **Follow-up from review:** Non-blocking concerns raised during the review process were categorized here.\n\nTo manage this process effectively, we organized these categories into [child epics](https://docs.gitlab.com/ee/user/group/epics/manage_epics.html#multi-level-child-epics) under the main epic representing the merging effort.\n\n1. Child epic for [to-do follow-up issues](https://gitlab.com/groups/gitlab-org/-/epics/10472)\n2. Child epic for [disabled linting rules follow-up issues](https://gitlab.com/groups/gitlab-org/-/epics/10473)\n3. Child epic for [follow-up issues from review](https://gitlab.com/groups/gitlab-org/-/epics/10474)\n\n\n## Reviewer resources\nDuring the integration branch merge process for the Remote Development feature, we ensured a smooth and collaborative review experience for all involved. To facilitate this, we set up the following resources and documented the information in GitLab's issue, epic, and MR reviews for better persistence and traceability:\n\n1. **Dedicated Slack channel:** We had a Slack channel that served as our primary hub for coordinating reviews and resolving any blockers that arose during the process. The discussions, decisions, and important points discussed in this channel were documented in the related GitLab issues and epics. This approach enabled us to maintain a historical record of the conversations for to refer back to in the future.\n2. **General Slack channel:** For non-urgent or non-blocking questions and discussions, reviewers could use the a general Slack channel. Similar to the dedicated channel, we documented the relevant information from this channel in the corresponding issues and MR reviews in GitLab.\n3. **Addressing urgent issues:** When urgent issues required immediate attention, reviewers could directly address our technical leads [Vishal Tak](https://gitlab.com/vtak) and/or [Chad Woolley](https://gitlab.com/cwoolley-gitlab) in their Slack messages. However, we kindly requested that [direct messages were avoided](https://about.gitlab.com/handbook/communication/#avoid-direct-messages) to promote open collaboration. The resolutions to these urgent issues were documented in the corresponding GitLab issues or MR discussions.\n4. **Zoom collaboration room:** The collaborative sessions held in the open Zoom room were not only beneficial for real-time discussions but also for fostering a collaborative environment. After each session, we summarized the key points and decisions made during the meeting in the associated GitLab issue or MR, making sure all important outcomes were captured and accessible to the team.\n\nThroughout the review process, we were committed to maintaining a seamless and well-documented workflow. By capturing all relevant information in GitLab issues, epics, and MR reviews, we ensured that the knowledge was persistently available, and future team members could easily understand the context and decisions made during the integration process.\n\n## Application security review\nDuring the application security review process, we focused on providing a secure and reliable Remote Development feature for our users. Here are the key resources and updates related to the application security review:\n\n1. **Main application security review issue:** The main application security review issue served as the central hub for tracking security-related considerations. You can find the defined process we followed [here](https://about.gitlab.com/handbook/security/security-engineering/application-security/appsec-reviews.html).\n2. **Application security review comment:** The application security review issue contained a comment indicating that the merge was not blocked unless there were severe issues that could impact production. \"In order to maintain a smooth merge process, we do not block MRs from being merged unless we identify severe issues that could prevent the feature from going into production, such as S1 or S2 level problems. If you are aware of any design flaws or concerns that might qualify as such issues, please bring them to our attention. We can review them together and address any questions or concerns that arise. Let's work collaboratively to find an approach that works for both parties. 👍\"\n3. **Engineering perspective:** For managing the application security review process from an engineering team perspective, we had a dedicated issue, which is kept confidential for security reasons. \n4. **Security and authentication matters:** All security and authentication concerns pertaining to the Beta release were documented within the [`Remote Development Beta -Auth` epic](https://gitlab.com/groups/gitlab-org/-/epics/10377). As of April 30, 2023, we are delighted to announce that **no known issues or obstacles were found that would impede the merge**. This represents a significant accomplishment, considering the intricate nature of this new feature.\n5. **Initial question raised:** During the application security review, one initial question was raised, and we promptly addressed it. You can track the issue and our response [here](https://gitlab.com/gitlab-org/gitlab/-/issues/409317).\n\n## Database review\nTo ensure the reliability and efficiency of the Remote Development feature, we sought guidance from the database reviewer. Although the team had not conducted a thorough self-review, we were fully prepared to address any blocking issues raised during the review process. Our references for the review were:\n\n- [Database review documentation](https://docs.gitlab.com/ee/development/database_review.html)\n- [Database reviewer guidelines](https://docs.gitlab.com/ee/development/database/database_reviewer_guidelines.html)\n\nAs an example, during the database migration review, a discussion arose between [Alper Akgun](https://gitlab.com/a_akgun) and Chad, regarding the efficient ordering of columns in the workspaces table. Alper initially suggested placing integer values at the beginning of the table based on relevant documentation.\n\nChad questioned the benefit of this suggestion, pointing out that the specific integer field, `max_hours_before_termination`, would still be padded with empty bytes even if moved to the front, due to its current position between two text fields.\n\nAlper proposed an alternative approach, emphasizing that organizing variable-sized fields (such as `text`, `varchar`, `arrays`, `json`, `jsonb`) at the end of the table could be sufficient for the workspaces table.\n\nUltimately, Chad took the initiative to implement the changes, moving all variable length fields to the end of the table, and documented the discussion as a comment to address review suggestions.\n\nWith this collaborative effort, the workspaces table was efficiently optimized, and the team gained valuable insights into database column ordering strategies.\n\n![DB](https://about.gitlab.com/images/blogimages/remote-development/DB.png){: .shadow.medium}\n\n## Ruby code review\nDuring the Ruby code review phase, we followed a meticulous approach by conducting a comprehensive self-review of every line of code. Our goal was to ensure the highest code quality and address any potential issues identified by the reviewers effectively.\n\nTo ensure clarity, it's important to clarify that the Ruby code review primarily focused on backend changes and server-side improvements. This included optimizing performance, enhancing functionalities, and refining the overall codebase to deliver a seamless user experience.\n\nFor the code review process, we referred to the [Code review documentation](https://docs.gitlab.com/ee/development/code_review.html), a valuable resource that guided us in maintaining industry best practices and adhering to the GitLab community's coding standards.\n\n### Example: Enhance error messages for unavailable features\nAs an example during the code review, we addressed an essential aspect of the workspace method, focusing on how we handle scenarios related to the `remote_development_feature_flag` and the `remote_development` licensed feature. The primary objective was to enhance the error messages presented to users when these features are not available.\n\nInitially, the code employed identical error messages for both cases, making it less clear to users whether the issue was due to a missing license or a disabled feature flag. This ambiguity could lead to confusion and hinder the user experience.\n\n#### The suggested improvement\nDuring the review, one of our maintainers, [Peter Leitzen](https://gitlab.com/splattael), raised an important question: \"Are we OK with having only a single error message for both cases (missing license and missing feature flag)?\"\n\nRecognizing the importance of clear communication, Chad proposed enhancing the error messages to provide distinct descriptions for each case. This improvement aimed to empower users by precisely conveying the reason behind the unavailability of certain features.\n\n#### The revised implementation\nFollowing Chad's suggestion, the code underwent the following changes:\n\n```ruby\nunless ::Feature.enabled?(:remote_development_feature_flag)\n # TODO: Could have `included Gitlab::Graphql::Authorize::AuthorizeResource` and then use\n # raise_resource_not_available_error!, but didn't want to take the risk to mix that into\n # the root query type\n raise ::Gitlab::Graphql::Errors::ResourceNotAvailable,\n \"'remote_development_feature_flag' feature flag is disabled\"\nend\n\nunless License.feature_available?(:remote_development)\n # TODO: Could have `included Gitlab::Graphql::Authorize::AuthorizeResource` and then use\n # raise_resource_not_available_error!, but didn't want to take the risk to mix that into\n # the root query type\n raise ::Gitlab::Graphql::Errors::ResourceNotAvailable,\n \"'remote_development' licensed feature is not available\"\nend\n\nraise_resource_not_available_error!('Feature is not available') unless current_user&.can?(:read_workspace)\n```\n\n#### The value of distinct error messages\nBy implementing distinct and descriptive error messages, we reinforce our commitment to user-centric development. Users interacting with our system will receive accurate feedback, helping them navigate potential roadblocks effectively. This enhancement not only improves the user experience but also streamlines troubleshooting and support processes.\n\nThis code review example highlights the significance of concise and informative error messages in delivering a top-notch user experience within the GitLab ecosystem. Our team's collaborative efforts ensure that users can confidently interact with our platform, knowing they'll receive clear and helpful error messages when needed.\n\n![BE1](https://about.gitlab.com/images/blogimages/remote-development/BE1.png){: .shadow.medium}\n\n### Example: Improving performance and addressing N+1 issues in WorkspaceType\nIn a recent code review, our team focused on optimizing the WorkspaceType and addressing potential N+1 query problems. The discussion involved two key contributors, [Laura Montemayor](https://gitlab.com/lauraX) and Chad, who worked together to enhance the performance of the codebase.\n\n#### Identifying the performance concerns\nDuring the review, Laura raised a performance concern regarding the possibility of N+1 queries in the WorkspaceType resolver. She suggested that preloading certain associations could be beneficial to avoid this common performance issue.\n\n#### A separate issue for N+1 control\nChad took prompt action and created a separate issue specifically aimed at resolving the N+1 query problems. The new issue, titled \"Address review feedback: Resolve N+1 issues,\" would address the concerns raised by Laura and implement the necessary preloading.\n\n#### Evaluating the potential N+1 impact\nChad provided insightful information about the low risk of real N+1 impact from two particular fields in the current implementation. He elaborated on how the queries for user and agent associations would largely be cache hits due to scoping and usage patterns. Chad diligently examined the cache hits happening in development, confirming the potential optimization.\n\nHere's a code snippet from the initial implementation:\n\n```ruby\n# Initial Implementation\nclass WorkspaceType \u003C BaseType\n field :user, ::Types::UserType,\n description: \"User associated with this workspace\",\n null: true\n\n field :agent, ::Types::AgentType,\n description: \"Agent associated with this workspace\",\n null: true\n\n # Resolver for the user association\n def user\n object.user\n end\n\n # Resolver for the agent association\n def agent\n object.agent\n end\nend\n```\n\n#### Treating performance as a priority\nBoth contributors acknowledged the significance of addressing the performance concern, with Laura emphasizing its importance. They agreed to prioritize the separate issue dedicated to resolving the N+1 queries and ensuring proper test coverage.\n\nHere's a code snippet from the revised implementation:\n\n```ruby\n# Revised Implementation with Preloading\nclass WorkspaceType \u003C BaseType\n field :user, ::Types::UserType,\n description: \"User associated with this workspace\",\n null: true\n\n field :agent, ::Types::AgentType,\n description: \"Agent associated with this workspace\",\n null: true\n\n # Resolver for the user association with preloading\n def user\n ::Dataloader.for(::User).load(object.user_id)\n end\n\n # Resolver for the agent association with preloading\n def agent\n ::Dataloader.for(::Agent).load(object.agent_id)\n end\nend\n```\n\n#### Considering future usage\nChad expressed excitement about the possibility of the new feature gaining significant usage. He humorously stated that encountering enough legitimate traffic on workspaces to trigger any performance impact would be a delightful problem to have, as it would indicate a growing user base.\n\n#### Collaboration and performance improvement\nThe code review exemplifies the collaborative and proactive approach of our team in optimizing the WorkspaceType. The team's dedication to addressing performance concerns ensures that our codebase remains performant and efficient, even as our user base grows.\n\n![BE2](https://about.gitlab.com/images/blogimages/remote-development/BE2.png){: .shadow.medium}\n\n## Frontend code review\nThe frontend code review process was managed by our resident `Create: IDE` frontend maintainers, [Paul Slaughter](https://gitlab.com/pslaughter) and [Enrique Alcátara](https://gitlab.com/ealcantara). Additionally, a significant portion of the new frontend UI code had already undergone separate reviews and was merged to master, contributing to the overall quality of the Remote Development feature.\n\n### Example: Collaborative code improvement for ApolloCache Mutators\nPaul started a thread on an old version of the diff related to `ee/spec/frontend/remote_development/pages/create_spec.js``. The code snippet in question involved creating a mock Apollo instance and writing queries to the cache.\n\n#### The initial implementation\nInitially, the code involved writing to the cache twice, which raised concerns among the maintainers, Paul and Enrique. Paul pointed out that the duplicate write was unintentional and wondered if the writeQuery was even necessary, given the removal of @client directives. However, he also acknowledged the need to test that the created workspace was added to the ApolloCache.\n\n```javascript\n// Initial Implementation\nconst buildMockApollo = () => {\n // ... Other mock setup ...\n \n // Initial writeQuery for userWorkspacesQuery\n mockApollo.clients.defaultClient.cache.writeQuery({\n query: userWorkspacesQuery,\n data: USER_WORKSPACES_QUERY_EMPTY_RESULT.data,\n });\n\n // ... Other mock setup ...\n};\n```\n\n#### Identifying a potential issue\nEnrique agreed that the duplicate write was unintentional and probably introduced during a rebase. He explained that pre-populating the cache with a user workspaces query empty result was essential for the mutator to have a place to add the workspace. However, he encountered difficulties in making the workaround work effectively in unit tests.\n\n#### Resolving the issue\nPaul highlighted the significance of pre-populating the cache with the user workspaces query empty result. He suggested leaving a comment to explain the necessity of the initial writeQuery, as it would be implicitly coupled to future writeQuery operations.\n\n```javascript\n// Resolving the Issue - Leaving a Comment\n// Pre-populate the cache with user workspaces query empty result to provide a place\n// for the mutator to add the Workspace later. This is needed for both test and production environments.\nmockApollo.clients.defaultClient.cache.writeQuery({\n query: userWorkspacesQuery,\n data: USER_WORKSPACES_QUERY_EMPTY_RESULT.data,\n});\n```\n\nHowever, upon further investigation, Paul discovered that the writeQuery might not be needed, and the issue might be a symptom of an underlying problem. He decided to open a separate thread to address this concern and indicated that he would work on a separate MR to handle it.\n\n```javascript\n// Resolving the Issue - Opening a Separate Thread and MR\n// Open a separate thread to discuss potential underlying issues.\n// Plan to work on a separate MR to handle it.\n// Stay tuned for updates!\n```\n\n![FE](https://about.gitlab.com/images/blogimages/remote-development/FE.png){: .shadow.medium}\n\n## What we learned\nAs part of the Remote Development team, we faced the challenge of merging the Remote Development Rails monolith integration branch to meet our ambitious release goal. We adapted to last-minute pivots and focused on minimizing risks during the review process. The successful merge brought us one step closer to benefiting GitLab users worldwide. We acknowledged areas for improvement and remained committed to refining the feature's quality. Our journey reflects our dedication to delivering results, embracing change, and pushing boundaries in the DevOps community. The release of the Remote Development feature in GitLab 16.0 is a significant milestone for GitLab, and we continue to iterate and grow, providing innovative solutions for developers worldwide.\n\nAn outcome of this process was an ongoing conversation to propose a [simplified review process for greenfield features](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/125117). Through this proposal, we aim to distill the lessons we learned during this experience and provide guidance to future teams facing similar challenges.\n\n## What is next for Remote Development?\nAfter the merge of the MR, several changes were implemented:\n- The first production tests were conducted to ensure the stability and functionality of the merged code.\n- Collaboration took place between the Dev Evangelism and Technical Marketing teams, focusing on [creating content](https://gitlab.com/groups/gitlab-com/marketing/developer-relations/-/epics/190). This collaboration aimed to troubleshoot any issues that arose during the merge.\n- Feedback from the community was taken into account, and changes were made to address the concerns raised. This feedback was incorporated into an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/410031) and influenced the overall roadmap and direction of the project.\n\nDo you want to [contribute to GitLab](/community/contribute/)? Come and join in the conversation in the `#contribute` channel on GitLab's [Discord](https://discord.gg/gitlab), or just pop in and say \"Hi.\"\n\n",[797,1587,1157,1158,9,682],"DevSecOps",{"slug":1589,"featured":6,"template":685},"remote-development-beta","content:en-us:blog:remote-development-beta.yml","Remote Development Beta","en-us/blog/remote-development-beta.yml","en-us/blog/remote-development-beta",{"_path":1595,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1596,"content":1601,"config":1606,"_id":1608,"_type":13,"title":1609,"_source":15,"_file":1610,"_stem":1611,"_extension":18},"/en-us/blog/semyon-pupkov-contributor-post",{"title":1597,"description":1598,"ogTitle":1597,"ogDescription":1598,"noIndex":6,"ogImage":809,"ogUrl":1599,"ogSiteName":672,"ogType":673,"canonicalUrls":1599,"schema":1600},"GitLab Code Contributor: Semyon Pupkov","Long-time contributor Semyon Pupkov shares why he loves contributing to GitLab.","https://about.gitlab.com/blog/semyon-pupkov-contributor-post","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"GitLab Code Contributor: Semyon Pupkov\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2019-01-30\",\n }",{"title":1597,"description":1598,"authors":1602,"heroImage":809,"date":1603,"body":1604,"category":680,"tags":1605},[677],"2019-01-30","\n\nFor this month's contributor post, I'm excited to introduce [Semyon Pupkov](https://gitlab.com/artofhuman), who's been a consistent contributor to GitLab since 2016. The graph below shows Semyon's merge requests (MRs) since GitLab 8.13. Let's get to know him!\n\n![Semyon's MRs](https://about.gitlab.com/images/blogimages/semyon-blogpost/semyon-mrs.png){: .small.center}\n\n### Can you tell us where you live and a little bit about your area?\n\nI live in a city called [Yekaterinburg](https://www.google.com/maps/place/Yekaterinburg,+Sverdlovsk+Oblast,+Russia/@56.8138122,60.5145089,11z) in the Ural region of Russia. I love the nature here as it's not too hot in the summer and you will find good snow in the winter for snow boarding.\n\n### When did you first contribute to GitLab and why did you decide to contribute?\n\n[My first MR](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6762) about two years ago was a pretty simple one as I removed unnecessary code from tests. I used GitLab Community Edition for my private projects and since I like open source software, I decided to look at the GitLab code base. When I found some areas for improvement mainly in tests, I decided to create my first MR.\n\n### Which areas of GitLab product have you been contributing to over the past two years?\n\nMost of my contributions have been on the backend side where I tried to improve the existing code base.\n\n### Can you tell us what you do professionally?\n\nI am a backend Ruby/Python developer and work at a company called [SKB Kontur](https://kontur.ru/eng/about).\n\n### What do you enjoy doing when you're not working?\n\nI have been a father for about six months, and I try to give as much of my free time to my daughter. I also like playing games on PlayStation 4 and my favorite game right now is FIFA 19. And of course, I like to contribute to open source projects.\n\n![Semyon's family](https://about.gitlab.com/images/blogimages/semyon-blogpost/semyon-family.JPG){: .shadow.small.center}\n\n### What can we do better to help GitLab community contributors?\n\nSometimes in issues/MRs, I find links to Zendesk tickets or Slack discussions that are private, and this can be frustrating for someone not working at GitLab. Also, it would be great if GitLab had a better setup for local development with Docker and Docker Compose. I found the branch in the [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit) repository with [support for Docker Compose](https://gitlab.com/gitlab-org/gitlab-development-kit/tree/docker-compose), but it probably needs some updating. I recently submitted an [MR to help address this](https://gitlab.com/gitlab-org/gitlab-development-kit/merge_requests/592).\n\n### What advice do you have for others who may be interested in contributing to GitLab?\n\nJust don't be afraid to get started. If you find places in the code that can be improved, you should make a contribution and in most cases your code will be welcomed and accepted.\n\nContributing to GitLab also allows you to work with a strong professional team. It's a good way to improve your skills while working on a great product.\n\n### Interested in learning how you can contribute?\n\nA good place to start is the [Contributing to GitLab page](/community/contribute/), where you can learn how you can contribute to GitLab code, documentation, translation, and UX design.\n\nIf you have any questions, you are always welcome to reach me at rpaik@gitlab.com.\n\n_Note: This post is part of [a series featuring people who contribute to GitLab](/blog/tags.html#contributors)._\n",[266,817,682,9],{"slug":1607,"featured":6,"template":685},"semyon-pupkov-contributor-post","content:en-us:blog:semyon-pupkov-contributor-post.yml","Semyon Pupkov Contributor Post","en-us/blog/semyon-pupkov-contributor-post.yml","en-us/blog/semyon-pupkov-contributor-post",{"_path":1613,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1614,"content":1620,"config":1627,"_id":1629,"_type":13,"title":1630,"_source":15,"_file":1631,"_stem":1632,"_extension":18},"/en-us/blog/start-contributing-to-gitlab-today",{"title":1615,"description":1616,"ogTitle":1615,"ogDescription":1616,"noIndex":6,"ogImage":1617,"ogUrl":1618,"ogSiteName":672,"ogType":673,"canonicalUrls":1618,"schema":1619},"Start contributing to GitLab today","Learn how to start contributing to GitLab and how GitLab team members are here to help.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749676361/Blog/Hero%20Images/collaboration.jpg","https://about.gitlab.com/blog/start-contributing-to-gitlab-today","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Start contributing to GitLab today\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Rémy Coutable\"}],\n \"datePublished\": \"2020-09-30\",\n }",{"title":1615,"description":1616,"authors":1621,"heroImage":1617,"date":1623,"body":1624,"category":1625,"tags":1626},[1622],"Rémy Coutable","2020-09-30","\n{::options parse_block_html=\"true\" /}\n\nAt GitLab, [everyone can contribute](https://about.gitlab.com/company/mission/#mission). This has been our mission from day\none, since GitLab started as --and is still-- an open-source project.\n\nWe believe that, when consumers become contributors, it benefits everyone: GitLab the product, GitLab the company, GitLab the community\nas well as all GitLab users all around the world.\n\nWe already merged more than 7,700 [“community contribution”](https://gitlab.com/groups/gitlab-org/-/merge_requests?label_name%5B%5D=Community+contribution&state=merged) merge requests from our wider community (at the `gitlab-org` group level).\n\n![Screenshot showing more than 7,700 merged community MRs](https://about.gitlab.com/images/blogimages/2020-09-30-community-contributions.png){: .shadow.medium.center}\n*\u003Csmall>Merge requests from community members not employed by GitLab (aka from the GitLab wider community)\u003C/small>*\n\n## Contributing tracks\n\nNow, it's your turn to contribute and improve GitLab! Since not everyone share the same interests nor competencies, we\nhave multiple tracks to ensure everyone can contribute:\n\n- [Development (new features, bug fixes, performance improvements)](/community/contribute/development/)\n- [Documentation addition, improvements, and fixes](/community/contribute/documentation/)\n- [Translations](/community/contribute/translation/)\n- [UX design](https://about.gitlab.com/community/contribute/ux-design/)\n- [Project templates](/community/contribute/project-templates/)\n\nWhen you're ready, simply choose the track for you and follow the instructions.\n\n## Start small...\n\nTo get familiar with the merge request workflow, I advise you start small.\n[Fixing a typo](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/42447) or\n[adding a comma](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/43021) in the documentation are small yet awesome\ncontributions that are usually merged in a matter of hours. These are awesome to gear up and get the ball rolling.\n\nFor more examples, be sure to take a look at the [community merge requests that touched GitLab documentation](https://gitlab.com/gitlab-org/gitlab/-/merge_requests?state=merged&label_name[]=documentation&label_name[]=Community%20contribution).\n\nThese kind of changes don't require a lot of time from you, but if you have more time and are ready to tackle bigger challenges,\nyou can start looking for [bugs](https://gitlab.com/gitlab-org/gitlab/-/issues?label_name%5B%5D=Accepting+merge+requests&label_name[]=type::bug&scope=all&sort=popularity&state=opened)\nor [feature proposals](https://gitlab.com/gitlab-org/gitlab/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Accepting%20merge%20requests&label_name[]=feature).\n\n## ...and end up MVP\n\nEvery contribution is a collaborative effort between the merge request author, the reviewer(s), potentially MR coaches, and the maintainer (who gets to merge the MR).\n\nSome contributions are so complex and technical that they take months of collaboration to get accross the finish line!\n\nLet's give you a few examples of great collaborative efforts that happened in the last 12 months:\n\n1. [Cédric Tabin](https://gitlab.com/ctabin) worked for more than 9 months contributing\n [a new CI job keyword allowing interruptible builds](/releases/2019/09/22/gitlab-12-3-released/#interruptible-keyword-to-indicate-if-a-job-can-be-safely-canceled)\n and working with the GitLab teams to get it across the line. The [merge request](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/23464) involved 51 people, who posted 405 discussion notes!\n This contribution was released in GitLab 12.3, and allows to save a lot of money by avoiding running redundant pipelines.\n1. [Tuomo Ala-Vannesluoma](https://gitlab.com/tuomoa) worked for 7 months adding support for\n [previewing artifacts that are not public](/releases/2019/10/22/gitlab-12-4-released/#private-project-support-for-online-view-of-html-artifacts), a highly requested feature with almost 300 upvotes!\n The [merge request](https://gitlab.com/gitlab-org/gitlab-pages/-/merge_requests/134) landed in GitLab 12.4, and received two 🍾 emoji votes.\n1. [Roger Meier](https://gitlab.com/bufferoverflow) worked for more than 4 months contributing\n [support for S/MIME Signature Verification of Commits](/releases/2020/02/22/gitlab-12-8-released/#smime-signature-verification-of-commits), an important feature for sensitive projects and in regulated industries.\n Roger's teammate, [Henning Schild](https://gitlab.com/henning-schild), contributed the change upstream to Git and Roger made the change in GitLab.\n The [merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/17773) involved 42 people, who posted 430 discussion notes, and landed in GitLab 12.8.\n1. [Steve Exley](https://gitlab.com/steve.exley) worked for more than 5 months contributing one of\n [the biggest architectural changes to the Docker executor](/releases/2020/03/22/gitlab-12-9-released/#gitlab-runner-129).\n that solved multiple issues for the Docker executor, including [jobs sharing the same network bridge](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4430),\n [services don't work when `network_mode` is specified](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2699),\n and lastly, services can connect to one another and connect with the build container as well!\n The [merge request](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/1569) involved 69 people, who posted 293 discussion notes. It landed in GitLab 12.9, and received five 🔥 emoji votes.\n1. [Jesse Hall](https://gitlab.com/jessehall3) worked for more than 5 months contributing one of\n [the Batch Suggestions feature](/releases/2020/07/22/gitlab-13-2-released/#batch-suggestions) which allows MR reviewers to group all suggestions made to a diff and submit them at once.\n Because each suggestion translates into a Git operation, submitting these individually could take a long time if there were a large number of suggestions. Submitting suggestions in batches has numerous advantages, including time savings, efficient CI resource utilization (only one pipeline for all suggestions), and preventing an overly noisy Git history.\n The [merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/22439) involved 38 people, who posted 358 discussion notes. It landed in GitLab 13.2, and received seven 💚 emoji votes.\n\n## Get some help from the GitLab team\n\nIf you need any help while contributing to GitLab, below are some of the resources that are available.\n\n1. Ask questions on the [Contributors Gitter Channel](https://gitter.im/gitlabhq/contributors).\n1. Get in touch with [Merge Request Coaches](https://handbook.gitlab.com/job-families/expert/merge-request-coach/). To find a merge request coach, go to the GitLab Team Page and search for \"Merge Request Coach\".\n You can also mention Merge Request Coaches by typing `@gitlab-org/coaches` in a comment.\n1. Find reviewers & maintainers of Gitlab projects in our [handbook](/handbook/engineering/projects/#gitlab) and [mention](https://docs.gitlab.com/ee/user/group/subgroups/#mentioning-subgroups) them in a comment.\n1. If you have feature ideas/questions, you can search for existing issues or create a new issue if there isn't one already. Feel free to [mention](https://docs.gitlab.com/ee/user/group/subgroups/#mentioning-subgroups) [product team members](/handbook/product/categories/) in the issue.\n\nWait for a reviewer. You’ll likely need to change some things once the reviewer has completed a code review for your merge request.\nYou may also need multiple reviews depending on the size of the change.\nIf you don't hear from anyone in a timely manner, feel free to find reviewers or reach out to Merge Request Coaches.\nPlease don't be shy about [mentioning](https://docs.gitlab.com/ee/user/project/issues/index.html)\nGitLab team members in your merge requests as all team members are expected to be responsive to fellow community members.\n\n## How we stay on top of community contributions\n\nIn Q3 of 2020, several GitLab teams are focusing on improving the experience for community contributors. To achieve this goal,\nwe created a few metrics around community contributions:\n\n* [Community Contribution Mean Time to Merge](/handbook/engineering/quality/performance-indicators/#community-contribution-mean-time-to-merge)\n* [Unique Community Contributors per Month](/handbook/engineering/quality/performance-indicators/#unique-community-contributors-per-month)\n* [Community MR Coaches per Month](/handbook/engineering/quality/performance-indicators/#community-mr-coaches-per-month)\n\nTo make sure the GitLab team is working hand in hand with the wider community in a timely fashion, we've already put a few automations in place:\n\n1. Every hour, wider community contributions are automatically [labelled \"Community contribution\"](/handbook/engineering/quality/triage-operations/#community-contributions).\n1. Every day, a report with the [untriaged](/handbook/engineering/quality/merge-request-triage/) community merge requests is created and assigned to the Merge Request Coaches for triage. This ensures each merge request has a [stage and group](/handbook/product/categories/#hierarchy) labels set.\n1. Every two weeks, a report with unassigned and idle community contributions is created for each [group](/handbook/product/categories/#hierarchy).\n\nThese automations are powered by our [`triage-ops` project](https://gitlab.com/gitlab-org/quality/triage-ops/) and are documented in [Triage Operations](/handbook/engineering/quality/triage-operations/).\n\nI hope this post convinced you to start contributing to GitLab. Keep in mind, any contribution is valuable, and don't worry, we're here to support you.\n\nCover image: [\"Żuki leśne na liściu jesienią\"](https://unsplash.com/photos/5S2xIoNpcGk) by [Krzysztof Niewolny](https://unsplash.com/@epan5).\n{: .note}\n","unfiltered",[817,266,9,728,682],{"slug":1628,"featured":6,"template":685},"start-contributing-to-gitlab-today","content:en-us:blog:start-contributing-to-gitlab-today.yml","Start Contributing To Gitlab Today","en-us/blog/start-contributing-to-gitlab-today.yml","en-us/blog/start-contributing-to-gitlab-today",{"_path":1634,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1635,"content":1641,"config":1646,"_id":1648,"_type":13,"title":1649,"_source":15,"_file":1650,"_stem":1651,"_extension":18},"/en-us/blog/startup-covid-tracking",{"title":1636,"description":1637,"ogTitle":1636,"ogDescription":1637,"noIndex":6,"ogImage":1638,"ogUrl":1639,"ogSiteName":672,"ogType":673,"canonicalUrls":1639,"schema":1640},"How an analytics software startup took aim at COVID-19","Illumina Consulting Group didn’t just sit idle during the pandemic. Here’s how they developed a COVID-19 assessment and analysis tool.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681320/Blog/Hero%20Images/startupcovid.jpg","https://about.gitlab.com/blog/startup-covid-tracking","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How an analytics software startup took aim at COVID-19\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n \"datePublished\": \"2020-05-15\",\n }",{"title":1636,"description":1637,"authors":1642,"heroImage":1638,"date":1643,"body":1644,"category":680,"tags":1645},[834],"2020-05-15","\n\n_In the second of our irregular series on [the intersection of technology and COVID-19](/blog/cobol-programmer-shortage/), here’s a look at how one small software company changed gears to create a tool for symptom tracking._\n\nWe’ve heard a lot about companies around the world moving from [toy production to personal protective equipment](https://sports.yahoo.com/toy-companies-switch-gears-help-022919242.html), or switching gears from [making gin to making hand sanitizer](https://www.bbc.com/worklife/article/20200413-how-factories-change-production-to-quickly-fight-coronavirus).\n\nBut how about companies that have contributed in a more subtle way?\n\n[Illumina Consulting Group](https://icgsolutions.com/) is a Maryland-based data analytics software startup that does most of its work for the intelligence community. Suffice it to say about two months ago the team found themselves with time on their hands, says CEO David Waldrop. \"ICG has a very potent team of developers,\" he explains. \"So when this COVID thing kind of happened, we were sitting around trying to figure out what to do for the next eight weeks or longer sitting at home like groundhog day, with every day the same as the next. How could we help with this COVID thing with our skillset? We build software, that's what we do for a living.\" (For the record ICG is a GitLab customer, but this isn’t a post about that.)\n\nWaldrop’s team defined the requirements and concluded the biggest problem with this very contagious virus is a shortage of primary information. \"Who's really got the disease and how early in the process can we detect them?\" he asks. \"And the answer to that is pretty straightforward. Who's the person who knows if they've got the disease? Every person that's out there that's got a nose and ears and eyes that might have a sniffle and a fever. And so how could we get that information from those people? What if we just asked them?\"\n\nAnd with that simple thought process, a symptom assessment tool, [DoIhaveit.net](https://doihaveit.net/home#home), was born. The tool offers users both a snapshot of COVID-19 in their area (based on zip code) and asks them to take a quick two minute health survey. Using the results of that data, DoIhaveit (or DIHI as they call it) offers advice straight from the Centers for Disease Control. The survey is anonymous – it does not collect personal identifying information or private health data.\n\n![DoIhaveit.net home page](https://about.gitlab.com/images/blogimages/doihaveitscreenshot.png){: .shadow.medium.center.wrap-text}\n\nWaldrop admits the team was skeptical at first about the idea of people being willing to contribute their experiences. But \"everybody's got a mother or a grandmother or an older uncle or somebody,\" he says. \"When that person goes to the hospital, they want there to be a bed and a ventilator and gowns and all that stuff available.\"\n\nTo meet those needs ICG built DoIhaveit with a frontend survey piece and a backend that will aggregate and analyze the data down to the zip code level. \"We made it so the messaging at the assessment and the summary level can be jurisdictionally specific down to the zip code if necessary,\" he says. The team wanted it to be flexible for wherever the cycle takes an area from flattened curve to rising cases and to be modifiable by a public health or safety team that might want to adjust the parameters on the fly.\n\nAnd that’s the real point of DoIhaveit, Waldrop says – to make sure doctors and hospital systems are prepared for a potential onslaught. \"We built this as a public service and it’s ready to go.\" It’s in use in Virginia and the company wants to spread the word across the country. It’s completely free of charge for municipalities and Waldrop stresses ICG isn’t making any money from this. \"We hope to get this into as many hands as possible.\"\n\nCover image by [Centers for Disease Control](https://unsplash.com/@cdc) on [Unsplash](https://unsplash.com)\n{: .note}\n",[817,266,9],{"slug":1647,"featured":6,"template":685},"startup-covid-tracking","content:en-us:blog:startup-covid-tracking.yml","Startup Covid Tracking","en-us/blog/startup-covid-tracking.yml","en-us/blog/startup-covid-tracking",{"_path":1653,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1654,"content":1659,"config":1666,"_id":1668,"_type":13,"title":1669,"_source":15,"_file":1670,"_stem":1671,"_extension":18},"/en-us/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"title":1655,"description":1656,"ogTitle":1655,"ogDescription":1656,"noIndex":6,"ogImage":1210,"ogUrl":1657,"ogSiteName":672,"ogType":673,"canonicalUrls":1657,"schema":1658},"The Co-Create Program: How customers are collaborating to build GitLab","Learn how organizations like Thales, Scania, and Kitware are partnering with GitLab engineers to contribute meaningful features that benefit the entire community.","https://about.gitlab.com/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"The Co-Create Program: How customers are collaborating to build GitLab\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Fatima Sarah Khalid\"}],\n \"datePublished\": \"2025-01-30\",\n }",{"title":1655,"description":1656,"authors":1660,"heroImage":1210,"date":1661,"body":1662,"category":1663,"tags":1664},[793],"2025-01-30","This past year, over 800 community members have made more than 3,000 contributions to GitLab. These contributors include team members from global organizations like Thales, Scania, and Kitware, who are helping shape GitLab's future through the [Co-Create Program](https://about.gitlab.com/community/co-create/) — GitLab's collaborative development program where customers work directly with GitLab engineers to contribute meaningful features to the platform.\n\nThrough workshops, pair programming sessions, and ongoing support, program participants get hands-on experience with GitLab's architecture and codebase while solving issues or improving existing features.\n\n\"Our experience with the Co-Create Program has been incredible,\" explains Sébastien Lejeune, open source advocate at Thales. \"It only took two months between discussing our contribution with a GitLab Contributor Success Engineer and getting it live in the GitLab release.\"\n\nIn this post, we'll explore how customers have leveraged the Co-Create Program to turn their ideas into code, learning and contributing along the way.\n\n## The Co-Create experience\n[The GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit) helps contributors get started developing on GitLab. \"The advice I would give new contributors is to remember that you can't break anything with the GDK,\" says Hook. \"If you make a change and it doesn't work, you can undo it or start again. The beauty of GDK is that you can tinker, test, and learn without worrying about the environment.\"\n\nEach participating organization in the Co-Create Program receives support throughout their contribution journey:\n\n- __Technical onboarding workshop__: A dedicated session to set up the GitLab Development Kit (GDK) and understand GitLab's architecture\n- __1:1 engineering support__: Access to GitLab engineers for pair programming and technical guidance\n- __Architecture deep dives__: Focused sessions on specific GitLab components relevant to the issue the organization is contributing to\n- __Code review support__: Detailed feedback and guidance through the merge request process\n- __Regular check-ins__: Ongoing collaboration to ensure progress and address any challenges\n\nThis structure ensures that teams can contribute effectively, regardless of their prior experience with GitLab's codebase or the Ruby/Go programming language. As John Parent from Kitware notes, \"If you've never seen or worked with GitLab before, you're staring at a sophisticated architecture and so much code across different projects. The Co-Create Program helps distill what would take weeks of internal training into a targeted crash course.\"\n\nThe result is a program that not only helps deliver new features but also builds lasting relationships between GitLab and its user community. \"It's inspiring for our engineers to see the passion our customers bring to contributing to and building GitLab together,\" shares Shekhar Patnaik, principal engineer at GitLab. \"Customers get to see the 'GitLab way,' and engineers get to witness their commitment to shaping the future of GitLab.\"\n\n## Enhancing project UX with Thales\nWhen Thales identified opportunities to improve GitLab's empty project UI, they didn't just file a feature request — they built the solution themselves. Their contributions focused on streamlining the new project setup experience by simplifying SSH/HTTPS configuration with a tabbed interface and adding copy/paste functionality for the code snippets. These changes had a significant impact on developer workflows.\n\nThe team's impact extended beyond the UX improvements. Quentin Michaud, PhD fellow for cloud applications on the edge at Thales, contributed to improving the GitLab Development Kit (GDK). As a package maintainer for Arch Linux, Michaud's expertise helped improve GDK's documentation and support its containerization efforts, making it easier for future contributors to get started.\n\n\"My open source experience helped me troubleshoot GDK's support for Linux distros,” says Michaud. “While improving package versioning documentation, I saw that GitLab's Contributor Success team was also working to set up GDK into a container. Seeing our efforts converge was a great moment for me — it showed how open source collaboration can help build better solutions.\"\n\nThe positive experience for the Thales team means that Lejeune now uses the Co-Create Program as \"a powerful example to show our managers the return on investment from open source contributions.\"\n\n## Advancing package support with Scania\nWhen Scania needed advanced package support in GitLab, they saw an opportunity to contribute and build it themselves. \n\n\"As long-time GitLab users who actively promote open source within our organization, the Co-Create Program gave us a meaningful way to contribute directly to open source,\" shares Puttaraju Venugopal Hassan, solution architect at Scania.\n\nThe team started with smaller changes to familiarize themselves with the codebase and review process, then progressed to larger features. \"One of the most rewarding aspects of the Co-Create Program has been looking back at the full, end-to-end process and seeing how far we've come,\" reflects Océane Legrand, software developer at Scania. \"We started with discovery and smaller changes, but we took on larger tasks over time. It's great to see that progression.\" \n\nTheir contributions include bug fixes for the package registry and efforts to enhance the Conan package registry feature set, bringing it closer to general availability (GA) readiness while implementing Conan version 2 support. Their work and collaboration with GitLab demonstrates how the Co-Create Program can drive significant improvements to GitLab’s package registry capabilities.\n\n\"From the start, our experience with the Co-Create Program was very organized. We had training sessions that guided us through everything we needed to contribute. One-on-one sessions with a GitLab engineer also gave us an in-depth look at GitLab’s package architecture, which made the contribution process much smoother,\" said Juan Pablo Gonzalez, software developer at Scania. \n\nThe impact of the program goes beyond code — program participants are also building valuable skills as a direct result of their contributions. In [the GitLab 17.8 release](https://about.gitlab.com/releases/2025/01/16/gitlab-17-8-released/#mvp), both Legrand and Gonzalez were recognized as GitLab MVPs. Legrand talked about how the work she's doing in open source impacts both GitLab and Scania, including building new skills for her and her team: \"Contributing through the Co-Create Program has given me new skills, like experience with Ruby and background migrations. When my team at Scania faced an issue during an upgrade, I was able to help troubleshoot because I'd already encountered it through the Co-Create Program.\"\n\n## Optimizing authentication for high-performance computing with Kitware\nKitware brought specialized expertise from their work with national laboratories to improve GitLab's authentication framework. Their contributions included adding support for the OAuth2 device authorization grant flow in GitLab, as well as implementing new database tables, controllers, views, and documentation. This contribution enhances GitLab's authentication options, making it more versatile for devices without browsers or with limited input capabilities.\n\n\"The Co-Create Program is the most efficient and effective way to contribute to GitLab as an external contributor,\" shares John Parent, R&D engineer at Kitware. \"Through developer pairing sessions, we found better implementations that we might have missed working alone.\"\n\nAs a long-time open source contributor, Kitware particularly appreciated GitLab's approach to development. \"I assumed GitLab wouldn't rely on out-of-the-box solutions at its scale, but seeing them incorporate a Ruby dependency instead of building a custom in-house solution was great,” says Parent. “Coming from the C++ world, where package managers are rare, it was refreshing to see this approach and how straightforward it could be.\"\n\n## Building better together: Benefits of Co-Create\nThe Co-Create Program creates value that flows both ways. \"The program bridges a gap between us as GitLab engineers and our customers,\" explains Imre Farkas, staff backend engineer at GitLab. \"As we work with them, we hear their day-to-day challenges, the parts of GitLab they rely on, and where improvements can be made. It's great to see how enthusiastic they are about getting involved in building GitLab with us.\"\n\nThis collaborative approach also accelerates GitLab's development. As Shekhar Patnaik, principal engineer at GitLab, observes: \"Through Co-Create, our customers are helping us move our roadmap forward. Their contributions allow us to deliver critical features faster, benefitting our entire user base. As the program scales, there's a real potential to accelerate development on our most impactful features by working alongside the very people who rely on them.\"\n\n## Get started with Co-Create\nReady to turn your feature requests into reality? Whether you're looking to enhance GitLab's UI like Thales, improve package support like Scania, or optimize authentication like Kitware, the Co-Create Program welcomes organizations who want to actively shape GitLab's future while building valuable open source experience.\n\nContact your GitLab representative to learn more about participating in the Co-Create Program, or visit our [Co-Create page](https://about.gitlab.com/community/co-create/) for more information.\n","customer-stories",[9,682,1665],"customers",{"slug":1667,"featured":90,"template":685},"the-co-create-program-how-customers-are-collaborating-to-build-gitlab","content:en-us:blog:the-co-create-program-how-customers-are-collaborating-to-build-gitlab.yml","The Co Create Program How Customers Are Collaborating To Build Gitlab","en-us/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab.yml","en-us/blog/the-co-create-program-how-customers-are-collaborating-to-build-gitlab",{"_path":1673,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1674,"content":1680,"config":1686,"_id":1688,"_type":13,"title":1689,"_source":15,"_file":1690,"_stem":1691,"_extension":18},"/en-us/blog/three-faces-of-user-calls",{"title":1675,"description":1676,"ogTitle":1675,"ogDescription":1676,"noIndex":6,"ogImage":1677,"ogUrl":1678,"ogSiteName":672,"ogType":673,"canonicalUrls":1678,"schema":1679},"How product managers can get more out of user calls","There are 3 types of user calls. Here's how GitLab product managers approach them and how we leverage our transparency value to better understand our users.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682372/Blog/Hero%20Images/michal-czyz-ALM7RNZuDH8-unsplash.jpg","https://about.gitlab.com/blog/three-faces-of-user-calls","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"How product managers can get more out of user calls\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Viktor Nagy\"}],\n \"datePublished\": \"2022-07-20\",\n }",{"title":1675,"description":1676,"authors":1681,"heroImage":1677,"date":1683,"body":1684,"category":1305,"tags":1685},[1682],"Viktor Nagy","2022-07-20","\n\nOne of the core jobs of product managers is to speak with users to better understand their needs, pain points and the context in which they operate and use our products. But not all user calls are the same. \n\nThere are 3 prominent types of user calls:\n\n- Discovery or problem validation calls\n- Roadmap discussions\n- Solution validation calls\n\nHere's an in-depth look at how we approach the three types of user calls at GitLab.\n\n## Discovery calls\n\nDiscovery or problem validation calls are product managers' most crucial conversations with users. Discovery calls are typically set up to learn about our users in a targeted way. These calls help build a better understanding of users' pain points. \n\nFor discovery, we need a recipe for repeatable, comparable user calls. For this reason, we should create an interview script and follow that script on all the user calls. This does not mean these calls are robotic and devoid of improvisation, not at all! The script should provide the backbone of the discussions. We can adjust it either during the call or in advance based on prior knowledge about the user. Good discovery calls typically take the form of a deep-dive conversation: we know the script by heart and can run back and forth around it, always asking the questions that fit the conversation. \n\nFinding the right users is one of the most challenging parts of discovery calls. Thankfully, with GitLab, this is relatively easy. We can always reach out to the most active users on issues and invite them to a call. Another technique I employ is to find users in the [Cloud Native Computing Foundation](https://www.cncf.io) and Kubernetes communities' Slack channels and articles on [Medium](https://medium.com). This way, I can also find non-GitLab users, a set of people likely more valuable to interview than existing users. Finally, we can recruit users with the support of the account managers. They are always helpful in connecting PMs with users. Asking the users about their needs shows them that we genuinely care about them.\n\nThere are at least two distinct discovery calls: PM-led or UX-led. UX research typically works on projects with a strict scope. For PM-driven calls, a great framework is [\"Continuous discovery\" calls by Teresa Torres](https://www.producttalk.org/continuous-discovery/). With continuous discovery, we build a deep understanding of our users and get well-understood opportunities. The technique allows us to get a broad view and to dive deep into specific aspects of our problem space when needed.\n\n## Roadmap discussions\n\nRoadmap discussion calls are typically initiated by sales or account management teams. Product managers are asked to join the prospect/customer call to strengthen our positions and show how much we care for the customer. \n\nTo prepare for roadmap discussions, PMs should have an effective way to present the roadmap. This typically happens in the form of slides. A diligent PM might even prepare something specifically for the client.\n\nDuring these calls, the user/customer/prospect will typically ask the questions, and the PMs respond. Our role in these calls is to represent the truth. We might be tempted to paint a rosier picture about the current or expected state of the product than is actually true, and we should avoid making time-bound promises.\n\nWhat are the expected outcomes of roadmap discussions? They can help strengthen our position with the user. Remember that these calls primarily cater to our customers/users and customer-facing teams. As such, they are unlikely to provide deep learning about our users. \n\nIf we approach these calls with the intention to prove that our roadmap is correct, we will likely fall victim to both response and confirmation biases. There are techniques to validate a roadmap, but they are more aligned with problem validation than roadmap discussion calls. For example, UX researchers should be able to help validate a roadmap as a UX research project.\n\n## Solution validation calls\n\nLast but not least, we have solution validation calls. These calls serve our learning but are way more focused than discovery calls. Solution validation calls require some form of a prototype for a specific problem we want to test and get feedback on from our users.\n\nAt GitLab, the prototypes are typically built by product design or engineering. The product manager might miss some of these calls in an empowered and autonomous team. But, as these calls are great learning experiences, we should aim to be there to support and learn if we can.\n\nA solution validation call might be started with a concise roadmap discussion. Unlike in sales calls, our aim is not to influence the user but to set the scene for solution validation. The central part of the call should be around the proposed solution. We should provide the least amount of guidance to our users since there are no humans available to direct our users when they are working with the actual product. If much guidance is required, that is a sign that we might want to rethink our UX approach.\n\nFinding suitable interview candidates for a solution validation call might be tricky. For GitLab, we often use the shortcut of inviting users based on their activity on relevant issues. Sometimes, when our issues provide enough context, we might get some solution validation asynchronously as users give their feedback directly in the issue.\n\n## How many calls?\n\nHow often does a good PM have all these calls? For discovery calls, I aim to have 3 calls per week. Above this, I don’t mind taking 1 sales call. While I prefer the product designer to run solution validation calls, I try to participate there too. Not every solution requires dedicated validation, so having a target number for solution validation calls is unrealistic. The better the discovery calls are, the fewer solution validation calls you might need. Still, even the best discovery cannot and should not answer all the questions of a solution validation. Often there are different (and totally valid) approaches to the same problem, and we need to pick the one that is the easiest for users to understand.\n\nI think we need to speak to our users every day. Working at GitLab, sometimes this might take the form of issue comments, but face-to-face calls are a must. In any case, during these discussions we should aim to learn from our users, not just answer their questions. A handy question in issues is to ask for more context from our users. The response might highlight unknown use cases or edge cases we missed previously.\n\n## Take the calls\n\nIt is helpful to remember all the user call types we practice as PMs. As mentioned, I think the most crucial user calls for PMs are the discovery calls. If we don’t make discovery calls, nobody will; also, PMs might not be needed in the other calls. That said, a product manager's job is to also help the business be viable. So we should be able to support sales and always have a deck ready for roadmap calls. Lastly, we should work continuously with our team on solution validation so that everyone is confident in our solution.\n\n",[775,1665,9],{"slug":1687,"featured":6,"template":685},"three-faces-of-user-calls","content:en-us:blog:three-faces-of-user-calls.yml","Three Faces Of User Calls","en-us/blog/three-faces-of-user-calls.yml","en-us/blog/three-faces-of-user-calls",{"_path":1693,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1694,"content":1700,"config":1705,"_id":1707,"_type":13,"title":1708,"_source":15,"_file":1709,"_stem":1710,"_extension":18},"/en-us/blog/translating-gitlab",{"title":1695,"description":1696,"ogTitle":1695,"ogDescription":1696,"noIndex":6,"ogImage":1697,"ogUrl":1698,"ogSiteName":672,"ogType":673,"canonicalUrls":1698,"schema":1699},"Help us speak your language!","GitLab is available in many languages, but there's always more translation work to be done. Here's how you can contribute to translating GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663430/Blog/Hero%20Images/2018-09-13-gitlab-hackathon-cover.jpg","https://about.gitlab.com/blog/translating-gitlab","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Help us speak your language!\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Ray Paik\"}],\n \"datePublished\": \"2019-01-08\",\n }",{"title":1695,"description":1696,"authors":1701,"heroImage":1697,"date":1702,"body":1703,"category":680,"tags":1704},[677],"2019-01-08","\nOne of the lesser-known features of GitLab is that it has been translated into many languages by community members. If you have only seen GitLab in (American) English, you can go to your [Profile page](https://gitlab.com/profile) and change your **Preferred language** to see it in another language.\n\n![Selecting preferred language](https://about.gitlab.com/images/blogimages/translation-blog/preferred_language_chinese.png){: .shadow.small.center}\n\n![GitLab in Chinese](https://about.gitlab.com/images/blogimages/translation-blog/gitlab_in_chinese.png){: .shadow.small.center}\n\nWe are proud of the work done by so many dedicated community members to help translate GitLab, but this is ongoing work, and we also have many languages that are just getting started with translation. That's where you come in!\n\n## Why translate GitLab?\n\nSome may say that GitLab is used by technical people who are already used to using a lot of different software in English, and translation is not really necessary. That may be true, but having the software available in local languages that people are more comfortable with lowers the barrier to entry not only for users, but for contributors too. Maybe it's because GitLab is an [all-remote company](/blog/the-case-for-all-remote-companies/) with [employees in nearly 50 countries](/company/team/), but GitLab team-members appreciate the benefits of localized software in local communities.\n\n## How is GitLab translated and how do I start contributing?\n\nThe translation is managed at [translate.gitlab.com](https://translate.gitlab.com/) using [Crowdin](https://crowdin.com/). First, a phrase (e.g. one that appears in the GitLab user interface or in error messages) needs to be internationalized before it can be translated. The internationalized phrases are then made available for translations on [translate.gitlab.com](https://translate.gitlab.com/). As each phrase is translated, it is added to the translation file, and will then be merged into future releases. You can find more details on how GitLab is translated in the [Translate GitLab documentation](https://docs.gitlab.com/ee/development/i18n/).\n\nAs you can see in the [translation activity stream](https://translate.gitlab.com/project/gitlab-ee/activity_stream), the majority of translations are contributed by community members. You're probably already familar with GitLab's motto, \"Everyone can contribute,\" and contributing translation is even easier than contributing code. All you need is an account on [CrowdIn](https://crowdin.com/) plus a browser, and you are ready to translate GitLab to a language of your choice. So if you're looking for ways to contribute and know other languages, translation is a great place to get started.\n\nDuring the [GitLab Hackathon](/community/hackathon/) in September, one of our [Core Team](/community/core-team/) members [Hannes Rosenögger](https://gitlab.com/haynes) presented a session on translation where he walked through how community members can contribute. You can watch the recording:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/LJ9oSSx0qyY\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Where do we need help?\n\nAs you can see from the screenshot below, GitLab is almost fully translated into several languages, such as Chinese (both Simplifed and Traditional), French, German, Filipino, Brazilian Portuguese, Ukrainian, etc. However, many languages are in early stages, with a lot of translation left to be done and may also need [proofreaders](https://docs.gitlab.com/ee/development/i18n/proofreader.html) to help review and approve translations. You can find steps to becoming a proofreader also outlined in [the proofreader documentation](https://docs.gitlab.com/ee/development/i18n/proofreader.html#become-a-proofreader).\n\n![GitLab translation status](https://about.gitlab.com/images/blogimages/translation-blog/gitlab_translation_status.png){: .shadow.medium.center}\n\nEven if a language is fully translated today, new phrases are added all the time, so we welcome new contributors across all languages. If you have any questions as you get started on [translate.gitlab.com](https://translate.gitlab.com/), you can post questions on the [Crowdin discussions forum](https://translate.gitlab.com/project/gitlab-ee/discussions), and you are always welcome to reach me at rpaik@gitlab.com.\n\n[\"GitLab application screengrab\"](https://unsplash.com/photos/ZV_64LdGoao) by [Pankaj Patel](https://unsplash.com/@pankajpatel) on Unsplash\n{: .note}\n",[266,817,682,9],{"slug":1706,"featured":6,"template":685},"translating-gitlab","content:en-us:blog:translating-gitlab.yml","Translating Gitlab","en-us/blog/translating-gitlab.yml","en-us/blog/translating-gitlab",{"_path":1712,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1713,"content":1719,"config":1724,"_id":1726,"_type":13,"title":1727,"_source":15,"_file":1728,"_stem":1729,"_extension":18},"/en-us/blog/ultimate-perks-for-open-source-projects",{"title":1714,"description":1715,"ogTitle":1714,"ogDescription":1715,"noIndex":6,"ogImage":1716,"ogUrl":1717,"ogSiteName":672,"ogType":673,"canonicalUrls":1717,"schema":1718},"Public open source projects are eligible for Ultimate tier features","GitLab's Open Source Program offers top-tier functionality and 50,000 CI pipeline minutes, for free. Learn more about applying.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667457/Blog/Hero%20Images/open_source_program_blog_image.jpg","https://about.gitlab.com/blog/ultimate-perks-for-open-source-projects","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Public open source projects are eligible for Ultimate tier features\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Orit Golowinski\"}],\n \"datePublished\": \"2022-02-04\",\n }",{"title":1714,"description":1715,"authors":1720,"heroImage":1716,"date":1721,"body":1722,"category":726,"tags":1723},[1520],"2022-02-04","\n> **2022-07-28 UPDATE:** As of 2022-07-01, all public open source projects on the Free tier have to apply to the Open Source program to continue receiving GitLab Ultimate benefits. In-app notifications informing impacted users of the change were active from 2022-04-18 through 2022-07-01. Please refer to the [FAQ](/pricing/faq-efficient-free-tier/#public-projects-on-gitlab-saas-free-tier) for more details.\n\nGitLab believes in a world where everyone can contribute and we like to support those who share our mission.\n\nGitLab exists today in large part thanks to the work of hundreds of thousands of open source contributors around the world. To give back to this community, the [GitLab for Open Source Program](/solutions/open-source/) was created to help open source teams be more efficient, secure, and productive by allowing them to use GitLab’s [top tier](/pricing/) capabilities.\n\nOpen source organizations have to meet the program requirements and actively apply in order to qualify. \n\nRequirements include:\n\n* **OSI-approved open source license**: All of the code you host in this GitLab group must be published under [OSI-approved open source licenses](https://opensource.org/licenses/category)\n* **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](/handbook/marketing/developer-relations/community-programs/opensource-program/#who-qualifies-for-the-gitlab-for-open-source-program).\n* Publicly visible: Your GitLab.com group or self-managed instance and your source code must be [publicly visible and publicly available](https://docs.gitlab.com/ee/user/public_access.html).\n\n[Learn more and apply](/solutions/open-source/join/) to the GitLab for Open Source Program.\n\n**Note**: Newly created public projects will no longer automatically receive the Ultimate tier benefits as of 2022-02-17, more details in [this FAQ entry](/pricing/faq-efficient-free-tier/#public-projects-on-gitlab-saas-free-tier). In order to receive the benefits, you will need to [apply](#how-to-apply) to the GitLab for Open Source Program.\n\n## Why apply to the GitLab for Open Source Program?\n\nThe GitLab for Open Source Program gives access to unlimited seats per license to features of [GitLab Ultimate](/pricing/ultimate/) (SaaS or Self-Managed), including 50,000 CI/CD minutes, for free to qualifying open source projects. GitLab Ultimate includes features that allow organization-wide security, compliance and planning. Some key features include:\n\n- [Multi-level Epics](https://docs.gitlab.com/ee/user/group/epics/)\n- [Portfolio-level Roadmaps](https://docs.gitlab.com/ee/user/group/roadmap/)\n- [Requirements Management](/direction/plan/#requirements-management)\n- [Compliance pipeline configuration](https://docs.gitlab.com/ee/user/project/settings/#compliance-pipeline-configuration)\n- [Chain of custody report](https://docs.gitlab.com/ee/user/compliance/compliance_report/#chain-of-custody-report)\n- [Vulnerability Database](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#contributing-to-the-vulnerability-database)\n- [Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/)\n- and much more...\n\nTo see a complete list of features, see our\n[Feature Comparison between tiers](/pricing/feature-comparison/) page. \n\n* Free top-tier accounts do not include support. However, you can purchase [support](/support/) for 95% off, at $4.95 per user per month.\n* Your program membership needs to be renewed annually. If you do not renew, [your account will be downgraded](/pricing/licensing-faq/#what-happens-when-my-subscription-is-about-to-expire-or-has-expired).\n* Acceptance into the GitLab for Open Source Program is at GitLab’s sole discretion, and we reserve the right to terminate the Program, or change the [Program requirements](/solutions/open-source/join/#requirements) at any time.\n\nIf you have any additional questions regarding this program, feel free to reach us at [opensource@gitlab.com](mailto:opensource@gitlab.com).\n\n## How to apply\n\n1. Set up a GitLab account. You’ll need to have a GitLab group already set up for your open source project or organization through a Free account or Free Trial. For help setting up a GitLab group, please see the relevant [FAQ](/solutions/open-source/join/#faqs). If you're considering a migration, you do not need to have finished the migration before applying to our program. You will need at least one project (repo) set up under your GitLab group to comply with our requirements.\n1. Take screenshots. During the application process, you’ll need to provide 3 screenshots of your project. We suggest taking them in advance, since you’ll need to submit them on page two of the application form.\n1. Fill out the [form](/solutions/open-source/join/#application) and submit it. \n\nApplications are reviewed and a response to your request can be expected within 10 business days. You may be asked to provide additional information.\n\nCover image by [Clay Banks](https://unsplash.com/photos/N3SsG7xR-Dg) on [Unsplash](https://unsplash.com)\n{: .note}\n",[682,9,775],{"slug":1725,"featured":6,"template":685},"ultimate-perks-for-open-source-projects","content:en-us:blog:ultimate-perks-for-open-source-projects.yml","Ultimate Perks For Open Source Projects","en-us/blog/ultimate-perks-for-open-source-projects.yml","en-us/blog/ultimate-perks-for-open-source-projects",{"_path":1731,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1732,"content":1738,"config":1744,"_id":1746,"_type":13,"title":1747,"_source":15,"_file":1748,"_stem":1749,"_extension":18},"/en-us/blog/updates-from-aws-reinvent",{"title":1733,"description":1734,"ogTitle":1733,"ogDescription":1734,"noIndex":6,"ogImage":1735,"ogUrl":1736,"ogSiteName":672,"ogType":673,"canonicalUrls":1736,"schema":1737},"Highlights from AWS re:Invent 2019","DevOps dining, selecting jukebox tunes, learning ‘Dog’Ops from Wag!, supporting Graviton, and more from AWS re:Invent 2019.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666262/Blog/Hero%20Images/default-blog-image.png","https://about.gitlab.com/blog/updates-from-aws-reinvent","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Highlights from AWS re:Invent 2019\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Tina Sturgis\"}],\n \"datePublished\": \"2019-12-13\",\n }",{"title":1733,"description":1734,"authors":1739,"heroImage":1735,"date":1741,"body":1742,"category":298,"tags":1743},[1740],"Tina Sturgis","2019-12-13","\n\nAWS re:Invent is both energizing and exhausting all at the same time. Come on... admit it, you think so too! But, it is actually one of my favorite events of the year. It is just me and approximately 65,000 of my best friends coming together to hear what AWS is up to and how it will effect GitLab and our joint users. \n\n\n## AWS announcements and how they relate to GitLab\n\n**Transformation.** I am a sucker for a transformation theme and AWS didn’t disappoint this year. Whether we are talking transformation personally or in our business, I can’t help but visualize a caterpillar transforming into a beautiful butterfly. \n\nAWS internally reflected as well as challenged their customers to think about “How should we reinvent ourselves?” In the [keynote with Andy Jassy](https://www.youtube.com/watch?v=7-31KgImGgU), Goldman Sachs, and Verizon each told their stories about transforming their business with AWS. While each story was a little different, they all talked about what they have accomplished with AWS. \n\nI sat back and reveled in the fact that the ‘untold’ story of [Goldman Sachs](/customers/goldman-sachs/) is that GitLab’s [DevOps platform](/solutions/devops-platform/) is used exclusively by their dev teams across the entire software development lifecycle. They have been able to remove toolchain complexity while going from providing a build once every two weeks to over a thousand per day. Talk about a transformation. Just imagine the velocity in their build cycle that they are able to achieve. \n\n**Amazon Fargate for Amazon EKS.**: Customers asked and AWS took action by launching Amazon Fargate for Amazon EKS. This is big news seeing that 84% of all Kubernetes installations run on AWS. So if you are looking to manage your containers at the task level, this announcement should have you dancing in your seat. Two out of five new container customers choose to start their container journey with Amazon Fargate, citing its overall ease of use. GitLab already supports Amazon Fargate and Amazon EKS, so it is very natural that we are excited about this new launch. Have a look at our [Trek10 customer case study](/customers/trek10/) to learn more about how it is using GitLab and Amazon Fargate today.\n\n**AWS Graviton**: AWS announced the next generation of Graviton with native runners for 32 and 64-bit ARM-based processors. GitLab already supports this service and our customers are already contributing.\n\n## WAG!’s phased approach to ‘Dog’Ops...errrrr DevOps \n\nDave Bullock from Wag! went through the first two phases of the transformation journey with both AWS and GitLab. Some of my favorite highlights from his talk, in his words, were:\n\n```\n“Automate all the things!”\n\n“We wanted Dev to work locally to test and monitor themselves so they take ownership.”\n\n“Everything as code! Code, not clicks!”\n\n“Everything is built into the pipeline...if something happens you can rollback at each step.”\n\n“Change is hard, things break! No one is perfect.”\n```\n\nWatch the full [Wag! story](https://youtu.be/HfEl9GXZC0s) from AWS re:Invent. \n\n\n\n## The importance of early security\n\n[Brandon Jung](/company/team/#bjung), our VP of alliances and board member at the Linux Foundation, sat down with Stu Miniman and John Walls, hosts of [theCUBE](https://www.thecube.net), to talk about how [GitLab empowers DevOps while making CISOs happy](https://siliconangle.com/2019/12/06/qa-gitlab-empowers-devops-making-cisos-happy-reinvent/). Brandon explained how GitLab users are able to include security earlier in the software development process, which saves them money because they're not iterating in the production phase.\n\nWatch [Brandon’s full interview](https://www.youtube.com/watch?v=Auua2qMYFOw).\n\n## Do you want to play a game?\n\nWe love games here at GitLab and were thrilled to be the featured SCM tool used in [AWS GameDay](https://aws.amazon.com/gameday/) at re:Invent this year. AWS GameDay is an interactive team-based learning exercise designed to give players a chance to put their AWS skills to the test in a real-world, gamified, risk-free environment. Expect to see us \"play\" a bigger role in AWS GameDay in 2020. \n\nThis year, the GitLab DevOps Diner-themed booth earned an honorable mention for the [best booth by AWS](https://twitter.com/AWSreInvent/status/1202735726153981953). Our corporate events team stayed laser-focused and each and every corner of the booth, including the swag, had the diner theme. My personal fav was the jams on the jukebox – I think this is a must-have in every one of our booths. We are already thinking about how to outdo the diner theme in 2020.\n\n![GitLab Diner at AWS](https://about.gitlab.com/images/blogimages/gitlabdiner.jpg){: .shadow.medium.center}\n\nLet’s keep the conversation going...what were your favorite parts at re:Invent this year? Comment here or ping me on Twitter @t_sturgis!\n",[266,9,817,276,726],{"slug":1745,"featured":6,"template":685},"updates-from-aws-reinvent","content:en-us:blog:updates-from-aws-reinvent.yml","Updates From Aws Reinvent","en-us/blog/updates-from-aws-reinvent.yml","en-us/blog/updates-from-aws-reinvent",{"_path":1751,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1752,"content":1758,"config":1766,"_id":1768,"_type":13,"title":1769,"_source":15,"_file":1770,"_stem":1771,"_extension":18},"/en-us/blog/why-we-spent-the-last-month-eliminating-postgresql-subtransactions",{"title":1753,"description":1754,"ogTitle":1753,"ogDescription":1754,"noIndex":6,"ogImage":1755,"ogUrl":1756,"ogSiteName":672,"ogType":673,"canonicalUrls":1756,"schema":1757},"Why we spent the last month eliminating PostgreSQL subtransactions","How a mysterious stall in database queries uncovered a performance limitation with PostgreSQL.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669470/Blog/Hero%20Images/nessie.jpg","https://about.gitlab.com/blog/why-we-spent-the-last-month-eliminating-postgresql-subtransactions","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Why we spent the last month eliminating PostgreSQL subtransactions\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Grzegorz Bizon\"},{\"@type\":\"Person\",\"name\":\"Stan Hu\"}],\n \"datePublished\": \"2021-09-29\",\n }",{"title":1753,"description":1754,"authors":1759,"heroImage":1755,"date":1762,"body":1763,"category":748,"tags":1764},[1760,1761],"Grzegorz Bizon","Stan Hu","2021-09-29","\nSince last June, we noticed the database on GitLab.com would\nmysteriously stall for minutes, which would lead to users seeing 500\nerrors during this time. Through a painstaking investigation over\nseveral weeks, we finally uncovered the cause of this: initiating a\nsubtransaction via the [`SAVEPOINT` SQL query](https://www.postgresql.org/docs/current/sql-savepoint.html) while\na long transaction is in progress can wreak havoc on database\nreplicas. Thus launched a race, which we recently completed, to\neliminate all `SAVEPOINT` queries from our code. Here's what happened,\nhow we discovered the problem, and what we did to fix it.\n\n### The symptoms begin\n\nOn June 24th, we noticed that our CI/CD runners service reported a high\nerror rate:\n\n![runners errors](https://about.gitlab.com/images/blogimages/postgresql-subtransactions/ci-runners-errors.png)\n\nA quick investigation revealed that database queries used to retrieve\nCI/CD builds data were timing out and that the unprocessed builds\nbacklog grew at a high rate:\n\n![builds queue](https://about.gitlab.com/images/blogimages/postgresql-subtransactions/builds-queue.png)\n\nOur monitoring also showed that some of the SQL queries were waiting for\nPostgreSQL lightweight locks (`LWLocks`):\n\n![aggregated lwlocks](https://about.gitlab.com/images/blogimages/postgresql-subtransactions/aggregated-lwlocks.png)\n\nIn the following weeks we had experienced a few incidents like this. We were\nsurprised to see how sudden these performance degradations were, and how\nquickly things could go back to normal:\n\n![ci queries latency](https://about.gitlab.com/images/blogimages/postgresql-subtransactions/ci-queries-latency.png)\n\n### Introducing Nessie: Stalled database queries\n\nIn order to learn more, we extended our observability tooling [to sample\nmore data from `pg_stat_activity`](https://gitlab.com/gitlab-cookbooks/gitlab-exporters/-/merge_requests/231). In PostgreSQL, the `pg_stat_activity`\nvirtual table contains the list of all database connections in the system as\nwell as what they are waiting for, such as a SQL query from the\nclient. We observed a consistent pattern: the queries were waiting on\n`SubtransControlLock`. Below shows a graph of the URLs or jobs that were\nstalled:\n\n![endpoints locked](https://about.gitlab.com/images/blogimages/postgresql-subtransactions/endpoints-locked.png)\n\nThe purple line shows the sampled number of transactions locked by\n`SubtransControlLock` for the `POST /api/v4/jobs/request` endpoint that\nwe use for internal communication between GitLab and GitLab Runners\nprocessing CI/CD jobs.\n\nAlthough this endpoint was impacted the most, the whole database cluster\nappeared to be affected as many other, unrelated queries timed out.\n\nThis same pattern would rear its head on random days. A week would pass\nby without incident, and then it would show up for 15 minutes and\ndisappear for days. Were we chasing the Loch Ness Monster?\n\nLet's call these stalled queries Nessie for fun and profit.\n\n### What is a `SAVEPOINT`?\n\nTo understand `SubtransControlLock` ([PostgreSQL\n13](https://www.postgresql.org/docs/13/monitoring-stats.html#MONITORING-PG-STAT-ACTIVITY-VIEW)\nrenamed this to `SubtransSLRU`), we first must understand how\nsubtransactions work in PostgreSQL. In PostgreSQL, a transaction can\nstart via a `BEGIN` statement, and a subtransaction can be started with\na subsequent `SAVEPOINT` query. PostgreSQL assigns each of these a\ntransaction ID (XID for short) [when a transaction or a subtransaction\nneeds one, usually before a client modifies data](https://gitlab.com/postgres/postgres/blob/a00c138b78521b9bc68b480490a8d601ecdeb816/src/backend/access/transam/README#L193-L198).\n\n#### Why would you use a `SAVEPOINT`?\n\nFor example, let's say you were running an online store and a customer\nplaced an order. Before the order is fullfilled, the system needs to\nensure a credit card account exists for that user. In Rails, a common\npattern is to start a transaction for the order and call\n[`find_or_create_by`](https://apidock.com/rails/v5.2.3/ActiveRecord/Relation/find_or_create_by). For\nexample:\n\n```ruby\nOrder.transaction do\n begin\n CreditAccount.transaction(requires_new: true) do\n CreditAccount.find_or_create_by(customer_id: customer.id)\n rescue ActiveRecord::RecordNotUnique\n retry\n end\n # Fulfill the order\n # ...\nend\n```\n\nIf two orders were placed around the same time, you wouldn't want the\ncreation of a duplicate account to fail one of the orders. Instead, you\nwould want the system to say, \"Oh, an account was just created; let me\nuse that.\"\n\nThat's where subtransactions come in handy: the `requires_new: true`\ntells Rails to start a new subtransaction if the application already is\nin a transaction. The code above translates into several SQL calls that\nlook something like:\n```sql\n--- Start a transaction\nBEGIN\nSAVEPOINT active_record_1\n--- Look up the account\nSELECT * FROM credit_accounts WHERE customer_id = 1\n--- Insert the account; this may fail due to a duplicate constraint\nINSERT INTO credit_accounts (customer_id) VALUES (1)\n--- Abort this by rolling back\nROLLBACK TO active_record_1\n--- Retry here: Start a new subtransaction\nSAVEPOINT active_record_2\n--- Find the newly-created account\nSELECT * FROM credit_accounts WHERE customer_id = 1\n--- Save the data\nRELEASE SAVEPOINT active_record_2\nCOMMIT\n```\n\nOn line 7 above, the `INSERT` might fail if the customer account was\nalready created, and the database unique constraint would prevent a\nduplicate entry. Without the first `SAVEPOINT` and `ROLLBACK` block, the\nwhole transaction would have failed. With that subtransaction, the\ntransaction can retry gracefully and look up the existing account.\n\n### What is `SubtransControlLock`?\n\nAs we mentioned earlier, Nessie returned at random times with queries\nwaiting for `SubtransControlLock`. `SubtransControlLock` indicates that\nthe query is waiting for PostgreSQL to load subtransaction data from\ndisk into shared memory.\n\nWhy is this data needed? When a client runs a `SELECT`, for example,\nPostgreSQL needs to decide whether each version of a row, known as a\ntuple, is actually visible within the current transaction. It's possible\nthat a tuple has been deleted or has yet to be committed by another\ntransaction. Since only a top-level transaction can actually commit\ndata, PostgreSQL needs to map a subtransaction ID (subXID) to its parent\nXID.\n\nThis mapping of subXID to parent XID is stored on disk in the\n`pg_subtrans` directory. Since reading from disk is slow, PostgreSQL\nadds a simple least-recently used (SLRU) cache in front for each\nbackend process. The lookup is fast if the desired page is already\ncached. However, as [Laurenz Albe discussed in his blog\npost](https://www.cybertec-postgresql.com/en/subtransactions-and-performance-in-postgresql/),\nPostgreSQL may need to read from disk if the number of active\nsubtransactions exceeds 64 in a given transaction, a condition\nPostgreSQL terms `suboverflow`. Think of it as the feeling you might get\nif you ate too many Subway sandwiches.\n\nSuboverflowing (is that a word?) can bog down performance because as\nLaurenz said, \"Other transactions have to update `pg_subtrans` to\nregister subtransactions, and you can see in the perf output how they\nvie for lightweight locks with the readers.\"\n\n### Hunting for nested subtransactions\n\nLaurenz's blog post suggested that we might be using too many\nsubtransactions in one transaction. At first, we suspected we might be\ndoing this in some of our expensive background jobs, such as project\nexport or import. However, while we did see numerous `SAVEPOINT` calls\nin these jobs, we didn't see an unusual degree of nesting in local\ntesting.\n\nTo isolate the cause, we started by [adding Prometheus metrics to track\nsubtransactions as a Prometheus metric by model](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/66477).\nThis led to nice graphs as the following:\n\n![subtransactions plot](https://about.gitlab.com/images/blogimages/postgresql-subtransactions/subtransactions-plot.png)\n\nWhile this was helpful in seeing the rate of subtransactions over time,\nwe didn't see any obvious spikes that occurred around the time of the\ndatabase stalls. Still, it was possible that suboverflow was happening.\n\nTo see if that was happening, we [instrumented our application to track\nsubtransactions and log a message whenever we detected more than 32\n`SAVEPOINT` calls in a given transaction](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67918). Rails\nmakes it possible for the application to subscribe to all of its SQL\nqueries via `ActiveSupport` notifications. Our instrumentation looked\nsomething like this, simplified for the purposes of discussion:\n\n```ruby\nActiveSupport::Notifications.subscribe('sql.active_record') do |event|\n sql = event.payload.dig(:sql).to_s\n connection = event.payload[:connection]\n manager = connection&.transaction_manager\n\n context = manager.transaction_context\n return if context.nil?\n\n if sql.start_with?('BEGIN')\n context.set_depth(0)\n elsif cmd.start_with?('SAVEPOINT', 'EXCEPTION')\n context.increment_savepoints\n elsif cmd.start_with?('ROLLBACK TO SAVEPOINT')\n context.increment_rollbacks\n elsif cmd.start_with?('RELEASE SAVEPOINT')\n context.increment_releases\n elsif sql.start_with?('COMMIT', 'ROLLBACK')\n context.finish_transaction\n end\nend\n```\n\nThis code looks for the key SQL commands that initiate transactions and\nsubtransactions and increments counters when they occurred. After a\n`COMMIT,` we log a JSON message that contained the backtrace and the\nnumber of `SAVEPOINT` and `RELEASES` calls. For example:\n\n```json\n{\n \"sql\": \"/*application:web,correlation_id:01FEBFH1YTMSFEEHS57FA8C6JX,endpoint_id:POST /api/:version/projects/:id/merge_requests/:merge_request_iid/approve*/ BEGIN\",\n \"savepoints_count\": 1,\n \"savepoint_backtraces\": [\n [\n \"app/models/application_record.rb:75:in `block in safe_find_or_create_by'\",\n \"app/models/application_record.rb:75:in `safe_find_or_create_by'\",\n \"app/models/merge_request.rb:1859:in `ensure_metrics'\",\n \"ee/lib/analytics/merge_request_metrics_refresh.rb:11:in `block in execute'\",\n \"ee/lib/analytics/merge_request_metrics_refresh.rb:10:in `each'\",\n \"ee/lib/analytics/merge_request_metrics_refresh.rb:10:in `execute'\",\n \"ee/app/services/ee/merge_requests/approval_service.rb:57:in `calculate_approvals_metrics'\",\n \"ee/app/services/ee/merge_requests/approval_service.rb:45:in `block in create_event'\",\n \"ee/app/services/ee/merge_requests/approval_service.rb:43:in `create_event'\",\n \"app/services/merge_requests/approval_service.rb:13:in `execute'\",\n \"ee/app/services/ee/merge_requests/approval_service.rb:14:in `execute'\",\n \"lib/api/merge_request_approvals.rb:58:in `block (3 levels) in \u003Cclass:MergeRequestApprovals>'\",\n ]\n \"rollbacks_count\": 0,\n \"releases_count\": 1\n}\n```\n\nThis log message contains not only the number of subtransactions via\n`savepoints_count`, but it also contains a handy backtrace that\nidentifies the exact source of the problem. The `sql` field also\ncontains [Marginalia comments](https://github.com/basecamp/marginalia)\nthat we tack onto every SQL query. These comments make it possible to\nidentify what HTTP request initiated the SQL query.\n\n### Taking a hard look at PostgreSQL\n\nThe new instrumentation showed that while the application regularly used\nsubtransactions, it never exceeded 10 nested `SAVEPOINT` calls.\n\nMeanwhile, [Nikolay Samokhvalov](https://gitlab.com/NikolayS), founder\nof [Postgres.ai](https://postgres.ai/), performed a battery of tests [trying to replicate the problem](https://gitlab.com/postgres-ai/postgresql-consulting/tests-and-benchmarks/-/issues/20).\nHe replicated Laurenz's results when a single transaction exceeded 64\nsubtransactions, but that wasn't happening here.\n\nWhen the database stalls occurred, we observed a number of patterns:\n\n1. Only the replicas were affected; the primary remained unaffected.\n1. There was a long-running transaction, usually relating to\nPostgreSQL's autovacuuming, during the time. The stalls stopped quickly after the transaction ended.\n\nWhy would this matter? Analyzing the PostgreSQL source code, Senior\nSupport Engineer [Catalin Irimie](https://gitlab.com/cat) [posed an\nintriguing question that led to a breakthrough in our understanding](https://gitlab.com/gitlab-org/gitlab/-/issues/338410#note_652056284):\n\n> Does this mean that, having subtransactions spanning more than 32 cache pages, concurrently, would trigger the exclusive SubtransControlLock because we still end up reading them from the disk?\n\n### Reproducing the problem with replicas\n\nTo answer this, Nikolay immediately modified his test [to involve replicas and long-running transactions](https://gitlab.com/postgres-ai/postgresql-consulting/tests-and-benchmarks/-/issues/21#note_653453774). Within a day, he reproduced the problem:\n\n![Nikolay experiment](https://about.gitlab.com/images/blogimages/postgresql-subtransactions/nikolay-experiment.png)\n\nThe image above shows that transaction rates remain steady around\n360,000 transactions per second (TPS). Everything was proceeding fine\nuntil the long-running transaction started on the primary. Then suddenly\nthe transaction rates plummeted to 50,000 TPS on the replicas. Canceling\nthe long transaction immediately caused the transaction rate to return.\n\n### What is going on here?\n\nIn his blog post, Nikolay called the problem [Subtrans SLRU overflow](https://v2.postgres.ai/blog/20210831-postgresql-subtransactions-considered-harmful#problem-4-subtrans-slru-overflow).\nIn a busy database, it's possible for the size of the subtransaction log\nto grow so large that the working set no longer fits into memory. This\nresults in a lot of cache misses, which in turn causes a high amount of\ndisk I/O and CPU as PostgreSQL furiously tries to load data from disk to\nkeep up with all the lookups.\n\nAs mentioned earlier, the subtransaction cache holds a mapping of the\nsubXID to the parent XID. When PostgreSQL needs to look up the subXID,\nit calculates in which memory page this ID would live, and then does a\nlinear search to find in the memory page. If the page is not in the\ncache, it evicts one page and loads the desired one into memory. The\ndiagram below shows the memory layout of the subtransaction SLRU.\n\n![Subtrans SLRU](https://about.gitlab.com/images/blogimages/postgresql-subtransactions/subtrans-slru.png)\n\nBy default, each SLRU page is an 8K buffer holding 4-byte parent\nXIDs. This means 8192/4 = 2048 transaction IDs can be stored in each\npage.\n\nNote that there may be gaps in each page. PostgreSQL will cache XIDs as\nneeded, so a single XID can occupy an entire page.\n\nThere are 32 (`NUM_SUBTRANS_BUFFERS`) pages, which means up to 65K\ntransaction IDs can be stored in memory. Nikolay demonstrated that in a\nbusy system, it took about 18 seconds to fill up all 65K entries. Then\nperformance dropped off a cliff, making the database replicas unusable.\n\nTo our surprise, our experiments also demonstrated that a single\n`SAVEPOINT` during a long-transaction [could initiate this problem if\nmany writes also occurred simultaneously](https://gitlab.com/gitlab-org/gitlab/-/issues/338865#note_655312474). That\nis, it wasn't enough just to reduce the frequency of `SAVEPOINT`; we had\nto eliminate them completely.\n\n#### Why does a single `SAVEPOINT` cause problems?\n\nTo answer this question, we need to understand what happens when a\n`SAVEPOINT` occurs in one query while a long-running transaction is\nrunning.\n\nWe mentioned earlier that PostgreSQL needs to decide whether a given row\nis visible to support a feature called [multi-version concurrency control](https://www.postgresql.org/docs/current/mvcc.html), or MVCC for\nshort. It does this by storing hidden columns, `xmin` and `xmax`, in\neach tuple.\n\n`xmin` holds the XID of when the tuple was created, and `xmax` holds the\nXID when it was marked as dead (0 if the row is still present). In\naddition, at the beginning of a transaction, PostgreSQL records metadata\nin a database snapshot. Among other items, this snapshot records the\noldest XID and the newest XID in its own `xmin` and `xmax` values.\n\nThis metadata helps [PostgreSQL determine whether a tuple is visible](https://www.interdb.jp/pg/pgsql05.html).\nFor example, a committed XID that started before `xmin` is definitely\nvisible, while anything after `xmax` is invisible.\n\n### What does this have to do with long transactions?\n\nLong transactions are bad in general because they can tie up\nconnections, but they can cause a subtly different problem on a\nreplica. On the replica, a single `SAVEPOINT` during a long transaction\ncauses a snapshot to suboverflow. Remember that dragged down performance\nin the case where we had more than 64 subtransactions.\n\nFundamentally, the problem happens because a replica behaves differently\nfrom a primary when creating snapshots and checking for tuple\nvisibility. The diagram below illustrates an example with some of the\ndata structures used in PostgreSQL:\n\n![Diagram of subtransaction handling in replicas](https://about.gitlab.com/images/blogimages/postgresql-subtransactions/pg-replica-subtransaction-diagram.png)\n\nOn the top of this diagram, we can see the XIDs increase at the\nbeginning of a subtransaction: the `INSERT` after the `BEGIN` gets 1,\nand the subsequent `INSERT` in `SAVEPOINT` gets 2. Another client comes\nalong and performs a `INSERT` and `SELECT` at XID 3.\n\nOn the primary, PostgreSQL stores the transactions in progress in a\nshared memory segment. The process array (`procarray`) stores XID 1 with\nthe first connection, and the database also writes that information to\nthe `pg_xact` directory. XID 2 gets stored in the `pg_subtrans`\ndirectory, mapped to its parent, XID 1.\n\nIf a read happens on the primary, the snapshot generated contains `xmin`\nas 1, and `xmax` as 3. `txip` holds a list of transactions in progress,\nand `subxip` holds a list of subtransactions in progress.\n\nHowever, neither the `procarray` nor the snapshot are shared directly\nwith the replica. The replica receives all the data it needs from the\nwrite-ahead log (WAL).\n\nPlaying the WAL back one entry at time, the replica populates a shared data\nstructure called `KnownAssignedIds`. It contains all the transactions in\nprogress on the primary. Since this structure can only hold a limited number of\nIDs, a busy database with a lot of active subtransactions could easily fill\nthis buffer. PostgreSQL made a design choice to kick out all subXIDs from this\nlist and store them in the `pg_subtrans` directory.\n\nWhen a snapshot is generated on the replica, notice how `txip` is\nblank. A PostgreSQL replica treats **all** XIDs as though they are\nsubtransactions and throws them into the `subxip` bucket. That works\nbecause if a XID has a parent XID, then it's a subtransaction. Otherwise, it's a normal transaction. [The code comments\nexplain the rationale](https://gitlab.com/postgres/postgres/blob/9f540f840665936132dd30bd8e58e9a67e648f22/src/backend/storage/ipc/procarray.c#L1665-L1681).\n\nHowever, this means the snapshot is missing subXIDs, and that could be\nbad for MVCC. To deal with that, the [replica also updates `lastOverflowedXID`](https://gitlab.com/postgres/postgres/blob/9f540f840665936132dd30bd8e58e9a67e648f22/src/backend/storage/ipc/procarray.c#L3176-L3182):\n\n```c\n * When we throw away subXIDs from KnownAssignedXids, we need to keep track of\n * that, similarly to tracking overflow of a PGPROC's subxids array. We do\n * that by remembering the lastOverflowedXID, ie the last thrown-away subXID.\n * As long as that is within the range of interesting XIDs, we have to assume\n * that subXIDs are missing from snapshots. (Note that subXID overflow occurs\n * on primary when 65th subXID arrives, whereas on standby it occurs when 64th\n * subXID arrives - that is not an error.)\n```\n\nWhat is this \"range of interesting XIDs\"? We can see this in [the code below](https://gitlab.com/postgres/postgres/blob/4bf0bce161097869be5a56706b31388ba15e0113/src/backend/storage/ipc/procarray.c#L1702-L1703):\n\n```c\nif (TransactionIdPrecedesOrEquals(xmin, procArray->lastOverflowedXid))\n suboverflowed = true;\n```\n\nIf `lastOverflowedXid` is smaller than our snapshot's `xmin`, it means\nthat all subtransactions have completed, so we don't need to check for\nsubtransactions. However, in our example:\n\n1. `xmin` is 1 because of the transaction.\n2. `lastOverflowXid` is 2 because of the `SAVEPOINT`.\n\nThis means `suboverflowed` is set to `true` here, which tells PostgreSQL\nthat whenever a XID needs to be checked, check to see if it has a parent\nXID. Remember that this causes PostgreSQL to:\n\n1. Look up the subXID for the parent XID in the SLRU cache.\n1. If this doesn't exist in the cache, fetch the data from `pg_trans`.\n\nIn a busy system, the requested XIDs could span an ever-growing range of\nvalues, which could easily exhaust the 64K entries in the SLRU\ncache. This range will continue to grow as long as the transaction runs;\nthe rate of increase depends on how many updates are happening on the\nprmary. As soon as the transaction terminates, the `suboverflowed` state\ngets set to `false`.\n\nIn other words, we've replicated the same conditions as we saw with 64\nsubtransactions, only with a single `SAVEPOINT` and a long transaction.\n\n### What can we do about getting rid of Nessie?\n\nThere are three options:\n\n1. Eliminate `SAVEPOINT` calls completely.\n1. Eliminate all long-running transactions.\n1. Apply [Andrey Borodin's patches to PostgreSQL and increase the subtransaction cache](https://www.postgresql.org/message-id/flat/494C5E7F-E410-48FA-A93E-F7723D859561%40yandex-team.ru#18c79477bf7fc44a3ac3d1ce55e4c169).\n\nWe chose the first option because most uses of subtransaction could be\nremoved fairly easily. There were a [number of approaches](https://gitlab.com/groups/gitlab-org/-/epics/6540) we took:\n\n1. Perform updates outside of a subtransaction. Examples: [1](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68471), [2](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68690)\n1. Rewrite a query to use a `INSERT` or an `UPDATE` with an `ON CONFLICT` clause to deal with duplicate constraint violations. Examples: [1](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68433), [2](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/69240), [3](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68509)\n1. Live with a non-atomic `find_or_create_by`. We used this approach sparingly. Example: [1](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68649)\n\nIn addition, we added [an alert whenever the application used a a single `SAVEPOINT`](https://gitlab.com/gitlab-com/runbooks/-/merge_requests/3881):\n\n![subtransaction alert](https://about.gitlab.com/images/blogimages/postgresql-subtransactions/subtransactions-alert-example.png)\n\nThis had the side benefit of flagging a [minor bug](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/70889).\n\n#### Why not eliminate all long-running transactions?\n\nIn our database, it wasn't practical to eliminate all long-running\ntransactions because we think many of them happened via [database\nautovacuuming](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html),\nbut [we're not able to reproduce this yet](https://gitlab.com/postgres-ai/postgresql-consulting/tests-and-benchmarks/-/issues/21#note_669698320).\nWe are working on partitioning the tables and sharding the database, but this is a much more time-consuming problem\nthan removing all subtransactions.\n\n#### What about the PostgreSQL patches?\n\nAlthough we tested Andrey's PostgreSQL patches, we did not feel comfortable\ndeviating from the official PostgreSQL releases. Plus, maintaining a\ncustom patched release over upgrades would add a significant maintenance\nburden for our infrastructure team. Our self-managed customers would\nalso not benefit unless they used a patched database.\n\nAndrey's patches do two main things:\n\n1. Allow administrators to change the SLRU size to any value.\n1. Adds an [associative cache](https://www.youtube.com/watch?v=A0vR-ks3hsQ).\nto make it performant to use a large cache value.\n\nRemember that the SLRU cache does a linear search for the desired\npage. That works fine when there are only 32 pages to search, but if you\nincrease the cache size to 100 MB the search becomes much more\nexpensive. The associative cache makes the lookup fast by indexing pages\nwith a bitmask and looking up the entry with offsets from the remaining\nbits. This mitigates the problem because a transaction would need to be\nseveral magnitudes longer to cause a problem.\n\nNikolay demonstrated that the `SAVEPOINT` problem disappeared as soon as\nwe increased the SLRU size to 100 MB with those patches. With a 100 MB\ncache, PostgreSQL can cache 26.2 million IDs (104857600/4), far more\nthan the measely 65K.\n\nThese [patches are currently awaiting review](https://postgres.ai/blog/20210831-postgresql-subtransactions-considered-harmful#ideas-for-postgresql-development),\nbut in our opinion they should be given high priority for PostgreSQL 15.\n\n### Conclusion\n\nSince removing all `SAVEPOINT` queries, we have not seen Nessie rear her\nhead again. If you are running PostgreSQL with read replicas, we\nstrongly recommend that you also remove *all* subtransactions until\nfurther notice.\n\nPostgreSQL is a fantastic database, and its well-commented code makes it\npossible to understand its limitations under different configurations.\n\nWe would like to thank the GitLab community for bearing with us while we\niron out this production issue.\n\nWe are also grateful for the support from [Nikolay\nSamokhvalov](https://gitlab.com/NikolayS) and [Catalin\nIrimie](https://gitlab.com/cat), who contributed to understanding where our\nLoch Ness Monster was hiding.\n\nCover image by [Khadi Ganiev](https://www.istockphoto.com/portfolio/Ganiev?mediatype=photography) on [iStock](https://istock.com), licensed under [standard license](https://www.istockphoto.com/legal/license-agreement)\n",[1765,9,1077],"performance",{"slug":1767,"featured":6,"template":685},"why-we-spent-the-last-month-eliminating-postgresql-subtransactions","content:en-us:blog:why-we-spent-the-last-month-eliminating-postgresql-subtransactions.yml","Why We Spent The Last Month Eliminating Postgresql Subtransactions","en-us/blog/why-we-spent-the-last-month-eliminating-postgresql-subtransactions.yml","en-us/blog/why-we-spent-the-last-month-eliminating-postgresql-subtransactions",{"_path":1773,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1774,"content":1780,"config":1785,"_id":1787,"_type":13,"title":1788,"_source":15,"_file":1789,"_stem":1790,"_extension":18},"/en-us/blog/why-were-sticking-with-ruby-on-rails",{"title":1775,"description":1776,"ogTitle":1775,"ogDescription":1776,"noIndex":6,"ogImage":1777,"ogUrl":1778,"ogSiteName":672,"ogType":673,"canonicalUrls":1778,"schema":1779},"Why we're sticking with Ruby on Rails","GitLab CEO and co-founder Sid Sijbrandij makes the case for Ruby on Rails.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668296/Blog/Hero%20Images/gitlab-ruby.jpg","https://about.gitlab.com/blog/why-were-sticking-with-ruby-on-rails","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Why we're sticking with Ruby on Rails\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Sid Sijbrandij\"}],\n \"datePublished\": \"2022-07-06\",\n }",{"title":1775,"description":1776,"authors":1781,"heroImage":1777,"date":1782,"body":1783,"category":1033,"tags":1784},[722],"2022-07-06","\nWhen David Heinemeier Hansson created Ruby on Rails ([interview](https://corecursive.com/045-david-heinemeier-hansson-software-contrarian/)), he was guided by his experience with both PHP and Java. On the one hand, he didn’t like the way the verbosity and rigidness of Java made Java web frameworks complex and difficult to use, but appreciated their structural integrity. On the other hand, he loved the initial approachability of PHP, but was less fond of the quagmires that such projects tended to turn into.\n\n![Ruby vs. Java](https://about.gitlab.com/images/blogimages/ruby1.png)\n\nIt seems like these are exclusive choices: You either get approachable and messy or well-structured and hard to use, pick your poison. We used to make a very similar, and similarly hard, distinction between server-class operating systems such as Unix, which were stable but hard to use, and client operating systems such as Windows and MacOS that were approachable but crashed a lot.\n\nEveryone accepted this dichotomy as God-given until NeXT put a beautiful, approachable and buttery-smooth GUI on top of a solid Unix base. Nowadays, “server-class” Unix runs not just beautiful GUI desktops, but also most phones and smart watches.\n\nSo it turned out that approachability and crashiness were not actually linked except by historical accident, and the same turns out to be true for approachability and messiness in web frameworks: They are independent axes.\n\n![approachability and messiness](https://about.gitlab.com/images/blogimages/ruby2.png)\n\nAnd these independent axes opened up a very desirable open spot in the lower right hand corner: an approachable, well-structured web framework.\nWith its solid, metaprogrammable Smalltalk heritage and good Unix integration, Ruby proved to be the perfect vehicle for DHH to fill that desirable bottom right corner of the table with Rails: an extremely approachable, productive and well-structured web framework. \n\n![a well-structured framework](https://about.gitlab.com/images/blogimages/ruby3.png)\n \nWhen GitLab co-founder Dmitriy Zaporozhets decided he wanted to work on software for running his (and your) version control server, he also came from a PHP background. But instead of sticking with the familiar, he chose Rails. Dmitry's choice may have been prescient or fortuitous, but it has served GitLab extremely well, in part because David succeeded in achieving his goals for Rails: approachability with good architecture.\n\n## Why modular?\n\nIn the preceding section, it was assumed as a given that modularity is a desirable property, but as we also saw it is dangerous to just assume things. So why, and in what contexts, is modularity actually desirable?\n\nIn his 1971 paper [\"On the Criteria to be Used in Decomposing Systems into Modules\"](https://prl.ccs.neu.edu/img/p-tr-1971.pdf), David L. Parnas gave the following (desired) benefits of a modular system:\n\n- Development time should “be shortened because separate groups would work on each module with little need for communication.”\n- It should be possible to make “drastic changes or improvements in one module without changing others.”\n- It should be possible to study the system one module at a time.\n\nThe importance of reducing the need for communication was later highlighted by Fred Brooks in _[The Mythical Man Month](https://en.wikipedia.org/wiki/The_Mythical_Man-Month)_, with the additional communication overhead one of the primary reasons for the old saying that \"adding people to a late software project makes it later.\" \n\n## We don’t need microservices\n\nModularity has generally been as elusive as it is highly sought after, with the default architecture of most systems being the [Big Ball of Mud](http://laputan.org/mud/). It is therefore understandable that designers took inspiration from arguably the largest software system in existence: the World Wide Web, which is modular by necessity, it cannot function any other way.\n\nOrganizing your local software systems using separate processes, microservices that are combined using [REST](https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf) architectural style does help enforce module boundaries, via the operating system, but comes at significant costs. It is a very heavy-handed approach for achieving modularity.\n\nThe difficulties and costs of running what is now a gratuitously distributed system are significant, with some of the performance and reliability issues documented in the well-known [fallacies of distributed computing](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing). In short, the performance and reliability costs are significant, as function calls that take nanoseconds and never fail are replaced with network ops that are three to six orders of magnitude slower and do fail. Failures become much harder to diagnose if they must be traced across multiple services with very little tooling support.\nYou need a fairly sophisticated DevOps organization to successfully run microservices. This doesn't really make a difference if you run at a scale that requires that sophistication anyhow, but it is very likely that [you are not Google](https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb?gi=1b82f8ef279a).\n\nBut even if you think you can manage all that, it is important to note that all this accidental complexity is on top of the original essential complexity of your problem, microservices do nothing to reduce complexity. And even the hoped-for modularity improvements are not in the least guaranteed, typically what happens instead is that you get a [distributed ball of mud](http://www.codingthearchitecture.com/2014/07/06/distributed_big_balls_of_mud.html).\n\n## Monorails\n\nBy making good architecture approachable and productive, Rails has allowed GitLab to develop a [modular monolith](https://medium.com/@dan_manges/the-modular-monolith-rails-architecture-fb1023826fc4). A modular monolith is the exact opposite of a distributed ball of mud: a well-structured, well-architected, highly modular program that runs as a single process and is as [boring](https://handbook.gitlab.com/handbook/values/#boring-solutions) as possible.\n\nAlthough structuring GitLab as a monolith has been extremely beneficial for us, we are not dogmatic about that structure. Architecture follows needs, not the other way around. And while Rails is excellent technology for our purposes, it does have a few drawbacks, one of them being performance. Luckily, only a tiny part of most codebases is actually performance critical. We use our own [gitaly](https://www.google.com/url?q=https://docs.gitlab.com/ee/administration/gitaly/&sa=D&source=docs&ust=1656441057979077&usg=AOvVaw11r4iMGjvs6PrtTJEkeTbO) daemon written in Go to handle actual git operations, and [PostgreSQL](https://thenewstack.io/two-sizes-fit-most-postgresql-and-clickhouse/) for non-repository persistence.\n\n## Open Core\n\nLast but not least, our modular monolith turns [our](/blog/gitlab-is-open-core-github-is-closed-source/) [Open Core](https://en.wikipedia.org/wiki/Open-core_model) business model from being just a nice theory into a practical [reality](https://www.cnbc.com/2021/10/14/gitlab-jumps-in-nasdaq-debut-after-pricing-ipo-above-expected-range.html). Although Rails does not accomplish this by itself, that would be our wonderful contributors and engineers, it does lay the proper foundations.\n\nIn order to reap the true [benefits](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar) of open source, the source code that is made available must be approachable for contributors. In order to maintain architectural integrity in the face of contributions from a wide variety of sources, and to keep a clear demarcation line between the open and closed components, the code must be very well structured. Sound familiar?\n\nWouldn’t it be better to have a proper plugin interface? Or better yet, a services interface modeled on microservices? In a word: no. Not only do these approaches impose deployment and integration hurdles that go far beyond “I made a small change to the source code,\" they often enforce architectural constraints too rigidly. Anticipating all the future extension points is a fool's errand, one that we luckily did not embark on, and do not have to.\n\nWith our boring modular monolith, users and other third-party developers can and do contribute enhancements to the core product, giving us tremendous leverage, coupled with an unbeatable pace and scalability of innovation.\n",[775,682,9],{"slug":1786,"featured":6,"template":685},"why-were-sticking-with-ruby-on-rails","content:en-us:blog:why-were-sticking-with-ruby-on-rails.yml","Why Were Sticking With Ruby On Rails","en-us/blog/why-were-sticking-with-ruby-on-rails.yml","en-us/blog/why-were-sticking-with-ruby-on-rails",{"_path":1792,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1793,"content":1799,"config":1804,"_id":1806,"_type":13,"title":1807,"_source":15,"_file":1808,"_stem":1809,"_extension":18},"/en-us/blog/wrapping-up-commit",{"title":1794,"description":1795,"ogTitle":1794,"ogDescription":1795,"noIndex":6,"ogImage":1796,"ogUrl":1797,"ogSiteName":672,"ogType":673,"canonicalUrls":1797,"schema":1798},"Wrapping up GitLab Commit","From bagels to bowling with a healthy dose of DevSecOps and CI/CD in between, it was an epic day of learning and sharing at GitLab Commit Brooklyn.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680823/Blog/Hero%20Images/commit-brooklyn-graffiti-cover.jpg","https://about.gitlab.com/blog/wrapping-up-commit","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"Wrapping up GitLab Commit\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Valerie Silverthorne\"}],\n \"datePublished\": \"2019-09-18\",\n }",{"title":1794,"description":1795,"authors":1800,"heroImage":1796,"date":1801,"body":1802,"category":298,"tags":1803},[834],"2019-09-18","\n\n***Relive GitLab Commit Brooklyn through the power of lights, cameras, and a pinch of Tanuki magic. Here's the [full YouTube playlist for the event](https://www.youtube.com/playlist?list=PLFGfElNsQthaaqEAb6ceZvYnZgzSM50Kg)!***\n\nIf there's anything you need to understand about GitLab's first ever user conference, it's this: I started the day with a New York bagel, learned how to create a CI/CD pipeline in just 20 minutes, found out [NASA will take GitLab into space](/blog/open-source-nasa-gl/), and it ended in a bowling alley... yes, it was _that_ kind of day.\n\nWe did a neighborhood takeover of a few blocks in the Williamsburg area of Brooklyn and before I even arrived at the venue, I knew something interesting was happening. There was wall grafitti and street graffiti.\n\n![street graffiti](https://about.gitlab.com/images/blogimages/commitbrooklynstreet.jpg){: .shadow.small.center}\nGitLab has arrived in Brooklyn!\n{: .note.text-center}\n\nOver 400 attendees gathered in brick-and-light-filled meeting spaces for conversation, demonstrations, laughter, and even a screaming chicken (the result of the CI/CD demo). It was an epic day of sharing, learning and exploring that could have felt overwhelming. Instead, the quirky informal spaces seemed to relax everyone and make it easier to actually listen and learn.\n\n{::options parse_block_html=\"false\" /}\n\n\u003Cdiv class=\"center\">\n\n \u003Cblockquote class=\"twitter-tweet\" data-partner=\"tweetdeck\">\u003Cp lang=\"en\" dir=\"ltr\">THE live coding keynote is here! \u003Ca href=\"https://twitter.com/eddiezane?ref_src=twsrc%5Etfw\">@eddiezane\u003C/a> of \u003Ca href=\"https://twitter.com/digitalocean?ref_src=twsrc%5Etfw\">@digitalocean\u003C/a> introduces his “startup” Screaming Chicken at \u003Ca href=\"https://twitter.com/hashtag/GitLabCommit?src=hash&ref_src=twsrc%5Etfw\">#GitLabCommit\u003C/a> and shows how he runs it on \u003Ca href=\"https://twitter.com/gitlab?ref_src=twsrc%5Etfw\">@GitLab\u003C/a> AutoDevops, \u003Ca href=\"https://twitter.com/hashtag/Kubernetes?src=hash&ref_src=twsrc%5Etfw\">#Kubernetes\u003C/a> and DO. The audience is riveted! \u003Ca href=\"https://t.co/ibao6ngeNX\">pic.twitter.com/ibao6ngeNX\u003C/a>\u003C/p>— Priyanka Sharma @ #GitLabCommit Brooklyn! (@pritianka) \u003Ca href=\"https://twitter.com/pritianka/status/1173972101713276928?ref_src=twsrc%5Etfw\">September 17, 2019\u003C/a>\u003C/blockquote>\n \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\nThis was not anyone's typical idea of a user conference: no large, impersonal hotel, no pre-fab food, and no stilted conversations with total strangers. No one spent the day in frigid air conditioning. Instead everyone moved seamlessly from space to space, inside and outside, and it really was refreshing.\n\nLunch was refreshing too. It's not every day a gorilla brings you grilled cheese and tater tots under sunny skies.\n\n![Gorilla Grilled Cheese](https://about.gitlab.com/images/blogimages/commitbrooklyngorilla.jpg){: .shadow.small.center}\nThis was some grilled cheese!\n{: .note.text-center}\n\nAfter lunch, some people met up with our CEO [Sid Sijbrandij](/company/team/#sytses) while others attended individual tracks.\n\n![Office hours with Sid](https://about.gitlab.com/images/blogimages/commitbrooklynsid.jpg){: .shadow.small.center}\nMeet the CEO!\n{: .note.text-center}\n\nAn open coffee and tea bar (we took over the local coffee shop and my iced chai latte was delicious) fueled lots of conversations about the challenges we all face around DevOps.\n\n![iced chai](https://about.gitlab.com/images/blogimages/commitbrooklynchai.jpg){: .shadow.small.center}\nCheers!\n{: .note.text-center}\n\nAnd then it was time to, well, bowl.\n\n![Bowling](https://about.gitlab.com/images/blogimages/commitbrooklynbowling.jpg){: .shadow.small.center}\nGitLab at Brooklyn Bowl\n{: .note.text-center}\n\nIt might be bragging, but we really do throw a great party (and user conference, for that matter).\n\nIf you'd like to see for yourself, you'll have another chance to network with others on the same DevOps journey. Get your tickets to [Commit London on October 9](/events/commit/#). You can also read about news from Commit: [$268 million in Series E funding, new partners, and more](/blog/live-from-commit-news/), and check out the highlight reel below:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n \u003Ciframe src=\"https://www.youtube.com/embed/hi2D0Se_VnA\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n\u003C%= partial \"includes/blog/blog-merch-banner\" %>\n",[108,9,276,860,1077],{"slug":1805,"featured":6,"template":685},"wrapping-up-commit","content:en-us:blog:wrapping-up-commit.yml","Wrapping Up Commit","en-us/blog/wrapping-up-commit.yml","en-us/blog/wrapping-up-commit",{"_path":1811,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1812,"content":1817,"config":1824,"_id":1826,"_type":13,"title":1827,"_source":15,"_file":1828,"_stem":1829,"_extension":18},"/en-us/blog/you-are-hired-two-gitlab-contributors-turn-their-success-into-full-time-engineering-roles",{"title":1813,"description":1814,"ogTitle":1813,"ogDescription":1814,"noIndex":6,"ogImage":1024,"ogUrl":1815,"ogSiteName":672,"ogType":673,"canonicalUrls":1815,"schema":1816},"How contributors earned full-time engineering roles at GitLab","As we continue to celebrate the 10th anniversary of the first commit to GitLab, here's a look at how two highly active community members became enthusiastic team members.","https://about.gitlab.com/blog/you-are-hired-two-gitlab-contributors-turn-their-success-into-full-time-engineering-roles","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"You're hired! Two GitLab contributors turn their success into full-time engineering roles\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"GitLab\"}],\n \"datePublished\": \"2021-11-12\",\n }",{"title":1818,"description":1814,"authors":1819,"heroImage":1024,"date":1821,"body":1822,"category":1033,"tags":1823},"You're hired! Two GitLab contributors turn their success into full-time engineering roles",[1820],"GitLab","2021-11-12","[Greg Myers](https://gitlab.com/greg) and [Rajendra Kadam](https://gitlab.com/rkadam3) have something beyond their engineering roles at GitLab in common – both started out as GitLab contributors. We wanted to share their stories as part of our celebration around the 10th anniversary of the first commit to GitLab.\n\nMyers, a GitLab Senior Support Engineer, says his contributions started in 2018, when he first found his passion for helping other community forum members. \n\n“Most of my early contributions involved helping people set up, configure, and troubleshoot self-hosted GitLab installations,” Myers says.\n\nHe enjoyed this helper role so much he applied for an engineering position, but failed the technical interview and didn’t receive an offer. “I kept contributing to GitLab and helping others in the forum while I leveled up in my weak areas,” he says.\n\nKadam, a GitLab Back-end Engineer and [GitLab hero](/community/heroes/members/), started contributing to GitLab in Jan 2020 to learn more about Ruby on Rails and apply it to his then-workplace. \n\n“I did not stop after that since it is more than the code. I loved working with people at GitLab and the culture, even though I was not a full-time team member,” Kadam says.\n\nLike Kadam, Myers enjoyed being a part of the GitLab community. “The majority of my ‘code’ contributions back then were quite simple – fixing typos and markdown formatting issues in documentation,” he says. “I'd never contributed to an open source project of this size and caliber, and I was impressed by how easy and smooth it was to get involved and contribute.”\n\nHe remembers feeling “star-struck” when GitLab co-founder Dmitriy Zaporozhets personally responded in the comments to one of his first MRs.\n\nUsing what he learned as a contributor, Kadam earned a promotion from his employer. He went on to participate in [GitLab hackathons](/community/hackathon/), winning three in a series. His prominence in the GitLab community led him to be offered and to accept an internal engineering role in February 2021. Kadam blogged about the journey from being a contributor to a team member [on Medium](https://rajendraak.medium.com/how-i-got-a-job-at-gitlab-a3515214b74b).\n\nMyers, meanwhile, feeling more confident about his skills, took another shot at a team member role. “After four months, I reapplied for the support engineer position, and this time I got the job. Now it is my job to help others with GitLab and contribute to GitLab, and I love what I do,” Myers says.\n\nAs a Developer Relations Support counterpart, he helps others in the GitLab community forum and advocates for the GitLab wider community. And, as a GitLab Open Source Support Liaison, “I give back to open source communities I know and love,” he says.\n\nHe encourages others to not only contribute to the GitLab community but to help other forum members as he did. After all, you never know where those contributions can lead. “Being a GitLab community member and contributor led me to my dream job,” he says.",[775,9,728],{"slug":1825,"featured":6,"template":685},"you-are-hired-two-gitlab-contributors-turn-their-success-into-full-time-engineering-roles","content:en-us:blog:you-are-hired-two-gitlab-contributors-turn-their-success-into-full-time-engineering-roles.yml","You Are Hired Two Gitlab Contributors Turn Their Success Into Full Time Engineering Roles","en-us/blog/you-are-hired-two-gitlab-contributors-turn-their-success-into-full-time-engineering-roles.yml","en-us/blog/you-are-hired-two-gitlab-contributors-turn-their-success-into-full-time-engineering-roles",{"_path":1831,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1832,"content":1838,"config":1845,"_id":1847,"_type":13,"title":1848,"_source":15,"_file":1849,"_stem":1850,"_extension":18},"/en-us/blog/13-0-contributor-experience-update",{"title":1833,"description":1834,"ogTitle":1833,"ogDescription":1834,"noIndex":6,"ogImage":1835,"ogUrl":1836,"ogSiteName":672,"ogType":673,"canonicalUrls":1836,"schema":1837},"13.0 Contributor Experience Update","We're continually improving the tooling that helps our community of contributors build GitLab. Here's what's new over the last month!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669604/Blog/Hero%20Images/tanuki-bg-sm.gif","https://about.gitlab.com/blog/13-0-contributor-experience-update","\n {\n \"@context\": \"https://schema.org\",\n \"@type\": \"Article\",\n \"headline\": \"13.0 Contributor Experience Update\",\n \"author\": [{\"@type\":\"Person\",\"name\":\"Patrick Deuley\"},{\"@type\":\"Person\",\"name\":\"Taurie Davis\"}],\n \"datePublished\": \"2020-06-01\",\n }",{"title":1833,"description":1834,"authors":1839,"heroImage":1835,"date":1842,"body":1843,"category":1625,"tags":1844},[1840,1841],"Patrick Deuley","Taurie Davis","2020-06-01","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nThe Ecosystem group is the home of the [Pajamas Design System](https://design.gitlab.com) and the [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit). Our job is to help you as a contributor work on GitLab, whether that's writing backend code, creating awesome new features in our UI, or testing feature branches to validate new work that's about to go in.\n\nThis is a collection of all the updates from the last month, including changes to Pajamas, new components in GitLab UI, new icons, new commands in the GDK, and more! Check it out below, and as always, please feel free to send us issues for new things we could improve or add. You can also find us in [#g_ecosystem](https://gitlab.slack.com/archives/CK4Q4709G) (for general inquiries), [#g_manage_foundations](https://gitlab.slack.com/archives/C010NAWPRV4) (for Pajamas and GitLab-UI), or [#gdk](https://gitlab.slack.com/archives/C2Z9A056E). 🎉\n\n\n## Pajamas\n\n* We introduced [semantic releases](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/1866) and [conventional commits](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/1863). \n* We updated our [component status table](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/1878) to include different touchpoints. This includes Figma, Usage docs, Vue docs, GitLab UI state, and Accessibility audit statuses.\n\n## Usage guidelines\n\n* We added first usage guideline iterations for [Progress Bars](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/1886) and [File Uploaders](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/1799).\n* We also clarified the [position of buttons in alerts](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/1889), as well as added [dismissal guidelines for banners](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/1893).\n* We introduced documentation for our new [data visualization color palette](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/1831).\n\n_[Check out the changelog](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/blob/main/CHANGELOG.md) for more improvements._\n\n## GitLab UI\n\n* Within GitLab UI, we introduced [UX Reviewers](https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/1358) to our review roulette bot.\n* We also started laying the foundation for using GitLab UI in our Docs as part of our [Beautifying the Docs](https://gitlab.com/groups/gitlab-org/-/epics/3063) effort.\n\n## Component updates\n\n* Our [markdown typescale](https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/1201) is now viewable with compact markdown coming soon.\n* We've [removed the documentation link from scoped labels](https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/1259), [standardized alert styling](https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/1344), added [filters](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/1897) as built and ready to use, fixed [dropdown styles](https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/1322), and introduced the [loading button](https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/1308). We also clarified that [filter and sorting functionality shouldn't be combined in the same component](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/1879).\n\n_[Check out the changelog](https://gitlab.com/gitlab-org/gitlab-ui/-/blob/master/CHANGELOG.md) for more improvements._\n\n## Figma migration\n\n* New components have been added to Figma!\n * [Token](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/1917)\n * [Sorting](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/1890)\n * [Tree](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/1896)\n* We [deprecated the Sketch UI Kit](https://gitlab.com/gitlab-org/gitlab-design/-/merge_requests/243) in favor of the [Pajamas UI Kit](https://www.figma.com/community/file/781156790581391771) in Figma. We also determined [Project and Team library structure in Figma](https://gitlab.com/gitlab-org/gitlab-design/-/merge_requests/247/diffs) and added [guidance on collaborating within Figma vs. GitLab's Design Management](https://gitlab.com/gitlab-org/gitlab-design/-/merge_requests/248)\n\n# Icons\n\n* Issue templates for adding new [icons](https://gitlab.com/gitlab-org/gitlab-svgs/-/merge_requests/539) and [illustrations](https://gitlab.com/gitlab-org/gitlab-svgs/-/merge_requests/541) have been moved from [GitLab Design](https://gitlab.com/gitlab-org/gitlab-design) to [GitLab SVGs](https://gitlab.com/gitlab-org/gitlab-svgs).\n* The following icons were added to GitLab SVG:\n * [Project, group, and subgroup](https://gitlab.com/gitlab-org/gitlab-svgs/-/merge_requests/562)\n * [Expire](https://gitlab.com/gitlab-org/gitlab-svgs/-/merge_requests/564)\n * [Container image](https://gitlab.com/gitlab-org/gitlab-svgs/-/merge_requests/566)\n\n# GDK\n\n* [GDK doctor](https://gitlab.com/gitlab-org/gitlab-development-kit/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name[]=gdk-doctor&milestone_title=13.0) now checks a bunch of Ruby gems that have C extensions that are known to cause issues\n* There's [a new `quiet` mode](https://gitlab.com/gitlab-org/gitlab-development-kit/-/merge_requests/1267) that reduces the \"noise\" during the bundle installation. This should make it more obvious when actionable things happen. Try it out and let us know if this is helpful!\n\n## Documentation\n* We added some [general commands](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/master/doc/troubleshooting.md#troubleshooting) that are good to know when troubleshooting GDK errors.\n* We've [restructured the documentation](https://gitlab.com/gitlab-org/gitlab-development-kit/-/tree/master/doc) to make it easier to navigate! This includes moving non-core content into `doc/howto` to centralize specific how to docs in one place.\n* There were also [24 other documentation improvements](https://gitlab.com/gitlab-org/gitlab-development-kit/-/merge_requests?scope=all&utf8=%E2%9C%93&state=merged&label_name[]=documentation&milestone_title=13.0)!! 🎉\n* [YARD documentation](https://gitlab.com/gitlab-org/gitlab-development-kit/-/merge_requests/1213) is now automatically generated and accessible at https://gitlab-org.gitlab.io/gitlab-development-kit/\n* [Webpack is now able to be run in different modes](https://gitlab.com/gitlab-org/gitlab-development-kit/-/merge_requests/1201/)\n* There's now a doc on how to [configure a hosted Grafana instance](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/master/doc/howto/prometheus/third_party_access.md#configuring-a-hosted-grafana-instance)\n\n## CI\n - All [shell scripts](https://gitlab.com/gitlab-org/gitlab-development-kit/-/merge_requests/1190) within the project are now checked\n - Documentation linted even further with the [introduction of Vale](https://gitlab.com/gitlab-org/gitlab-development-kit/-/merge_requests/1193)\n - Ruby code is now [checked with RuboCop](https://gitlab.com/gitlab-org/gitlab-development-kit/-/merge_requests/1206)\n - CI config was [split up into templates](https://gitlab.com/gitlab-org/gitlab-development-kit/-/merge_requests/1229)\n - CI jobs are now [interruptible by default](https://gitlab.com/gitlab-org/gitlab-development-kit/-/merge_requests/1256)\n\n## Misc\n - [Sidekiq logging now JSON by default](https://gitlab.com/gitlab-org/gitlab-development-kit/-/merge_requests/1198)\n\n",[9,774,1546],{"slug":1846,"featured":6,"template":685},"13-0-contributor-experience-update","content:en-us:blog:13-0-contributor-experience-update.yml","13 0 Contributor Experience Update","en-us/blog/13-0-contributor-experience-update.yml","en-us/blog/13-0-contributor-experience-update",7,[665,690,712,735,759,782,804,824,844],1753981655802]