[MINOR][DOCS] Fix minor typos at nulls_option in Window Functions

[bfallik]

What changes were proposed in this pull request?

Fix a typo: RESECT -> RESPECT.

Why are the changes needed?

RESECT isn't a valid term here

Does this PR introduce any user-facing change?

Yes, the typos in the docs are corrected.

How was this patch tested?

inspection via the Github UI

[itholic]

Could you make the test pass by allowing Github Actions in your forked repository ??

Please refer to https://github.com/apache/spark/pull/35774/checks?check_run_id=5467958735.

[itholic]

And for "Does this PR introduce any user-facing change?", I think we have user-facing change since we fix the typo in the documentation which users can read.

So, maybe we can simply say like, "Yes, the typo in documentation is corrected" or something.

[bfallik]

@itholic after enabling github actions on my private repo, how do I rerun the failed check? I don't see any obvious way to do it within the GH UI.

[itholic]

Here is an example:

1. Click the "Details" on the failed test (Build and test for your case)

2. Click the "See test results" on the right side.

3. Click the "Re-run all jobs" on the right-above side, then now you can rerun the tests.

Or, you can just push the empty commit to rerun the test via git commit --allow-empty command

[AmplabJenkins]

Can one of the admins verify this patch?

[bfallik]

@itholic looks like the tests all pass now

[itholic]

Great! BTW, also we should follow the contribution guideline from community.

Can you create a related Apache Spark JIRA and fix the title ??

And I think maybe we would move the description "I'm just learning Spark but am assuming that these code examples refer to the RESPECT NULLS syntax called out just below." to under "Why are the changes needed?" or just remove.

You can also refer to other PRs as reference :-)

[bfallik]

Hi @itholic ,

Please know that I appreciate all the hard work, often thankless, that project committers undertake to try and manage community activity into a sensible workflow, but this is starting to feel like a lot of back-and-forth for a documentation change to correct an obvious misspelling.

I did review the contribution guidelines before posting this PR. The section on "Contributing documentation changes" says

To propose a change to release documentation (that is, docs that appear under https://spark.apache.org/docs/), edit the Markdown source files in Spark’s docs/ directory, whose README file shows how to build the documentation locally to test your changes. The process to propose a doc change is otherwise the same as the process for proposing code changes below.

and, notably, the section on "Contributing code changes" says

2. If the change is new, then it usually needs a new JIRA. However, trivial changes, where the what should change is virtually the same as the how it should change do not require a JIRA. Example: Fix typos in Foo scaladoc

I read that example and assumed this trivial change didn't need a JIRA ticket.

I'll go ahead and edit the description to address your most recent suggestion. Appreciate your help getting the automated checks to pass.

Thanks.

[itholic]

@bfallik That makes sense to me. Thanks for the update description!

[itholic]

cc @HyukjinKwon I think maybe we could just merge this trivial patch?

[HyukjinKwon]

Merged to master.