Challenge#1-Rakshyak

[rakshyak-98]

name: rakshyak github_user_name: rakshyak-98 discord_id: rakshak1998

[rakshyak-98]

Challenge #2 https://github.com/rakshyak-98/scaler-open-source-september-challenge

[rakshyak-98]

Challenge #3

[rakshyak-98]

Challenge #4

[rakshyak-98]

[rakshyak-98]

Challenge 7

[rakshyak-98]

Challenge 9

[rakshyak-98]

Challenge 11

[rakshyak-98]

Challenge 10

[rakshyak-98]

Challenge 12

[rakshyak-98]

Challenge 13

[rakshyak-98]

Challenge 14

[rakshyak-98]

Challenge 15

[rakshyak-98]

Challenge 16

[rakshyak-98]

Challenge 17

[rakshyak-98]

Challenge 18

[rakshyak-98]

Challenge 19

[rakshyak-98]

Challenge 20

[rakshyak-98]

Challenge 21

[rakshyak-98]

Challenge 22

[rakshyak-98]

Challenge 23

[rakshyak-98]

Challenge 24

---

Naming Convention

Branch Naming

• avoid naming conventions simultaneously
• avoid log descriptive names for log-lived branches
• lint your code, use team established standard tools ex: scss-lint, tlint, prettier.
• two categories
  • Regular
  • Temporary

    Regular

• available in repository as permanent base.
• naming is simplet and straightforward ex. : dev, master, QA
  • dev : development branch, make changes in it and restrict the developers from making any changes in the master branch directly.
  • master : it should be stable all the time and won't allow any direct check-in.
  • QA : test branch, contain all code for QA testing and automation testing. Before any changes goes to the production environment, it must undergo the QA testing to get a stable codebase.

    Temporary

• these can be created and deleted when needed. ex. : bugfix, hotfix, feature, experimental, wip, release.

  Naming convention

  1. Start branch name with a group word
• bug : bug need to be fixed soon.
• wip : work in progress. development will not finish soon.

  example

• bug-logo-alignment-issue
• wip-ioc-container-added
  2. Use unique id in branches names issue tracker id can be used in branch name. Prefered when fixing some bugs, To be tracked bu external system.
• give the title a prefix like WIP or IN-PROGRESS, to avoid someone accidentally reviewing prematurely.

  example

• wip-8731-add-testing-module
  3. Use hyphen or slash as seprators

     example

• feature_upgrade_jquery_version_login_module
  4. Branch with Author name
• easy tracking of different developer's work and progress with additional system.
• can give prefix as name initials

  example

• <author>_<branch-type>_<branch-name>
  5. Use present imperative tense when naming

     example

• Fix-dashboard-typo instead of fixed or fixes
  6. Give PR a meaningful description
• providing a little extra context helps give your reviewer a clearer understanding of what they are about to be looking at.
• provide a bullet point list of the most important commits, expanding on each as necessary.

  Issues

• help wanted : participation from the community but not necessarily beginner-friendly
• good first issue : partifipation from the community and friendly towards new contributors
• staff only : requires infrastructure access or institutional knowledge that would be impractical to provide to community. Do not work on these.
• not open for community contribution. Do not work on these.
  • status: blocked : blocked by other work that need to be done first
  • status: ticket work required : needs additional work it is ready to be taken by
  • status: awaiting triage : has not been triaged by a maintainer

    Contribution process

    1. Comment on it and say you're working on that issue, this avoid conflicts with others also working on the issue.
    2. Write code and submit your pull reques. Read and follow pull request guidelines.
    3. Wait for code review and address any issues raised as soon as you can.

[rakshyak-98]

Challenge 25

its daily update, I have been searching in list of good first issue

[rakshyak-98]

Challenge 27