Hi Mirko, I think in principle I agree with you. I also do think that making content searchable and easily composable into different trainings based on what is needed on the spot is the final target (and Mount Everest :) ).
I love the idea of having everything indexed and easily searchable! If we manage to combine that with some metadata like - instructors guidelines - prerequisites that students need - learning objectives - test questions - faq - etc and come up with a way of easily composing trainings from this then I think we have achieved something really worthwhile! The only point where I beg to differ from your point of view is the onboarding of existing content. A landing repository is certainly a great idea and I agree that it should not put any restrictions on the type of content in there and we can also include it in the searchable material for reference. But for the actual content, I do believe that we need a standardized format into which donated material will be converted. Keeping these up to date will be an effort, but sharing that effort was one of the main drivers behind this entire podling, so I don't think that we should shy away from that. In my mind the processes would look something like this: Onboarding: - donated material is added to a "raw" repository - raw material is converted piece by piece into whatever format we choose later on - as part of this process it'll also be properly indexed, whatever that means with reference to the metadata etc. that we discussed - once everything is converted it is retired from the landing zone Repository: - the main Apache Training repository contains the curated content that was donated as well as created from scratch - this will probably be just a git repo - all is searchable, tagged with metadata, .... all this needs to be discussed I think - based on the content of this repository it is now possible to create courses with content from that repository - some "default" courses will probably be part of the official repo - by using our tooling people can also create custom courses, every time they rebuild an existing course it will pull updated material from the repo - people can also host repositories of their own, either private or public to benefit from the tooling we created Sorry, probably rambling a bit here :) Hope that makes a little sense? As a follow up I'd like to pick up on a point from Craig as well about naming and what parts we actually need to name. I have on my todo list the item "suitable name search" for this podling, but I hesitate to actually start that because I feel that we are still a bit unsure on what all we actually need to name. I feel like Apache Training as the overall name is still suitable, but if we create tooling like what I described above I also feel like that might actually deserve a name of its own, because people could potentially use that completely separated from the Apache Training content to build courses of their own. Any thoughts? Best regards, Sönke On Mon, Mar 11, 2019 at 9:17 PM Mirko Kämpf <mirko.kae...@gmail.com> wrote: > > Hey Lars and Craig, > > I comment inside Craig's response with some of my thoughts regarding > content. > > Am Mo., 11. März 2019 um 20:23 Uhr schrieb Craig Russell < > apache....@gmail.com>: > > > Hi Lars, > > > > > On Mar 11, 2019, at 9:22 AM, Lars Francke <lars.fran...@gmail.com> > > wrote: > > > > > > Another thing I wanted to bring up is donation of existing content. > > > > > > We have (partial) trainings on HBase, Hadoop ecosystem basics, Kafka and > > a > > > few other minor things ready. But they are PowerPoint. > > > > > > The colleagues from inovex have their own existing material, also in > > > PowerPoint. > > > > > > I _hope_ that we'd get other material as well. > > > > I have a number of presentations that are written in OpenOffice .odp and > > then exported as .pdf for use. > > > > > > Do we want to accept material no matter the format? > > > > I think that would make it easier for contributors. > > > > > Do we require it to be in a (yet to be decided) canonical format? > > > > I would hope that the tooling would allow material to be transformed to > > and from a few formats into whatever "canonical" format we choose. > > > > > Does it need to go through a normal "proper" review? > > > > Yes; either a software grant or icla would normally be the standard to > > accept an original work. Minor edits to existing presentations would have a > > different standard. > > > > It might make sense for us to have a "contributions" part of the project > > and then transform and move them to where we want to distribute the > > canonical form, organized into courses that included presentations, labs, > > feedback (tests) etc. > > > > > > I thought about this for a while and it comes back to a point we talked > > > about in another thread: > > > Do we have proper releases or do we just tag various trainings with > > various > > > maturities? > > > > This might be a separate thread from this one, but releases are actually > > kind of a big deal here at Apache. There is a lot of process to make > > releases. > > > > In order to rationalize our effort it might make sense to have a "core" > > which contains all of the tooling for the project and groups of source > > materials (courses) that the tools would operate on. Organizing the groups > > into collections of courses might allow us to release the collections > > individually. > > > > We could also encourage outside groups to use their own repositories to > > store content that our core tools would process. The outside groups could > > have their own contribution/editing/release process distinct from the > > Apache project. What the tooling would specify is the organization of the > > courses. Probably a directory structure with specifically named > > subdirectories with canonical naming scheme for the various bits of what we > > might call courses. > > > > Especially because of the variety of course styles and the huge number of > technologies we have to deal with, I suggest to focus less on particular > documents and their appearance. > > I think, landing contributed material in a document repository and "making > this material" accessible is key to our project. Even if we convert the > slide decks, or drafts or whatever is used for a workshop - the material > will be outdated faster than we can maintain it. > > *But, training concepts will stay longer.* Once we have a good presentation > about - let's say Apache HBase - we should care about "the way to teach > this type of technology". > Example 1: HBase is a key-value store - This means, also other trainings > about key-value stores are related to this material. > Example 2: HBase can work as a cache - This means, it is also relevant for > trainings about caching-systems - at least the material can be relevant as > an example. > > Rethinking the preparation phase of my training courses in the past I think > it is much more helpful to get inspiration for "your flow" and for "your > hot topics" rather than fully pre-materialized documents. The more we care > about "compiling the best course about XYZ" the more energy we need in > terms of finding the "best way to teach something". > Since I believe, there is not such a best way - we should rather collect > possible ways and thus, just provide the material in a repository and then, > as part of our release, we maintain the "knowledge graph" in a searchable > way - e.g., as SOLR index in a container. > > In a previous project I indexed our team-repository and multiple FAQs. The > SOLR index files have been zipped and shared via a central repository. Each > team member had access to an "offline reader" since we used this material > often also in offline situations. Assuming we have a* preparation phase for > our course* and access to free documents, we could simply download all > referenced content to a local disc (or as part of a docker container with a > local SOLR instance) and than, the content package can be used to support > any kind of real life training scenario. > > Providing content packages for such scenarios is what I can imagine as a > part of the Apache Training project. > Each content package should come with reference material, and learning > objectives, facts, and FAQ sections. > > As an alternative, I can see the getting started tutorial to any kind of > Apache project as well standardized (standardizable) assets which can be in > our focus, at least in the beginning of Apache Training - to get a first > release of something well defined. > Merging all the incubator project's getting-started guides could also bring > some collaboration energy to this island ... ;-) > > What do you think? > > Best Regards, > Mirko > > > > > > > > Have we thought of what to call the various parts of the training process? > > > > Craig > > > > > > I could imagine a "staging" area for donated material and then a "beta" > > and > > > a "ga" layer. Or some other verbiage (could even follow the ASF model of > > > having "podlings" which can graduate). > > > > > > Either way: Opinions? > > > > > > I'm looking forward to actually working with some content ;-) > > > > Craig L Russell > > c...@apache.org > > > > > > -- > > Dr. rer. nat. Mirko Kämpf > Müchelner Str. 23 > 06259 Frankleben -- Sönke Liebau Partner Tel. +49 179 7940878 OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany
