Apply suggestions from code review

Co-authored-by: Mrunal Patel <mrunalp9@outlook.com>

sig-node/CONTRIBUTING.md

@@ -3,11 +3,11 @@
 Welcome!
 
 Thank you for your interest in contributing to SIG Node. SIG Node is one of the biggest SIGs in Kubernetes.
-Reliability and performance of millions of nodes running critical applications in production rely on a quality of your contribution.
-The diversity of workloads, environments, and scale SIG Node needs to support make every code change risky as every side effect needs to be evaluated.
-And the contribution is and realistically can be only evaluated by a small set of maintainers.
+Reliability and performance of millions of nodes running critical applications in production rely on the quality of your contribution(s).
+The diversity of workloads, environments, and the scale SIG Node needs to support makes every code change risky as all the side effects need to be evaluated.
+And the contribution can realistically only be evaluated by a small set of maintainers.
 
-Please make sure you understand and accept the challenge. Contributing instructions are designed to help you.
+Please make sure you understand and are up to the challenge. The contributing instructions are designed to help you.
 
 ## For Kubernetes Code Contributions
 
@@ -17,21 +17,21 @@ If you aspire to grow scope in the SIG, please review the [SIG Node contributor
 
 ### For Enhancements
 
-Find out if [your thing is an enhancement a.k.a KEP](https://github.com/kubernetes/enhancements/?tab=readme-ov-file#is-my-thing-an-enhancement).
+Find out if [your thing is an enhancement a.k.a KEP](https://github.com/kubernetes/enhancements/?tab=readme-ov-file#is-my-thing-an-enhancement). A good way to do that is to open and issue and get feedback from node reviewers and approvers. You can even come present your idea at a weekly sig-node meeting.
 
 If you plan to contribute an enhancement, please prepare yourself for at least 1 year of engagement.
-In order to progress a KEP via all stability stages, at a minimum 3 Kubernetes releases needs to be worked on.
+A KEP takes atleast 3 kubernetes releases to move from alpha to beta to GA. If there are API / kubelet skew considerations, it may take even longer. 
 SIG Node expects contributors to commit to land a KEP to GA stage to avoid [permanent betas](https://kubernetes.io/blog/2020/08/21/moving-forward-from-beta/#avoiding-permanent-beta).
 It is always surprising how much work is needed to productize the feature after it is seemingly complete.
 
-If you are not ready for this commitment, you can often team up with other contributors in community or contribute
-to KEP driven by somebody else.
+If you are not ready for this commitment, you can consider teaming up with other contributors in the community or contribute
+to a KEP driven by somebody else.
 
 SIG Node enhancements are available:
 - Committed KEPs [directory](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node)
 - All open KEPs [tracking issues](https://github.com/kubernetes/enhancements/issues?q=is%3Aissue+is%3Aopen+label%3Asig%2Fnode+)
 
-What is following are some best practices how to approach KEP development.
+Here are some best practices how to approach KEP development:
 It is based on a [talk](https://kcsna2023.sched.com/event/1Sp9i/implementing-a-big-feature-on-an-example-of-a-sidecar-container-kep) 
 *"Implementing a big feature on an example of a Sidecar container KEP"*
 ([Recording](https://www.youtube.com/watch?v=c3iV8E8EDUA), [Slides](https://static.sched.com/hosted_files/kcsna2023/a0/KCS-NA-2023-ppt.pdf)).
@@ -46,7 +46,7 @@ It is based on a [talk](https://kcsna2023.sched.com/event/1Sp9i/implementing-a-b
 At this stage the expectation is that the proposal is written in general-enough terms as a Google Doc for easy commenting and fast collaborative editing.
 Sharing the design document with `dev@kubernetes.io` for commenting and with SIG members `kubernetes-sig-node@googlegroups.com` for commenting or in some cases editing is a good practice.
 
-It is also very helpful to attend SIG Node weekly meeting to present your proposal. Most of the time meeting agenda is open for any proposals.
+It is also very helpful to attend SIG Node weekly meeting to present your proposal. Most of the time meeting agenda is open to discuss any proposals.
 During the meeting you can gather initial feedback, find collaborators, and secure sponsorship.
 
 #### API Design
@@ -64,7 +64,7 @@ API approvers may reject the proposal and ask to redesign it.
 
 Some KEPs may go back and forth between use cases and API design for many iterations.
 This often happens when use cases are not described completely or a lot of context is lost in written feedback.
-If the KEP is going in those circles, the recommendation is to request the meeting between SIG Approvers and API approvers driven by KEP author.
+If the KEP is going in those circles, the recommendation is to request a meeting between SIG Approvers and API approvers driven by KEP author.
 It may be a dedicated meeting or an invite of API approvers to SIG Node weekly meeting or SIG Node approvers to API meeting.
 
 Once API approval was received, SIG Node approvers will review it again as SIG always has the last word in the feature design.