Improved upto 1-js\02-first-steps\13-while-for

[mohitgedar]

changed files and about changes

1. js/first steps/hello world/artical.md

Improved readability of old content and add one new para which tells where to place <script> tag in

2. 1-js\02-first-steps\07-type-conversions\article.md

Improved the readability of the content but stating things clearly in simple words.

3. 1-js\02-first-steps\08-operators\article.md

Added details about use of comma operator with examples , also improved readability of the page by explain some content more clearly , also modified reference to code lines by referencing them directly because we see line no. of code automatically , there is not need to mark them separately.

4. 1-js\02-first-steps\08-operators\3-primitive-conversions-questions\solution.md

here I removed special marking to code lines because we automatically get line no. on the website. also i provided explaination for all the example in the code.

5. 1-js\02-first-steps\09-comparison\article.md

I updated this file so that some content is explained clearly.

6. 1-js\02-first-steps\09-comparison\1-comparison-questions\solution.md and task.md

In these files I have added more examples and explained previous ones in detail.

7. 1-js\02-first-steps\10-ifelse\article.md

I have updated this file with minor changes to explain things better and clearly

8. 1-js\02-first-steps\11-logical-operators\article.md

modified a JS code to improve readability

9. 1-js\02-first-steps\11-logical-operators\9-check-login\solution.md

modified this file's code to use const instead of let and explained it ,because we won't be modifying the variables later

10. 1-js\02-first-steps\13-while-for\article.md

I have made major changes to this file , added examples which were needed but not given , added some more sections such as 'Understanding loops' to generally explain loops , "Multiple Labels and Breaking Nested Loops" to explain how deeply nested loops can be labelled. also made some minor changes to match with general term of Js.

11. 1-js\02-first-steps\14-switch\article.md

Improved a code example, corrected a markdown error ,improved readability for one line , added a note to explain where a default can be placed in the switch and using break with it , added one another note to recommend using curly brace to put together all the statements of a switch case.

12. 1-js\02-first-steps\15-function-basics\article.md

I have updated this file to make this more clear and easily understandable , also added details about call by value/call by reference in JS. At one place i remove a duplication (not exactly same ,but could be combined) regarding use of default. Also added rules to pick a name for function.

13. 1-js\02-first-steps\16-function-expressions\article.md

When I read this chapter I felt like I am always searching for the content , it was not well arranged , and when new topics started their clear explanation was not provided. So I have rearranged the content in topics and sub topics , also provided clear explanations of topics such as callbacks , also added explanation for new terms such as Hoisting

14. 1-js\02-first-steps\17-arrow-functions-basics\article.md

the variables created inside let A =(var1 , var2 , ... , varN ) => { //code } should be termed as parameters not arguments

[CLAassistant]

All committers have signed the CLA.

[mohitgedar]

@smith558 please let me know if my changes are acceptable and makes the project better overall as I would like to work further on the project ,making it simple to understand and easy to grasp.

[mohitgedar]

@smith558 hey any update ? did you check the changes ?

[smith558]

@smith558 hey any update ? did you check the changes ?

This one is next in the queue.

[joaquinelio]

Wow
Please dont. Too many issues. I'd reject the entire PR.
I'll explain why later

[mohitgedar]

Wow Please dont. Too many issues. I'd reject the entire PR. I'll explain why later

Hello,
Did I made the PR too big , or my changes are incorrect ?
can you elaborate please what kind of issues are there?
If there are some changes required or some changes to be dropped , I can do that .
Do let me know.

[joaquinelio]

Sorry for the delay.
Sorry for the tone too, I'm 65 and my job is, I NEED TO, point out the darker side of things...
...I hope this doesn't discourage you, you're, maybe, on the right track.

I started listing issues, but they are not so helpful without long explanations
So, I'm changing the approach. This comment will focus on the maintainers' perspective.

Read this as if you were an alien lang maintainer. You'll understand.

• Massive PRs are hard to review (and GET reviewers), hard to adjust, and get final approval.
  1 File, 1 PR
  Or
  1 issue, 1 PR

• Precisely labeled PRs help maintainers focus. Not the same "typo/grammar" or "readability."

• Don't change line numbering unless removing or adding specific info. It's an specific issue on translated texts, git sometimes fails in tracking them.

• Avoid multiline changes as much as possible. Consider this: Eng to Eng is easy, you see the changes in different color right away. In a translated text, what you see is a BIG local colored text and a BIG English text with no clue of what's changed (ok, there are tools to match/track original commits, but it means extra work and I bet not many use them).

Extra toughs

I learned this contributing to this repo, so I hope this opens your mind too.

About specific changes,
I learned (barely) not to be perfectionist.

Being spanish js maintainer,
I learned I could help more and speed the process by fixing bottlenecks and doing more reviews than writing my own.

Hope this helps.

[joaquinelio]

I'm partially wrong about translated repos

Using the bot merge, all the pr are combined in a single bot's PR, thats why I used to frecuently make my own merges.

Being labeled "readability", i can dismiss all the changes without feeling guilty...

Still,
Line numbering and multiline changes are a pain for translated repos.

[joaquinelio]

I cannot review grammar, I'm not native English speaker.

Couple of things in a quick review.

I prefer the
"Intuitively empty" explanation rather than the hard list of things considered empty.
Maybe adding the non zero string length case.

Parameter is part of the definition of the function,
Arguments is the correct word for the values you pass into the function

Backticks format reserved words, you used them indiscriminately in many places
infinite loop + break
Is wrong format, the original is ok
infinite loop + break

I remember a let to const replacement pr rejected by Illya, i cant remember if he gave a reason
Maybe he tried to keep "first steps" clean.
No need to overcharge first steps with info and explanations.

Again,
Too many issues in a single pr.
Hard to follow.

[mohitgedar]

Hi @joaquinelio,

Thank you for your detailed feedback and for clarifying your perspective. I appreciate your insights on managing PRs effectively.

Now that I look at my PR, I realize that I didn’t explain my changes in a precise manner and instead provided more general explanations. I also understand that since this repo is translated into other languages, changes in one repository need to be reflected across others, making it challenging to manage large PRs with significant alterations. I understand now that large PRs can be hard to review, and breaking changes into smaller, more focused submissions would be more beneficial for reviewers. I’ll make sure to keep my future contributions more streamlined and specific, ideally tackling one issue or topic at a time.

Regarding the specific points you mentioned:

• I appreciate the reminder about not overloading the "first steps" section with too much detail.
• I didn’t realize that backtick formatting was specifically used to highlight keywords. I had assumed they were used to emphasize elements that are not part of a sentence or to highlight important data.
• My commit regarding arguments/parameters was intended to clarify that parameters are part of the function definition, while arguments are the values passed into the function. Currently, they are often used interchangeably, which can lead to confusion.

If I may suggest, while I’m still learning, I believe having a clear contributions guideline could be very helpful for contributors. It might assist in understanding the format and best practices to follow.

Moving forward, should I close this PR and create smaller, more focused ones with the bare minimum changes I believe should be made? Or would it be better to modify this PR to address the points you raised?

If you have additional thoughts or specific examples of what could be improved, I’d love to hear them.

Thank you again for your guidance! I’m eager to refine my contributions and make the project better overall.