Improving the Readme from a user's perspective

[LaChapeliere]

Changes

Addressing issue #91 (but not fixing it), a revamp of the Readme to clarify the goal of the project and the user instructions.

Type of change

Documentation

Checklist

• [x] My code follows the style guidelines of this project
• [x] I have performed a self-review of my own code
• [x] I have commented my code, particularly in hard-to-understand areas
• [x] I have made corresponding changes to the documentation
• [x] My changes generate no new warnings

[riibeirogabriel]

@LaChapeliere Sounds very good, did you really understand the monograph! thanks!

[riibeirogabriel]

Can i help you to put the texts in respective section?

[LaChapeliere]

Can i help you to put the texts in respective section?

I'd like to finish a first complete draft, and then yes work together to fill all the remaining info. Especially the FAQ since a lot of questions are about how you want people to interact with your project.

[LaChapeliere]

Usage instructions are still rather weak, but I'll come back to it after going through the actual doc so it's easier to reference the proper pages.

[riibeirogabriel]

@LaChapeliere Thanks!

[LaChapeliere]

@riibeirogabriel Could you take a look and add info wherever there's a :question: label? Just dump the info and I'll smooth things over if you don't want to cut hair around the redaction.

[riibeirogabriel]

Yes, i will take a look and make a PR to your repo, thanks!

[LaChapeliere]

Yes, i will take a look and make a PR to your repo, thanks!

I made you contributor so you don't have to fork my fork ;)

[LaChapeliere]

Looks really good and I think we can merge after @riibeirogabriel 's edits.

We're just sorting some naming convention out with @riibeirogabriel on the issue discussion thread, there's a small section that'll need to be changed too before merging

[pottekkat]

Yes, I saw that. Great work!

On Tue, 6 Oct 2020 at 13:53, LaChapeliere notifications@github.com wrote:

Looks really good and I think we can merge after @riibeirogabriel https://github.com/riibeirogabriel 's edits.

We're just sorting some naming convention out with @riibeirogabriel https://github.com/riibeirogabriel on the issue discussion thread, there's a small section that'll need to be changed too before merging

— You are receiving this because your review was requested. Reply to this email directly, view it on GitHub https://github.com/learningOrchestra/learningOrchestra/pull/95#issuecomment-704113081, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALZOXQ4ZWKKHLI74HSX3XBTSJLHX7ANCNFSM4SD2JWYQ .

[riibeirogabriel]

@LaChapeliere it is almost done, but there are two questions yet:

• Do you get money from learningOrchestra? How do you fund the project? -> this questions is to user describe how he earns money with learningOrchestra?

• How do I cite learningOrchestra in my paper? -> I need see this with my advisors

[LaChapeliere]

* Do you get money from learningOrchestra? How do you fund the project? -> this questions is to user describe how he earns money with learningOrchestra?

No, how YOU earn money from it -> you don't. How you fund it -> Do you get funding from your advisor for stuff like website hosting for example? Many people that are new to open source are confused because they are looking for the business model, that's why this question migth be useful. But remove it if you don't like it ;)

* How do I cite learningOrchestra in my paper? -> I need see this with my advisors

Let's write "In discussion" or something then? For now

[LaChapeliere]

@riibeirogabriel I've changed the description of the microservices, tell me if you agree with the new version. I'll check all links in the meantime, so we can merge if it's good for you.

[LaChapeliere]

Looks awesome! I will talk with my advisors about the new classification from preprocessing microservices, i think thats is right way; data exploration microservices.

Since you're creating microservices by function rather than position in the pipeline, may I suggest the following categories:

• Data management (collect, load, delete, ...)
• Preprocessing (all the cleaning and transformation steps to prepare for analysis)
• Exploration and visualisation (all projections and graphics, including stuff generated by the evaluation and tuning microservices)
• Model definition and training
• Model evaluation and tuning
• Infrastucture management

Model evaluation and tuning will obviously use stuff created by Model definition and training, but by splitting those you get pipelines that are more modular, which I think is what you're trying to create. Infrastucture management is only if you add things that we have started to discuss around helping with the Ops side of things. I'm not even sure it would translate into microservices, but I thought I'd include it to be safe.