Create a more basic introduction about task automation software and frameworks

[sdondley]

I would like to volunteer to help write a gentler introduction to Rex and the world of automated server/computer administration. Some basic topics I would include are:

1. What is an "automation framework?"
2. Why would you want to automate? What problems does automation solve?
3. What are some typical use cases for automation?
4. How to use Rex as a framework to help you automate tasks.

Basically, this intro would assume the person has little knowledge about server management software. Not being overly familiar with this class of software myself, I would need some general guidance but I will do all the writing.

[randyl]

I think this is a good idea. My first visit to the Rex website didn't help me understand why it's useful, or why it's better than, for instance, a series of shell scripts. Having a basic introduction like you suggest would be helpful.

[sdondley]

Yeah, I have to get around to writing that still. Thanks for the feedback and nudge.

But off the top of my head, some of the big advantages using Rex over bash scripts are:

1. You don't have to bother installing bash scripts on the remote machine.

Why is this important? Because if you have more than one machine to manage, you don't have to copy around your scripts to all the different machines you want to execute them on. It also means you don't have to install software on the remote machines.

2. It can be platform neutral.

The idea is that you can write some code for installing a package and/or starting and stopping a service and the code can work no matter what OS the remote machine is running.

3. It's far easier to write perl scripts to do complex tasks than write bash scripts

If you are familiar with Perl, at least.

4. Rex provides a way to group your tasks into libraries. Tasks in one library can call a task from another library.

This is much better than having a bunch of isolated scripts on your local machine.

5. The framework provides a bunch of nice little tools and commands that you can leverage to scale up big in a way that's just not possible with bash scripts without a huge amount of effort.

[ferki]

First, thank you for collecting ideas and considering to contribute more.It's a very useful feedback about how existing documents are desired to be improved, and which areas would require attention first.

I will be unavailable for a good while, and since there was recent activity here, plus it sounds like a major overhaul of the current content, I wanted to respond briefly, and encourage you to write about the topic on a personal publishing platform (at least) first.

At this point in time I personally don't consider the rexify-website project as a generic publishing platform for community content, or for more generic content e.g. about "the world of automated server/computer administration".

My main dilemma is what we put on the website automatically becomes official, and the maintenance burden of that also automatically falls on the long-term maintainers because the original authors doesn't come back to update their previous contributions (and we already have outdated content that needs review and curation which is a lot of work in the backlog).

So I also don't want to set false expectations of "if people submit articles here, it will be published, curated and maintained by the RexOps project" without being able to commit to that promise. Currently it gives me a great deal of frustration that someone might be putting in a lot of work into a content overhaul that we might not be able publish after all as official.

Because of that, I think that currently it's more fair to encourage people to publish Rex content on their own channels, increasing the spread of where Rex content is found, while decreasing the publishing burden and complexity. At the same time, I'd be happy to help popularize the content through official channels like linking to it on the website or sharing on Twitter. That way the content can be published easier/earlier, can be endorsed by upstream, or even republished as official (if allowed).

If we as a community need a different strategy about these topics, I'd like to encourage working on that "vision" first together, and reaching to a common understanding of project scope and goals together in a different issue (and probably different medium).