Small edits (#423)

docs/getting_started/mlops/mlops_best_practices.md

@@ -18,7 +18,7 @@ If you are afraid of clutter, use the archive option, and set up your own [clean
 
 ## Clone Tasks
 In order to define a Task in ClearML we have two options
-- Run the actual code with `task.init` call. This will create and auto-populate the Task in CleaML (including Git Repo / Python Packages / Command line etc.).
+- Run the actual code with `Task.init` call. This will create and auto-populate the Task in CleaML (including Git Repo / Python Packages / Command line etc.).
 - Register local / remote code repository with `clearml-task`. See [details](../../apps/clearml_task.md).
 
 Once we have a Task in ClearML, we can clone and edit its definitions in the UI, then launch it on one of our nodes with [ClearML Agent](../../clearml_agent.md).

docs/getting_started/video_tutorials/hands-on_mlops_tutorials/how_clearml_is_used_by_a_data_scientist.md

@@ -100,7 +100,7 @@ really annoying. And that is what ClearML Data does for you is it will keep trac
 of which run of your code actually produced this, and that allows you to always go back and see if you made any mistakes. 
 You can always go back, which allows you to iterate a lot faster. 
 
-And then finally we have the training script. If I go to the training script, you also again see the `task.init`, so we 
+And then finally we have the training script. If I go to the training script, you also again see the `Task.init`, so we 
 want to capture every single time that we run this code, and then you can also see that I made a huge configuration dict. 
 So essentially every parameter that I use in my code is in this dictionary, and then I connect it to the task. and we'll 
 see later why that is really, really useful. But for now at the very least what it will do is it will keep track of all 

docs/getting_started/video_tutorials/hands-on_mlops_tutorials/how_clearml_is_used_by_an_mlops_engineer.md

@@ -215,7 +215,7 @@ then you could go and clone the experiment and then enqueue it. This is somethin
 
 Now, another way of doing this is to actually use what you can see here, which is `task.execute_remotely`. What this line 
 specifically will do, is when you run the file right here. Let me just do that real quick. So if we do 
-`python setup/example_task_CPU.py` what will happen is ClearML will do the `task.init` like it would always do, but then 
+`python setup/example_task_CPU.py` what will happen is ClearML will do the `Task.init` like it would always do, but then 
 it would encounter the `task.execute_remotely` and what that will tell ClearML is say okay, take all of this code, take 
 all of the packages that are installed, take all of the things that you would normally take as part of the experiment 
 manager, but stop executing right here and then send the rest, send everything through to a ClearML agent or to the queue 

docs/getting_started/video_tutorials/hands-on_mlops_tutorials/ml_ci_cd_using_github_actions_and_clearml.md

@@ -55,7 +55,7 @@ and we have our task as well.
 Now, I'll start with the task because that's the thing we're going to run as the experiment you want to keep track of 
 in your Git, and in ClearML, and in this case, we'll just take like a dummy task. We'll take a very, very simple example 
 here, so we just do `from clearml import Task`. If you're familiar with ClearML this will be very familiar to you as
-well. It's just the `task.init`, give it a project, give it a name, and then I basically always set `reuse_last_task_id` 
+well. It's just the `Task.init`, give it a project, give it a name, and then I basically always set `reuse_last_task_id` 
 to `false`, which basically means that it will never override the previous task if it didn't complete properly. It's more
 or less a thing of taste. Then I set the random seed to do something completely random. Then for 10 times basically we're 
 going to be reporting a scalar, which is called performance metric in series "Series 1" and it will have a random value, 
@@ -67,7 +67,7 @@ also have the commit ID, which will come in handy later, and then we also have t
 directory. As you might know, we also keep track of any uncommitted changes, so if you add anything in the code that 
 isn't already tracked by Git, we also take care of that. But that will come in handy a little bit later as well. We also 
 keep track of installed packages and stuff like that. In this case, of course, we don't really keep track of very much, 
-it's only the `task.init` and then just reporting some scalars. 
+it's only the `Task.init` and then just reporting some scalars. 
 
 What we do have is some scalars, so this is what it would look like, and we'll be using this one later down the line. 
 Right, so if I go back here to my code you can also see we have a GitHub folder with the workflow sub-folder in there.