marketing VS tech-evangelism

GitLab team member here. Thanks for flagging.

Our web team is working to resolve this issue here: https://gitlab.com/gitlab-com/marketing/digital-experience/b...

> Having a web-based IDE is great for newcomers and will work on cheap Chromebooks or iPads

Good call, thanks. GitLab team member here.

From my experience as GitLab trainer in my past job, a web frontend to edit files hides the complexity of Git on the CLI, and helps with the "5 min success" to get going and learning. This can help with team member onboarding, as well as OSS projects looking for contributors.

Combined with CI/CD pipeline feedback in the same interface, without context switches, it makes the learning story easier to follow too.

The first workshops to get started with GitLab CI/CD from 2 years ago, are linked in the documentation, and use the Web IDE. [0] Seen great learning curves from the wider community :-) Taking a note to create a new workshop with the new IDE in the future. [1]

[0] https://docs.gitlab.com/ee/ci/quick_start/

[1] https://gitlab.com/gitlab-com/marketing/corporate_marketing/...

Thank you for the great thoughts :)

> And maybe only cache the downloads on the main branch.

$CI_COMMIT_REF_SLUG resolves into the branch when executed in a pipeline. Using it as value for the cache key, Git branches (and related MRs) use different caches. It can be one way to avoid collision but requires more storage with multiple caches. https://docs.gitlab.com/ee/ci/variables/predefined_variables...

In general, I agree, the more caches and parallel execution you add, the more complex and error prone it can get. Simulating a pipeline with runtime requirements like network & caches needs its own "staging" env for developing pipelines. That's a scenario not many have, or might be willing to assign resources onto. Static simulation where you predict the building blocks from the yaml config, is something GitLab's pipeline authoring team is working on in https://gitlab.com/groups/gitlab-org/-/epics/6498

And it is also a matter of insights and observability - the critical path in the pipeline has a long max duration, where do you start analysing and how do you prevent this scenario from happening again. Monitoring with the GitLb CI Pipeline Exporter for Prometheus is great, another way of looking into CI/CD pipelines can be tracing.

CI/CD Tracing with OpenTelemetry is discussed in https://gitlab.com/gitlab-org/gitlab/-/issues/338943 to learn about user experiences, and define the next steps. Imho a very hot topic, seeing more awareness for metrics and traces from everyone. Like, seeing the full trace for pipeline from start to end with different spans inside, and learning that the container image pull takes a long time. That can be the entry point into deeper analysis.

Another idea is to make app instrumentation easier for developers, providing tips for e.g. adding /metrics as an http endpoint using Prometheus and OpenTelemetry client libraries. That way you not only see the CI/CD infrastructure & pipelines, but also user side application performance monitoring and beyond in distributed environments. I'm collecting ideas for blog posts in https://gitlab.com/gitlab-com/marketing/corporate_marketing/...

For someone starting with pipeline efficiency tasks, I'd recommend setting a goal - like shown in the blog post X minutes down to Y - and then start with analysing to get an idea about the blocking parts. Evaluate and test solutions for each part, e.g. a terraform apply might depend on AWS APIs, whereas a Docker pull could be switched to use the Dependency proxy in GitLab for caching.

Each environment has different requirements - collect helpful resources from howtos, blog posts, docs, HN threads, etc. and also ask the community about their experience. https://forum.gitlab.com/ is a good spot too. Recommend to create an example project highlighting the pipeline, and allowing everyone to fork, analyse, add suggestions.

Good morning HN. I am the DRI (directly responsible individual) for about.gitlab.com and I have created this issue to audit our trackers, cookies, and other data collection on the marketing website https://gitlab.com/gitlab-com/marketing/inbound-marketing/ma...

Our product does not include the tracking that is used on the marketing site.

Hi,

> This was not a poor accident by a single employee. It's noble that the author tries to take all the blame on himself, but honestly, I feel like that is a moment where a leader has to step in and accept their mistake and not let a small trooper eat all the bullets.

The issues you have found are all assigned to me, or I created them. My task is to create blog posts, some of which being a hackathon and challenge. The KPI are impressions, other metrics are hard to measure. As a Developer Evangelist, I often need to learn new technologies, or dive into unknown areas connecting the dots.

You can learn more about our focus areas in our handbook: https://about.gitlab.com/handbook/marketing/community-relati...

I'm focussing on the Ops side, with a backend development background in the past 15 years. I was once a maintainer of an OSS monitoring project called Icinga, a Nagios fork back then. I decided to take on a new journey with becoming a Developer Evangelist in March 2020 (you can learn more on my website https://dnsmichi.at/about/ in case you're interested).

