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
