Curriculum restructuring

[Mierdin]

Current Problems

Categories

Right now, there are four categories in the platform:

1. Fundamentals
2. Troubleshooting
3. Verification
4. Configuration

While this seemed appropriate at the beginning, it's proving to be fairly inadequate as more content gets added, and we start planning yet more content for the future.

Content is skewing towards "tools"

Part of what makes automation hard is that there are a number of tools out there, and each has their own setup process, and it can take a lot of time to get things to the point where you can even start tinkering. In that respect, NRE Labs has been a resounding success. After all, one of the benefits of the platform is that you can get experience with these tools without any setup in your own environment.

However, because of this strength inherent to the platform, the content has definitely focused on the tools. Again, there's good reason for this content to exist, but it has become difficult to figure out whether a lesson is trying to teach a specific tool, or a more tool-agnostic workflow or methodology. Currently, the best-case scenario is that a lesson contains a lab or two at the very end that goes through some useful use-cases, after spending many more labs going through the features of a given tool.

It also makes it harder to categorize a lesson that introduces a tool. For instance, you can use Salt to accomplish quite a few things. Some of those things are Configuration Management, others are Event-Driven Automation. Neither or these are appropriate categories for the lesson introducing Salt, rather they are more appropriate for lessons that focus on a specific workflow that uses Salt to accomplish one of those things, and it would be implied that you already are familiar with Salt to go through with those lessons.

Proposed Solution

Here is a summary of the changes big changes for v0.3.0 to help us with this.

Categories Change

Proposed New Categories:

1. Fundamentals - basics like YAML, Python, etc
2. Tools - specific "Tool 101" lessons. Introduction to Ansible, Salt, Stackstorm, etc
3. Workflows - applying lessons in previous categories to accomplish a particular outcome. I.e. "Using JSNAPy to validate STIG compliance"

This is much simpler, and provides a natural progression from left to right, as the user moves from the more generic to the more specific.

However, you may correctly point out that we lose a lot of the value of the previous categorization from the existing format. Enter tags:

Introduction of Tags

While these categories cover vertical taxonomies of lessons, there will still be constant threads that run through them. For instance, Ansible will be mentioned in the "Intro to Ansible" lesson (of course) but will also likely be mentioned elsewhere. Maybe someone doesn't have a workflow in mind, maybe they just want to see everything that contains references to Ansible.

Tags will help us be able to provide this.

Metadata Changes in Syringe

To support these three efforts, Syringe must also incorporate new lesson metadata:

• prereqs - helps the advisor understand the dependency graph between lessons
• categories - must change to incorporate the new structure
• tags - additional data to help folks find lessons by keyword

The "NRE Labs Advisor"

I've captured this a bit more in nre-learning/antidote-web#22. Basically this will be a dedicated page that allows users to specify what they want to learn, and based on the dependency graph made available via lesson metadata (see the previous section), the Advisor will construct a recommended path for you to follow.

Collections

The antidote project is proud to be a community project, which puts learning and personal advancement above others. We strive to ensure the content hosted within our primary platform "NRE Labs" is not a product pitch, but rather, focuses on the skills and workflows that make the learner's lives better. However, due to the nature of the network industry, it's impossible to demonstrate network and network automation technology without showing some kind of vendor's products, or at the very least, open source projects that a vendor maintains.

The PyEZ and JSNAPy lessons are good examples of this. These are both open source projects, but they're only useful against Juniper gear. We feel it's beneficial to show these in action, even if the learner doesn't use Juniper's network gear, because it's just one way to solve a problem, and it's a good experience to have. However, the additional context of knowing this is a bit more Juniper-specific would be helpful.

nre-learning/antidote-web#29 and nre-learning/antidote-core#54 began to introduce functionality to indicate when a lesson was "from Juniper". The idea was that we felt there were some useful things using Juniper tech to show to the user, but since NRE Labs is truly meant to be a community initiative, rather than a vendor-driven marketing tool, we wanted to make sure everything was properly disclosed. However, this ended up being a little too narrow of an implementation. We needed something a little more robust that could allow us to organize lessons in a similar way but beyond just what might apply specifically to Juniper technology.

Enter collections. Design to follow.

[Mierdin]

Per @dkalintsev:

One thought that comes to mind is it would be good if Advisor was able to show that there may be several paths to achieve the same goal, each with different tree of pre-requisites. E.g., I can implement config automation with Expect/SSH, Python + PyEz or whatever, Terraform, Ansible + Jinja, and so on. The point here is to help people choose their own adventure that ends in the similar result of winning whatever quest. This IMO would be useful as people could match the pre-reqs to what they already know to find their own path of least resistance.

[Mierdin]

The above proposal was implemented in nre-learning/antidote-web#30