Course in a Box - Mozilla Reps

Archive New Courses
#1

We’re building out a number of educational resources for Mozilla community this year, but my first stop is to create a learning space for Mozilla Reps.

The way I am currently looking at it is, that roles have their own training/education modules ie: Reps Mentor

http://emmairwin.github.io/reps-edu/modules/mentors/introduction/

But what I’m noticing, is that many components of a module (like conflict resolution) are not unique to that module. Does that mean , where module components ‘need to be reused’ I should build as ‘their own course in a box’ ? Maybe.

Or maybe each role needs it’s own course, which is made up of one or more other courses. Which translates to maintaining a lot of course in the boxes, which I don’t really want to do.

@dirk hoping you have suggestions :slight_smile:

.

#2

I agree that you don’t want to go to too many levels of indirection. I would say duplicate the parts like conflict resolution in every module. It could be a nice touch point for the different roles to do something together, but from a Course in a Box perspective I would say just copy it?

#3

From a maintainability standpoint. … I don’t think that’s ideal. I’ll
think some more and share back.

#4

Thinking more.

What I really need is modules to be able to ‘live’ outside the course in the box structure, without themselves being a whole other course in the box. So basically this page: http://emmairwin.github.io/reps-edu/modules/mentors/conflict-resolution/ could come from a number of places. Perhaps, at it’s easiest it means changing the module/_posts document structure to accommodate more options ie:

title: How does this work?
CIAB-format: true
Repository: https://raw.github.com/emmairwin/emmas_modules/Reps/conflict_resolution.md

And that’s just to support CIAB file format. External could also link to something altogether like a wiki - so people can leverage existing resources without porting everything over at once.

title: How does this work?
External: Yes
CIAB-format: false
Link: https://wiki.mozilla.org/ReMo/SOPs/Mentoring-Training

or having modules/_posts modules/_repo modules/_links

I am happy to hack on this, with feedback

#5

Sounds like you want to create a collection of study guides for all the different roles, do I understand that right? I think that can work.

#6

I’ll be creating a number of educational and training resources, with ‘roles’ as just the current focus. Most will relate to community, and thus my focus on modularity/usability (also ‘contribution-ability’), and maintainability. :slight_smile: 'all the ‘bilities’

1 Like
#7

So here’s my current (slightly over-engineered solution)

The limitations are the jekyll only has two functions for including content: ‘include’ (which includes ONLY from the folder ’ _includes’) and ‘include_relative’ which ONLY includes relative to the file.

So my working solution is to create a stand-alone repository for common content. Here, community can work-on and contribute to content (markdown) in a way that does not require and understanding of the jekyll file structure or even post naming conventions. It also means we can tag releases of content. And maybe even branch if we end up having more complicated content development.

With each release, I clone common_content into the _includes folder and then simply use {% include common_content/filename.markdown %} in a post, and there it is!

Although the whole branching tagging bit is probably overthinking it a bit, this is a solution that helps me move forward. Would be interested if anyone sees any holes, or improvements in that workflow.

#8

@Emma_Irwin - that sounds like it could work well. You may want to look into using git submodules - it could help you avoid manually cloning the content repository into your course repository.

#9

perfect: https://github.com/emmairwin/reps-edu/tree/gh-pages/_includes and it works. So onward. Thanks!

1 Like