-
Notifications
You must be signed in to change notification settings - Fork 912
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
Conversation
Made some similar changes in many other command docs with the intent of making them clearer and more descriptive. |
Suggest mergning first and third commit into a single commit --- you could use |
750d8a0
to
01c111c
Compare
Merged everything into a single commit. |
There was a problem hiding this 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; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- *id*: Hex-encoded pubkey of the target node; | |
- *id*: A string, hex-encoded pubkey of the target node; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- *totlen*: The length of the reply message (including header) | |
- *totlen*: A string, length of the reply message (including header) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point.
- *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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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>
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? |
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. |
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 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 |
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. |
I'll leave this open in case someone wants to build on it. |
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...". |
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.
I added the documentation of these commands with JSON examples with a point to make the description of the command easy 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.
Concept ack. I agree to have a standard in the documentation description. |
Closing in favor of #4501 |
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.