Hi Frank, thanks for your mail, overall I totally agree with everything you said.
Regarding how to organize the content directory, I am unsure about the overall way of doing this. I think from what we have already seen we will have very varied content that I'd struggle to sort into lab, slide or any other well defined structure. I am personally tending towards ordering this into purely top level directories like "hbase_labs" "hbase_slides" or similar and then taking care of everything else via metadata. I think the process of using this will be largely decoupled from the actual directory structure anyway, as we'll have metadata and search indices for everything, so we might as well keep it simple here.. Just my two cents :) On a larger scale, I think if we can agree on the top level structure to start out with and get that committed, then there will probably be smaller groups of people interested in specific directories and can start discussions around the structure in there. Best regards, Sönke On Thu, Apr 11, 2019 at 11:17 AM Frank Marmann <[email protected]> wrote: > Hi, > > > > I like the proposed repository structure. I will just write out some > thoughts and my understanding to see if it fits your intention. > > > > content – below the /content/core/ directory there are specific subfolders > for each topic, which may or may not be related to Apache projects like > HBase, Spark, etc. > > > > I am not so sure yet about the language-specific subfolders. We need to > take multiple languages into account, but this applies not only to content > bus also to labs and maybe even to exams. I think this is a technical > decision of how to provide multiple languages. > > > > Below the /content/core/<topic>/content/ directory we probably need the > possibility to define training modules for that topic (or call it building > blocks as the term modules might be too overloaded already). For example: > Spark Basics, Spark ML, Spark Streaming, etc. In my option it is a > primarily technical decision if these building blocks require another level > of subfolders or if there is one file per building block or something like > that. > > > > training – I like the separation of content and the actual training. But as > you already wrote I also see the need to somehow create “releases” for each > of those trainings separately. > > > > Looking forward getting this structure up and running! :) > > > > Best regards, > > Frank > > On Wed, Apr 10, 2019 at 3:49 PM Sönke Liebau > <[email protected]> wrote: > > > Hi everybody, > > > > I'd like to start a dedicated thread about how to roughly structure our > > repository. > > I don't think we need to agree on the final and detailed structure at > this > > point in time, but some very high level decisions would be useful at this > > point to enable us to move forward I believe. > > > > Biggest question is: one repository or multiple? > > > > My personal opinion is that we can make do with one and it'll be less > > hassle overall. > > > > Based on that I think we need a few top-level directories: > > > > content - slide sources > > site - source code for the webpage > > tools - home to all tooling that we'll potentially develop > > trainings - definitions of trainings - these will not contain actual > > content but references to content from the content folder > > > > None of the names are final or in any way important for me - feel free to > > propose better suitable candidates! > > > > Lars has created a playground for that in our github account [1] which we > > could use to play around with this a little bit - but I think if we can > at > > least agree on the top level structure we might just as well get that > > committed to the Apache repo and then have individual discussions in the > > sub-projects. > > > > Any thoughts? > > > > Best regards, > > Sönke > > > > [1] https://github.com/opencore/training-playground > > > -- Sönke Liebau Partner Tel. +49 179 7940878 OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany
