Define The README File Structure

[romsi]

Goals ⚽

• Having a simple structure where people can easily access the content that matters to them
• Having minimum valuable content.

Inspiration 💡

• The official Swift style guide for raywenderlich.com
• uFeatures guidelines

[damienfraud]

Please, correct with These guidelines. I also believe we should develop this introduction a bit more to be more explicit about the goal of this document.

[romsi]

Sure, please go ahead.

[damienfraud]

Please, correct with This document intends. Also, I'm not sure this should appear in the README. If the document intends to be clear, brief and consistent, readers should be able to see it without us having to specify it. If this was specified for possible contributors, then maybe this is something we should add in a CONTRIBUTING file.

[romsi]

I like it because it helps reader to quickly understand the philosophy behind it. You can access to a particular section without needed to read the others. Checkout Raywenderlich style guide.

[damienfraud]

I added some comments already inside the content directly. To complement these, I really like the chapters set for this document, it sets up a nice base for the content. I also think we should start to think on defining labels (and maybe Milestones) for our pull requests, but maybe this is more of something to discuss inside PR #2.

[romsi]

I also think we should start to think on defining labels (and maybe Milestones) for our pull requests, but maybe this is more of something to discuss inside PR #2.

I do agree and we should create a CONTRIBUTING.md file where we define all these rules.

[romsi]

@damienfraud I do think if we have typo issues then we should correct them instantly, not waiting for authors to correct it.

[damienfraud]

I do think if we have typo issues then we should correct them instantly, not waiting for authors to correct it.

I agree, that is why checkout script has even more sense in those case (cf. my comment in PR #2). What do you think?

[romsi]

Check my answer.

[damienfraud]

@romsi I added some changes to the introduction. Please, review before we can approve this PR.

@damienfraud I was thinking about being explicit about that is based on our experiences, but I feel it should stay implicit. For example when you go to (Airbnb/javascript](https://github.com/airbnb/javascript) guideline repository, you know that it's based on their experiences. Being too explicit make people uncomfortable to contribute to it.