When I look at https://en.wikipedia.org/w/api.php?action=help&recursivesubmodules=1, I can't find any notes about keys such as userhidden, commenthidden, sha1hidden, and texthidden. This happens when revision suppression is used. Can we call these out specifically in any API module documentation where these *hidden keys are used? This note should also mention that "expected" keys such as user or sha1 will then be unavailable.
|mediawiki/core||master||+36 -36||Modify apihelp to include info about revision deleted parameters|
@MZMcBride: good first task tasks are self-contained, non-controversial issues with a clear approach and should be well-described with pointers to help the new contributor. Given the current short task description I'm removing the good first task tag. Please re-add the tag once the task description has been polished and provides sufficient information for a new contributor. Thanks!
We don't normally do much to describe the output fields. But if we want to do this, it would probably be most appropriate to describe them in the relevant prop option documentation.
I see @Legoktm said something similar on IRC:
<legoktm> We could mention it in the rvprop docs for each parameter
<legoktm> "user: User that made the revision. (note: if the user has been revision deleted, a "userhidden" property will be returned)
Sounds good to me.
If you think the task description here needs improvement, you're welcome to edit it. There's nothing wrong with a short task description. And, as I think you've now been told repeatedly here, tasks marked good first task do not need to mollycoddle users with, for example, exact file names and line numbers. This task, as a "non-code" documentation task, is pretty much the definition of good first task, so I'm re-adding the appropriate tag. Please do not remove it again. You were automatically subscribed to this ticket; if you have an issue here, remove yourself. Thanks.
I don't see any problems with the approach, or at a quick glance through the patch. I don't have time at the moment to give this one a full review; if you're confident that the change is good, feel free to merge.