Learning Tracks - example algorithms

[PaulNewton]

This issue will use computer science algorithms as an example but the issue is not about that specific topic but rather the implementation of ANY "track".

In addition to the three skill based tiers there should be knowledge pursuit tracks allowing new learners to move through those tiers onto related app-projects. This differs from #34 by focusing on a self directed educational goal instead of the creation of a specific type of MVP app.
This could be facilitated by docs,specific app-projects, or metadata to create a structure that relates different app-projects across the current tiers.

Academic Tracks - cover areas of interest in a curriculum similar to how developer conferences have tracks that allow you to attend specific presentations that are related throughout a day.
There are other terms ,like paths, for the idea and one of those may be a better fit for this project that deals with specificity[1] better

This is multifaceted with different flavors of difficulty, such as:

• metadata
• repo maintenance
• sensemaking wide areas of software development

So working out a reasonable process for submission and quality is important if a "tracks" feature is pursued to avoid a refactor.

Metadata & Maintenance - How to store this track metadata and present it in a intuitive way to learners 🤔?

Also so that extra info does not burden maintainers while keeping information in sync and resistant to breaking from changes. A catch here is if someone is NOT on a track you don't want to distract them with spurious "track" information.
Currently tiers are controlled by being in specific folders but this does not lend itself to also being used for tracks without needless duplication. does github allow symlinks? how would this work with githubpages? For tagging git itself can't be used as it only allows 1 tag on a specific commit

Having only a separate document makes it easy for a track to become outdated as a project-app changes,possibly removing the reason that app-project was in a specific track in the first place.
There should be some information somewhere in app-projects about which tracks they are a part of to serve as a sanity reminder when an app-project is changed.

Sensemaking - software development is a massive field even trying to narrow down to app-development still leaves a HUGE problem space that needs to be understand when reviewing any submissions. This means for maintainers adding "tracks" could become an unwanted burden.
With that in mind an overall process should be used to make sure a bare minimum is met before any "track" is merged.

I believe this rough checklist gives a high level overview of the different types of steps needed from any contributors submitting any type of "track" once it's figured out where to store track metadata:

• issue - open the ticket with title [TRACK] trackname and track doc starting file
• copy the following checklist items into that ticket
• file - track doc - separate file in plain english explaining the concept and how app-projects relate
• ticket - information gathering - in the ticket reviewers go over what types of concepts should be included at minimum and aggressively prune excess
• concept tiering - what is the difficulty or time intensiveness of the concept
• app alignment - Identification of any existing app projects that by their own nature already make use of a concept related to a track
• app checklist - list of app-projects requiring updates and needing inclusion in the track-doc
• add metadata - update existing app-projects that align with concepts&tracks
• add missing app-projects to facilitate a tracks core concepts across all 3 tiers
• file - track doc - further education

Example

• Tier 1 - Algorithms - sorting - Word Frequency
• Tier 2 - Algorithms - sorting - Podcast Directory - sort by rating AND date
• Tier 3 - Algorithms - sorting - NASA Exoplanet Query

Additional context and clarification
After tuning a creation process eventually there would be meta documentation,similar to Example Guide.md, about creating tracks.

The track doc also serves as the clarification space where issues for a track should be referenced so as to not bog down app-projects themselves just because it happens to be used in a specific track.
At the end of the track doc should be "further learning" information on bigger open source projects related to the focused track. An example with algorithms would be MIT's opencourseware Introduction to Algorithms, or someone on a UI-design track pointed to the TodoMVC project

App-projects created for a track should still be able to stand alone if a user is not on a track.

[1] Specificity - some things may be higher conceptual abstracts vs more specific concrete focused skills

• algorithms conceptual - big O notation
• algorithms concrete - binary sort
  Other examples beside computer science algorithms:
• conceptual - UI design, security accessibility
• concrete - learning a specific language(javascript,html5), or a frameworks(react,etc)