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

emphasize deprecation [documentation tweak] #22278

Closed
wants to merge 1 commit into from

Conversation

MichaelChirico
Copy link
Contributor

@MichaelChirico MichaelChirico commented Aug 30, 2018

Was poking around documentation for formals of this method as I'd seen it recommended and completely missed the Deprecated tag; even after seeing elsewhere it's deprecated, I stared at the documentation for far too long before noticing the existing tag.

So, adding this to emphasize further

Was poking around documentation for `formals` of this method as I'd seen it recommended and completely missed the `Deprecated` tag; even after seeing elsewhere it's deprecated, I stared at the documentation for far too long before noticing the existing tag.

So, adding this to emphasize further
@MichaelChirico MichaelChirico changed the title emphasize deprecation emphasize deprecation [documentation tweak] Aug 30, 2018
@AmplabJenkins
Copy link

Can one of the admins verify this patch?

@HyukjinKwon
Copy link
Member

I think there are many same instances. We should fix them everywhere consistently. But I don't think it's worth enough fixing everywhere. It's marked as deprecated and so it's deprecated, isn't it?

@MichaelChirico
Copy link
Contributor Author

@HyukjinKwon this is about usability/user-friendliness. As mentioned, despite being a seasoned R user & increasingly familiar with SparkR documentation, I spent several minutes googling about before realizing the existing "marking".

Happy to try and help file this patch somewhere else if you see fit; just filed here because it's a very easy fix & could be done in-browser without cloning locally/etc

@HyukjinKwon
Copy link
Member

If this is the only one, we could try to think differently but I guess there are multiple APIs documented like this. They are all consistently marked in the documentation and in the cod in this way. Unless there's a strong reason to change this kind of convention, I wouldn't fix those.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants