Breaking Bad Habits with GitLab CI.md

The goal of my talk is to make you a more competitive programmer.

How the average programmer thinks? “Ok, I am the programmer, I like to program, and I will program.”

However, programming is just a small part of the software development process.

It all starts with discussing an idea, then the idea turns into a task/issue, then you dig into the details, prioritize and plan, and lastly you'll start drafting your code. When the code is written, it should be tested and reviewed. New version should be tested on Staging, and then if approved, it can go to Production. Finally, you get a feedback from your customers, and the whole cycle starts from the beginning.

I suggest adding GitLab CI to your arsenal of tools. You’ll become more valuable by being able to automate any routine task, such as running tests, generating builds, and deploying your code.

Initially, this talk should have been called “Breaking Bad with GitLab CI”, and I was going to cover non-standard ways of GitLab CI utilization. However, let’s start by Breaking Bad Habits of not automating routine tasks!

You can consider this talk a mini-workshop because it is not just a demo or introduction. After you understand the principles, you will be able to use GitLab CI with any technology stack.

This is a very long-winded abstract, with the point of it not being revealed until after multiple paragraphs. By the time I get there I'm already thinking that this is going to be a very poorly structured talk and I'm not keen to go and see it.

The first few paragraphs are about programming in general. I know what programming is like, otherwise I wouldn't be at a programming conference. And none of that really seems relevant to using CI in particular. What are these paragraphs for? You could start the pitch at 'I suggest' and you'd be including exactly the same information.

Is English not your first language? There are some major grammar and idiomatic usage problems. I can point those out one by one if you want me to, but I think you'd be better off rewriting.

Sorry to be harsh, but I'd be doing you a disservice if I wasn't.

I'm inclined to agree with @chrisseaton. You have only a precious few sentences in which to hook the reader and make them want to attend your talk. Their line of thinking is going to be focused on what new knowledge they will gain by going to your talk. You must express that descriptively and concisely.

After the first few sentences I thought this is going to be a talk about the software development process (which it is, somehow, but with the use of a special tool). I was expecting something different. I also agree with @chrisseaton and @elazar that the abstract is too long-winded.
The last 3 paragraphs should better be moved to the beginning of the text.

I suggest adding GitLab CI to your arsenal of tools. You’ll become more valuable by being able to automate any routine task, such as running tests, generating builds, and deploying your code.

Try to focus and explain more around that paragraph.

Initially, this talk should have been called “Breaking Bad with GitLab CI”...

Sorry, but no one cares ;-) This just seems like you were unsure to decide about the title and content.

Most devs already have (marginal) familiarity with the idea of CI and the major CI tools (Jenkins, Travis). So why not start there? What makes GitLab CI different or worth learning compared to those other tools?

The first paragraph is crucial to attract people to your talk and those first sentences don't have anything to do with your talk or what attendees will get out of it. I suggest to shorten this abstract to maybe two paragraphs indicating what the talk is about and what people will get out of it. What problems are you solving that current solutions (Jenkins, Travis, Bamboo, etc) don't have. How will they become better developers or create better apps by learning this?