Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve developer docs #1015

Merged
merged 5 commits into from
Feb 27, 2018
Merged

Improve developer docs #1015

merged 5 commits into from
Feb 27, 2018

Conversation

bajtos
Copy link
Member

@bajtos bajtos commented Feb 19, 2018

  • integrate MONOREPO and DEVELOPING guides
  • add "new package checklist"
  • sort entries in MONOREPO.md
  • add content from the wiki page Contributing

This is a follow-up for #977 and #1005 and requires #1013 to be landed first.

Checklist

  • npm test passes on your machine
  • New tests added or existing tests modified to cover all changes
  • Code conforms with the style guide
  • Related API Documentation was updated
  • Affected artifact templates in packages/cli were updated
  • Affected example projects in packages/example-* were updated


## Packages
<!-- PLEASE KEEP THE TABLE ROWS SORTED ALPHABETICALLY BY PACKAGE NAME-->
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I intentionally sorted the packages by the nature of the modules such as common utilities, core, extensions, examples.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem with "order by nature of modules" is that it's subjective. There's definitely a case to be made for either ordering but I will say that as a "third party", I think it's always easier to reference things that are alphabetically ordered.

If you are going to group by functionality, you should create separate tables and name the groupings.

@raymondfeng
Copy link
Contributor

@bajtos Great start. A few comments:

  1. The README should have obvious links to other files (developing/monorepo/contributing).
  2. Not sure why DEVELOPING.md is under docs while the rest are not.
  3. We probably should have a section in DEVELOPING.md to cover how to add documentation for new features.

@jannyHou
Copy link
Contributor

@bajtos #1013 landed 🚢 you can continue yours, thanks!

Copy link

@richardpringle richardpringle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only one suggested change


## Packages
<!-- PLEASE KEEP THE TABLE ROWS SORTED ALPHABETICALLY BY PACKAGE NAME-->

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem with "order by nature of modules" is that it's subjective. There's definitely a case to be made for either ordering but I will say that as a "third party", I think it's always easier to reference things that are alphabetically ordered.

If you are going to group by functionality, you should create separate tables and name the groupings.

@@ -33,7 +28,7 @@ Then in your Node.js project root, run:
npm install -S @loopback/core
```

> Make sure you set `"target": "es6"` in your compiler options in your
> Make sure you set `"target": "es2017"` in your compiler options in your

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

README.md Outdated
- [Join the team](https://github.com/strongloop/loopback-next/issues/110)
See [Contributing Guidelines](./CONTRIBUTING.md) for more details.

You can join the team by posting a comment to [issue #110](https://github.com/strongloop/loopback-next/issues/110.).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

We use two tools to keep our codebase healthy:

- [TSLint](https://palantir.github.io/tslint/) to statically analyse our source code and detect common problems.
- [Prettier](https://prettier.io/) to keep our code always formatted the same way, avoid style discussions in code reviews, and save everybody's time an energy.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and save everybody's time and energy

👍

@@ -138,12 +157,54 @@ The **body** provides more details, it should include the motivation for the cha

Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes"a

Paragraphs or bullet points are ok (must not exceed 100 characters per line). Typically a hyphen or asterisk is used for the bullet, followed by a single space, with blank lines in between, but conventions vary here.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but, conventions vary here.

I would remove this. While it may be true, I don't think it should be documented.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will remove.

$ npm i -g commitizen
```

And to use it, simply call `git cz` instead of `git commit`. The tool will help you generate a commit message that follows the above guidelines.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Were the above guidelines directly from commitizen or is there some kind of config that sets things like the 100 char "limit".

Might be good to mention where "the above guidelines" come from.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most of the guidelines are from https://conventionalcommits.org/, some tweaks are our own (100 char limit, list of scopes defined by monorepo packages). We do mention https://conventionalcommits.org/ at the beginning of Commit message guidelines section. I feel that's good enough.

- Update [MONOREPO.md](../MONOREPO.md) - insert a new table row to describe the new package, please keep the rows sorted by package name.
- Update [docs/apidocs.html](./docs/apidocs.html) - add a link to API docs for this new package.
- Update [CODEOWNERS](./CODEOWNERS) - add a new entry listing the primary maintainers (owners) of the new package
- Ask somebody from the IBM team (e.g. [@bajtos](https://github.com/bajtos), [@raymondfeng](https://github.com/raymondfeng) or [@kjdelisle](https://github.com/kjdelisle)) to enlist the new package on http://apidocs.strongloop.com/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will fix.

Copy link
Member

@dhmlau dhmlau left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just one more change on the apidoc.loopback.io URL instead of the strongloop.com one.

@bajtos
Copy link
Member Author

bajtos commented Feb 26, 2018

The README should have obvious links to other files (developing/monorepo/contributing).

Makes sense, will fix.

Not sure why DEVELOPING.md is under docs while the rest are not.

That's a good question, indeed.

  • I think it's better to keep CONTRIBUTING.md at project root to make it easier for people to find it, as CONTRIBUTING is one of those common files many projects have in project root. Since we are linking to this file from README, I don't mind to move it to docs. GitHub's feature showing a link to CONTRIBUTING file supports the docs location too, no problem there.

  • I did not move MONOREPO to docs because I though it was your intention to have it in project root. If you are ok with the move, then I am happy to move it to docs.

@raymondfeng Thoughts?

We probably should have a section in DEVELOPING.md to cover how to add documentation for new features.

I agree. Let's leave it out of scope of this pull request though.

[Raymond] I intentionally sorted the packages by the nature of the modules such as common utilities, core, extensions, examples.
[Richard] The problem with "order by nature of modules" is that it's subjective. There's definitely a case to be made for either ordering but I will say that as a "third party", I think it's always easier to reference things that are alphabetically ordered.
If you are going to group by functionality, you should create separate tables and name the groupings.

@raymondfeng what's your opinion here? May I keep alphabetical order, or are you asking me to preserve your sorting and split the table into multiple ones?

@bajtos
Copy link
Member Author

bajtos commented Feb 26, 2018

I have rebased the patch on top of the latest master and addressed your review comments.

@raymondfeng @richardpringle LGTY now?

@bajtos bajtos added developer-experience Issues affecting ease of use and overall experience of LB users Docs labels Feb 27, 2018
@bajtos bajtos merged commit c8af3f6 into master Feb 27, 2018
@bajtos bajtos deleted the docs/improvements branch February 27, 2018 17:20
kjdelisle pushed a commit that referenced this pull request Feb 27, 2018
kjdelisle pushed a commit that referenced this pull request Feb 27, 2018
* docs: integrate MONOREPO and DEVELOPING guides

* docs: add "new package checklist"

* docs: sort entries in MONOREPO.md

* docs: more README cleanup

* docs: add content from the wiki page "Contributing"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
developer-experience Issues affecting ease of use and overall experience of LB users Docs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants