Challenge 1-30 : krati5

[krati5]

name: Krati Yadav github_user_name: krati5

[krati5]

Forked Repo URL: https://github.com/krati5/scaler-september-open-source-challenge

[krati5]

Screenshots of all the branches in my forked repo:

[krati5]

Day 4 - Upstream

[krati5]

Day 9 completed

[krati5]

challenge 11

[krati5]

challenge 13

[krati5]

challenge 14

[krati5]

Challenge 15

[krati5]

challenge 16

[krati5]

challenge 17

https://github.com/krati5/github-repo

Created new repo and branch using GitHub Desktop.

Created a new branch:

Created a new file myname.txt in the folder and checked the changes through github desktop application

Created a partial commit in krati-test branch using github

Published the repo Pulled from origin and pushed to origin/krati-test branch

Pushed the remaining code :

Deleting the file myname.txt

Stashing the changes

Discarding the stash

[krati5]

challenge 18 - Gist Creation

https://github.com/scaleracademy/scaler-september-open-source-challenge/pull/737

Created 2 gists

created gist-solutions.md containing these 2 links and pushed it

[krati5]

Challenge 20

Project Board Link : https://github.com/users/krati5/projects/1/views/1 GITHUB Repo Link: https://github.com/krati5/test-repo/tree/main

Created GITHUB Board :

Moved Item from To Do to In Progress

Moved Item from In Progress to Done

[krati5]

Challenge 21

4 Alias created :

Alias used:

[DaltonDeven]

Verified for milestone-2 congrats ✅

[krati5]

Challenge 23

Git Branching Naming Convention

Git branching strategies allow separation of work.

1. start branch name with a Group word like "bug" or "wip" based on the type of task we are working on
2. use issue id in branch names - for example: jira ids if the issues are created in Jira in your work
3. Use Hyphen as separators to make the name easier to read, use hyphens. eg: bug-fix-submit-button instead of bugfixsubmitbutton
4. we can also include developer name . eg:
5. Don't just use issue number, it creates confusion and provides no information on why the branch was created
6. Don't use all naming conventions, it can make the branch name too long and very complicated to understand
7. Use short names for branches

These can be categorized into Regular Branching and Temporary Branching

Regular Branching

1. master branch: it is the default branch of GIT and this branch doesn't allow direct check-ins. Code should be merged with master after code review ONLY.
2. dev branch : This is mainly used by developers to make any new changes in the code. Once the changes have been made, testing is performed on this branch and then after the final code review, a pull request is created to the Master branch and the changes are merged with master
3. QA or test branch: It contains code for QA testing and automation testing of all changes implemented. Before any change goes to the production, it must undergo QA testing to get a stable codebase.

Temporary Git Branches

These are branches that can be created and deleted after the task is complete. Some examples:

1. Bug Fix - Created to fix a bug
2. Hot Fix
3. Feature Branches
4. Experimental Branches
5. WIP branches - Work in Progress branches

Building a Pull Request

Below are some of the tips that can be followed to create clear pull requests

1. Naming the feature branch : Use well defined name for the branch to segregate the branches, If there are multiple developers working on the same repository, try using author name at the beginning of the branch.
2. Give good descriptive commit messages and pull request title so it is easier to understand what work is in this pull request. Also, it's better to use present tense instead of past tense these
3. Start your PR with WIP title if you are still working on it to avoid anyone actually merging it by mistake
4. Try to include screenshots in your PR
5. Review your PR before you assign it to someone else. Make sure that your branch has no conflict with master branch, use Lint to make your code easier to read, perform sanity-check.

CONTRIBUTION GUIDELINES

Before contributing into any repository first check out the guideliness of How to contribute inside the repository. You can find it in the README.md file or there will be a separate CONTRIBUTE.md file. Go through it and follow it.

Use GitHub issues associated with each project to track the work associated with that project. make extensive use of issue labels to designate the priority, status and beginner-friendliness of various issues

CONTRIBUTION PROCESS

Once you've found an issue you'd like to work on:

1. Comment on it and say you're working on that issue. This is to avoid conflicts with others also working on the issue.
2. Write your code and submit your pull request
3. Wait for code review and address any issues raised as soon as you can.
4. However, if staff-only label is there then you are not allowed to contribute as these are for the staff only.

PROPOSING A NEW ISSUE

If you want to work on something that there is no GitHub issue for.

1. Create a new GitHub issue associated with the relevant repository and propose your change there. Be sure to include implementation details and the reason for the proposed change.
2. Use good first issue or help wanted if you are first time contributor.

[krati5]

Challenge 24

Checked the good first issues on https://goodfirstissue.dev/language/python

Found an issue which is related to my technical skills and I have commented on it if I can contribute:

https://github.com/wagtail/wagtail/issues/6611#issuecomment-1256986090

[krati5]

challenge 25

1. I have received a comment on the issue on which I had commented yesterdat. I am going through the changes made by another developer in an existing pull request on this issue and will start working on it. https://github.com/wagtail/wagtail/issues/6611#issuecomment-1257063709

2. I have been assigned another issue, for which I have already ready a pull request, I am now waiting for it to get approved and merged. https://github.com/PrakashGatiyala/hackerrank_problems-or-hackerearth_problems/issues/127

[krati5]

Challenge-26

I have registered for hacktober fest.

Regarding the issues, I was working on

1. The author wanted some changes before the pull request could be merged. I had made the necessary changes and the pull request is now approved and merged.

https://github.com/PrakashGatiyala/hackerrank_problems-or-hackerearth_problems/pull/156 https://github.com/PrakashGatiyala/hackerrank_problems-or-hackerearth_problems/issues/127

2. Regarding the 2nd issue, I am still going through the existing pull request.

[krati5]

Challenge 27

What is open source ?

Open source software (OSS) is software that’s freely available to use, redistribute, and modify, typically shared via a public code repository hosting service.

Why contribute Open source ?

1. Improve the software you work on. If you find a bug in the software you are using, you can contribute the patch if it's an open source software and thus, helping you and millions of other users
2. Helps to enhance your own skills
3. Able to learn/teach more in a shared project
4. Build public artifacts that help you grow a reputation as open source work is public

Types of people in open source projects

1. Author: The person/s or organization that created the project
2. Owner: The person/s who has administrative ownership over the repository
3. Maintainers: Contributors who are responsible for managing the repo
4. Contributors: Everyone who has contributed something back to the project
5. Community Members: People who use the project. They might be active in conversations or express their opinion on the project’s direction

Types of documentation in open source projects

1. LICENSE: By definition, every open source project must have an open source license. If the project does not have a license, it is not open source.
2. README: The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started.
3. CONTRIBUTING: Whereas READMEs help people use the project, contributing docs help people contribute to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to.
4. Other documentation: There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects.

How to submit a contribution

Before you open an issue or pull request, or ask a question in chat, keep these points in mind to help your ideas come across effectively.

1. Give context. Help others get quickly up to speed. If you’re running into an error, explain what you’re trying to do and how to reproduce it.
2. Do your homework beforehand. It’s OK not to know things, but show that you tried. Before asking for help, be sure to check a project’s README, documentation, issues (open or closed), mailing list, and search the internet for an answe
3. Keep requests short and direct.
4. Keep all communication public
5. Respect community decisions.

Teminologies

1. Issues are like starting a conversation or discussion
2. Pull requests are for starting work on a solution
3. For lightweight communication, such as a clarifying or how-to question, try asking on Stack Overflow, IRC, Slack, or other chat channels, if the project has one

Opening a pull request in Github

If the project is on GitHub, here’s how to submit a pull request:

1. Fork the repository and clone it locally.
2. Connect your local to the original “upstream” repository by adding it as a remote. Pull in changes from “upstream” often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely.
3. Create a branch for your edits.
4. Reference any relevant issues or supporting documentation in your PR (for example, “Closes #37.”)
5. Include screenshots of the before and after if your changes include differences in HTML/CSS. Drag and drop the images into the body of your pull request.
6. Test your changes! Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don’t break the existing project.
7. Contribute to the style of the project to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, and others to understand and maintain in the future.

[krati5]

Challenge 28

I have picked up a issue which is in cookiecutter-django project. The task was to fix a bug which was being caused during production deployment using Sendgrid. I have created a pull request with the changes, however, I am still waiting for it to be reviewed.

Link of the Issue: https://github.com/cookiecutter/cookiecutter-django/issues/2560 Pull request : https://github.com/cookiecutter/cookiecutter-django/pull/3885

[krati5]

Challenge 29

Create a new discussion to share a new project idea.

[krati5]

Challenge 30

The issue I picked up in cookiecutter-django project has been successfully completed and merged with master. I am quite thrilled that I was able to contribute in a Django project repo which is massively used!

Link of the Issue: https://github.com/cookiecutter/cookiecutter-django/issues/2560 Pull request : https://github.com/cookiecutter/cookiecutter-django/pull/3885

With this, I finish my 30 days challenge and I am thankful to Scaler for giving me this opportunity to help me get into the open source world.

[Mrjoy832]

Milestone-4 done ✅