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

Make some command docs clearer and more descriptive #4286

Closed
wants to merge 2 commits into from

Conversation

fiatjaf
Copy link
Contributor

@fiatjaf fiatjaf commented Dec 18, 2020

I was very confused with these descriptions that said only "a string that represents a psbt" and no examples of what that string looked like. I wanted to know if it was a base64 string or what (although maybe someone experienced with PSBT stuff would know already), so I made these things more explicit.

@fiatjaf
Copy link
Contributor Author

fiatjaf commented Dec 18, 2020

Made some similar changes in many other command docs with the intent of making them clearer and more descriptive.

@fiatjaf fiatjaf changed the title make base64 encoding clear in PSBT docs. Make some command docs clearer and more descriptive Dec 18, 2020
doc/lightning-sendpsbt.7.md Outdated Show resolved Hide resolved
doc/lightning-getinfo.7.md Outdated Show resolved Hide resolved
doc/lightning-getinfo.7.md Outdated Show resolved Hide resolved
doc/lightning-listnodes.7.md Outdated Show resolved Hide resolved
@ZmnSCPxj
Copy link
Contributor

Suggest mergning first and third commit into a single commit --- you could use git rebase -i.

@fiatjaf
Copy link
Contributor Author

fiatjaf commented Dec 21, 2020

Merged everything into a single commit.

doc/lightning-getinfo.7.md Outdated Show resolved Hide resolved
Copy link
Contributor

@niftynei niftynei left a comment

Choose a reason for hiding this comment

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

Everything except the PSBT change is a NACK from me. You're removing important type information from these descriptions (string, integer, etc)

@@ -11,7 +11,7 @@ DESCRIPTION

The **ping** command checks if the node with *id* is ready to talk. It accepts the following parameters:

- *id*: A string that represents the node id;
- *id*: Hex-encoded pubkey of the target node;
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
- *id*: Hex-encoded pubkey of the target node;
- *id*: A string, hex-encoded pubkey of the target node;

Copy link
Contributor Author

Choose a reason for hiding this comment

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

How can a "hex-encoded something" not be a string?

Copy link
Contributor

Choose a reason for hiding this comment

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

432421 ?

@@ -33,7 +33,7 @@ RETURN VALUE

On success, the command will return an object with a single string.

- *totlen*: A string that represents the answer length of the reply message (including header)
- *totlen*: The length of the reply message (including header)
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
- *totlen*: The length of the reply message (including header)
- *totlen*: A string, length of the reply message (including header)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is not a string. See example below.

Copy link
Contributor

@niftynei niftynei Dec 21, 2020

Choose a reason for hiding this comment

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

Good point.

Suggested change
- *totlen*: The length of the reply message (including header)
- *totlen*: Integer. The length of the reply message (including header)

@@ -26,21 +26,21 @@ RETURN VALUE

On success, the command will return a list of transactions, each object represents a transaction, with the following details:

- *hash*: A string that represents the hash of transaction, which the caller can use to find it on the blockchain.
Copy link
Contributor

Choose a reason for hiding this comment

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

You're stripping the type information from these descriptions. NACK.

Copy link
Contributor Author

@fiatjaf fiatjaf Dec 21, 2020

Choose a reason for hiding this comment

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

The types were wrong in many places. They said "a string that represents whatever" a million times, but very often the type was actually a number. And there was no reference whatsoever to what was the encoding or format of the "string".

What I tried to do was to make the descriptions more readable and more helpful, but not necessarily containing all the possible details.

I actually think I should have removed more of these types, because there are examples right below these descriptions and in the examples the type is much clearer.

Copy link
Contributor

Choose a reason for hiding this comment

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

The types were wrong in many places.

If the types are wrong, they should be fixed.

but not necessarily containing all the possible details.

The point of documentation is to be both clear and contain all relevant details.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The relevant details are in the examples.

Co-authored-by: Christian Decker <decker.christian@gmail.com>
@fiatjaf
Copy link
Contributor Author

fiatjaf commented Dec 24, 2020

You're really not going to merge this even though it is a clear and obvious improvement just because I've removed some "string" notes from fields that are obviously strings and other "string" notes from fields that are integers?

@fiatjaf
Copy link
Contributor Author

fiatjaf commented Dec 24, 2020

None of the other command docfiles files have this "type information" @niftynei wants so much, not even those of her own authorship. Most don't even have examples like the ones I've modified have.

@niftynei
Copy link
Contributor

niftynei commented Dec 24, 2020

Hi @fiatjaf. It seems your latest comments are missing some context, namely that you'd like to know what it would take for me to change my NACK to an ACK.

As it stands currently, this PR removes type information from the description fields of the RPC documentation. Restoring the type information to the descriptions would be an ACK from me.

@fiatjaf
Copy link
Contributor Author

fiatjaf commented Dec 26, 2020

You are being unreasonable and ignoring my comments above, but fine. I don't know why I should care about making these docs better anyway.

@fiatjaf fiatjaf closed this Dec 26, 2020
@fiatjaf fiatjaf reopened this Jan 7, 2021
@fiatjaf
Copy link
Contributor Author

fiatjaf commented Jan 7, 2021

I'll leave this open in case someone wants to build on it.

@rustyrussell
Copy link
Contributor

But @niftynei is right. JSON coders expect type info. I like the clarification, but dislike the removal.

We could formalize these into a format like "fieldname: type. Description...".

@vincenzopalazzo
Copy link
Contributor

I'm sorry if I jump in the game late, I think that some errors in these docs are my fault, and I'm sorry for that. But it is not easy make check when you need a screen reader to read the documents.

None of the other command docfiles files have this "type information"

I added the documentation of these commands with JSON examples with a point to make the description of the command easy
also for people out of this world. I proposed this format with this issue #3874

As Rusty calls the JSON coders :-D care only about the JSON format, but also sometimes the JSON is more readable for the people with no experience in this world or with some problems like dyslexia. So, I would be happy to have some redundancy inside the documentation such as have some obvious descriptions.

We could formalize these into a format like "fieldname: type. Description...".

Concept ack.

I agree to have a standard in the documentation description.

@niftynei
Copy link
Contributor

niftynei commented May 5, 2021

Closing in favor of #4501

@niftynei niftynei closed this May 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants