Finish and improve the documentation

[daviddias]

No description provided.

[victorb]

I'm currently redoing the readme a bit. You could assign me if you please.

[daviddias]

awesome! Thank you @victorbjelkholm

@jbenet is the one able to assign people on orgs/repos

[jbenet]

@victorbjelkholm ok you are part of the github node-ipfs team now. please do not merge things, or push straight to master (unless you maintain the project) please use a branch on the same repo and issue a PR and get the repo maintainer to review and then merge it

[jbenet]

Actually, i added you directly to this repo instead, as you need more access will bump it up

[jbenet]

@diasdavid you now have admin on all these repos so you should be able to add people.

[daviddias]

Thanks @jbenet :)

[daviddias]

Note on: #33 (comment) to be added to the docs

[RichardLitt]

@victorbjelkholm How's this going? Is there anything I can help with?

[victorb]

@RichardLitt Hey! Yes, of course. I've made the structure to be proper but have yet to fill out all the details with calls. Take a look in my branch (that currently have to be rebased from master but have yet to get time to do that) https://github.com/VictorBjelkholm/node-ipfs-api/tree/better-readme

Basically, the only thing I've done is added a ToC, changed the structure and made the wording a bit better.

[dignifiedquire]

Just a note, might make sense to have a separate api.md document with those details and just a link from the readme, to keep readme at a reasonable length.

[victorb]

That sounds much more reasonable actually. Maybe just a quick introduction
in the readme and refer to them from it.

Sincerely,
Victor Bjelkholm
(+34) 672 15 90 89

On Mon, Oct 12, 2015 at 7:49 PM, Friedel Ziegelmayer <
notifications@github.com> wrote:

Just a note, might make sense to have a separate api.md document with
those details and just a link from the readme, to keep readme at a
reasonable length.

—
Reply to this email directly or view it on GitHub
#58 (comment).

[RichardLitt]

@victorbjelkholm Cool! Maybe rebase ,switch it to api.md, make sure no current information is lost, and then form a PR? That way we can hypothetically do it piecemeal and faster.

[daviddias]

@victorbjelkholm any updates on this? It might help to open a branch on this repo for the docs and then open a PR, so that you and @RichardLitt can collaborate (without having to PR to the other private PR)?

[victorb]

@diasdavid @RichardLitt Hey, sorry about the slowness on this, while creating the documentation, I found some issues with the response values that didn't make sense. I'll push my changes to this repository and open a PR when I'm available, so we can work together on this one.

Sorry again about the delay and kind of forgetting about this.

[RichardLitt]

No worries. Keep us updated.

[daviddias]

@victorbjelkholm can you point us to that branch? @RichardLitt was looking for it and is interested in shipping that with you :)

[victorb]

@diasdavid @RichardLitt PR Made! ^

[daviddias]

sweet!

[RichardLitt]

@victorbjelkholm That is awesome! Asked a question there about it. Looks great, so far.

[daviddias]

Update: We've new documentation coming with the upgrade to the 0.4.0 compatible js-ipfs-api (#74) and a spec for the http-api itself https://github.com/ipfs/http-api-spec.

[daviddias]

This has improved significantly over time (https://github.com/ipfs/js-ipfs-api/blob/master/API.md) and now we enroute to have a proper core-spec which will make it clear how the js-ipfs-api works for everyone. Closing this issue.