2:22 p.m.
Hi all,
Circling back to close this thread.
Summary: we did a good job following a decision process, and decided to
create a single `training` repo to organize into one source, many courses
for multiple types of learners.
## Process
This thread is an example of a lightweight decision process happening in
full-view of the community. Those who were interested in the outcome were
invited to the node of discussion (
https://github.com/operate-first/common/issues/39 ), we achieved consensus,
and have begun to build out the repo.
At the same time, we are announcing the decision back into this group. This
gives another opportunity for the wider community to review the decision.
If anything changes in the decision after that review/discussion, we take
advantage of how our infrastructure is designed to rollback or roll-across
to the new decision.
## Decision
Our conclusion is:
- One repository called `training`
- Use directory structure and filenames to differentiate between courses
and modules
- E.g. 'SRE Apprenticeship' and 'SRE Camp' course file names will be
different and in different directories
- If a module or course (one or a set of Jupyter Notebooks) need in-repo
resources, a module or course can have its own directory
- Sharing content between courses is easiest in git/GitHub when in the same
repo
- This includes a course/module being able to "freeze" itself with a
particular version of itself and all supporting parts across the repo by
using git and tags/releases
- Once the Governance 1.0 is in place, the Community SIG should form a new
Training SIG to own the repository and processes going forward.
- Then the Training SIG decides if/when any further repositories or
features are needed to support the growing range of Op1st training
activities.
Kind regards,
-- Karsten
On Mon, Nov 15, 2021 at 10:16 AM Karsten Wade <kwade(a)redhat.com> wrote:
All:
The team working on SRE training are ready to setup their repositories,
and Stephanie created this issue for opening the first repository:
https://github.com/operate-first/common/issues/39
We had a meeting today with the team who is going to be working in GitHub,
and we're not sure what is the best model to follow for repositories.
Please join us there to discuss what we want the repo(s) to look like. We
particularly need help from people with experience around automation
amongst multiple repositories.
Background
=========
Stephanie and anyone else, please fix any incorrect GitHub and modularity
thinking here, thanks.
As a community, we are creating a knowledge pool of modular course
materials. Modular here means, creating discrete pieces of content, each
explaining what, how, and why for a task. The learner might be a
contributor learning or reminding how to do the task; or the learner might
be a user taking a full SRE course. The same content can be used in both
cases, but placed into a context specific for the different learner type.
This content therefore is more than a Markdown file, it has inline or
metadata (labels, etc.) that means it can be organized to appear in
multiple learning pathways.
These multiple learning pathways currently are: SRE Learners, Open Source
Developers, Project Contributors, and Data Scientists and Data Engineers.
So if combining the pool with the number of learning path options, it
could be four separate learning paths with e.g. twelve modules per path.
Those modules would comprise existing modular content, combined with
content specific to the module that shapes the relationship to the learner
persona. An example of a single module might be, "How to use GitOps to make
changes to a live production cloud." It could have the how-to and
sparse-why content (useful for Project Contributors and Open Source
Developers) from one location (a repo?), which can be combined with the
full what/how/why of a beginner's viewpoint into a single ready-to-teach
module.
That's already 48 unique combinations to cover four pathways, and within
those modules it might be 3x to 5x more when combining pieces to form a
specific module.
Is this a repos problem? A branching problem? A nesting folders problem?
Or something else?
Kind regards,
- Karsten
--
Karsten Wade [he/him/his] | Senior Community Architect | @quaid
Red Hat Open Source Program Office (OSPO) : @redhatopen
The Open Source Way : https://theopensourceway.org
Operate First : https://operate-first.cloud
--
Karsten Wade [he/him/his] | Senior Community Architect | @quaid
Red Hat Open Source Program Office (OSPO) : @redhatopen
The Open Source Way : https://theopensourceway.org
Operate First : https://operate-first.cloud