That being said, I've found it interesting to learn about web apps and their deployment, and dive into new things. Never having found a use case for trying Heroku, March brought up one: There was a Twitter theme of "Everyone is building a better Heroku" - https://twitter.com/adamhjk/status/1369704730218299392?s=27

From there, I thought of learning Heroku while comparing it with the 5 minute production app. I underestimated the challenge of creating a web app with a persistent backend, and decided to stick with the simple battleships demo I had initially found.

This state of the blog post felt good enough for me, and I did not include the persistent backend just yet, but moved it into a separate blog post. This is feedback I got during the review.

Turns out that this decision was wrong, next to other negative raw sentiments I had added in the blog post.

You can try to convince that it is not my fault, and I will convince you - it is, and I am standing up for it. Public and transparent.

I know we all get better from making mistakes. The lesson I learned today helped me improve a talk I gave at a meetup in my evening, it added technical insights as well as helped with the story line. That's the tracking issue: https://gitlab.com/gitlab-com/marketing/corporate_marketing/...

We will continue to iterate, and have a retrospective on what we can improve from the lessons learned today. Thanks for your feedback.

Adding my thoughts to resources shared in https://news.ycombinator.com/item?id=30005358

> I think we’re I’m going is, when we see “Hi it’s Jon/Jane from gitlab …” is it a developer taking time out of their day to respond or is it a full time marketing person?

When you see someone writing "Hi, Michael from GitLab here" it is not always a Developer Evangelist or a Community Relations team member. Everyone at GitLab can join the conversation here on Hacker News :)

John shared this thread with all team members in Slack, and Chad Wooley joined to answer the question how the handbook is built in https://news.ycombinator.com/item?id=30043995 Another example is Lyle Kozloff helping answer a support related question in https://news.ycombinator.com/item?id=30015461

You will see the Developer Evangelism team engage more often, as it is defined in the responsibilities (https://about.gitlab.com/handbook/marketing/community-relati...). The team currently covers PT, ET, CET timezones. I am located in Germany, CET.

> Devrel and evangelist is that a full time job or is it something a developer gets time off to do?

Developer Evangelists at GitLab have an engineering background, everyone has their own experience and preferences though. For example, I feel much more confident in C/C++, Go and Python, and want to learn Ruby on Rails, and Rust.

Potentially there's room to go more into detail in the team members overview: https://about.gitlab.com/handbook/marketing/community-relati... - all team member profiles are linked, where more social profiles are available. I'm using 'dnsmichi' nearly everywhere, keeping things simple.

Speaking for myself:

I was a maintainer of an OSS monitoring tool from 2009-2020, and love diving into backend engineering and Ops topics. At some point, I was doing development, community building, support, social media and marketing. And a bit of Developer Relations with speaking at events. This did not work out so well in 2019 in my previous job doing all of that, where other companies have different teams and multiple people for.

Then I saw the Developer Evangelist role at GitLab later in November 2019 in a tweet from Sid (https://poly.work/h/11Rk7Jqw), and toyed with a full time job, switching gears from full-time development to full-time developer relations / advocacy / evangelism. Friends had gone on their adventure too, Philipp Krenn from Elastic has been a great role model.

I made ambitious plans and took many notes in https://gitlab.com/dnsmichi/tech-evangelism preparing for my role, and got an offer to join GitLab in March 2020. It's been an exciting, wild ride in the past ~2 years. Not everything went well - I learned a lot from a comparison blog post discussed here on HN, and keep reflecting on how we can create better helpful content for everyone to benefit. Details in https://www.polywork.com/dnsmichi/highlights/a6f10cbf-515d-4...

I'm doing many things, sometimes too many, requiring me to refine scope and focus on the important topics. For example, 2022 will be a strong theme for Observability and OpenTelemetry, app instrumentation for developers and CI/CD Observability. I've started activities with launching a new community learning website on https://o11y.love/ and feature implementation ideas for CI/CD Observability in https://gitlab.com/gitlab-org/gitlab/-/issues/338943

A general problem in Developer Relations can be the feeling of not being successful, sometimes also called "imposter syndrome". I never thought that it could reach me, though I am reflecting on how to avoid these situations and keep writing my own "diary" / "log" in a timeline what I do. There are often small highlights which can make your day :) I have shared thoughts about it in a blog post which also dives more into Developer Relations activities: https://dnsmichi.at/2022/01/20/how-polywork-helps-devrel/

Hope this insight into my story and motivation helps :)