๐๐ฏ๐ผ๐๐ ๐-๐๐๐๐ผ ๐ฐ๐ผ๐บ๐บ๐๐ป๐ถ๐๐ :- We have developed a community to promote Learning By Doing, no matter, what your branch is or from which college you belong.What you need here is a passion for your interests in learning and implementing technology related stuffs. We will act as facilitators while anyone joining this community acts as a volunteer.โ The soul aim of this initiative is to bring together all the tech heads, who are committed to enhance their knowledge,so as to promote collaborative learning and problem solving. We will be having virtual discussions on different topics of concern.Alongwith it ,we will be constantly sharing important information from various resources.๐
This ๐ถ๐๐๐ซ๐๐๐ถ๐๐๐จ๐๐๐ is a series that we are conducting here on GitHub as a part of L-ByDo Community. You will have algorithms to solve each day, code it in whatever language you are comfortable with and upload your file here on https://github.com/L-ByDo/OneDayOneAlgo .
๐๐ผ๐ป๐๐ฟ๐ถ๐ฏ๐๐๐ถ๐ผ๐ป ๐ด๐๐ถ๐ฑ๐ฒ๐น๐ถ๐ป๐ฒ๐:-
1.๐พ๐ค๐ข๐ข๐ช๐ฃ๐๐๐๐ฉ๐๐ฃ๐ ๐๐๐๐๐๐ฉ๐๐ซ๐๐ก๐ฎ: Whether youโre a one-time contributor or trying to join a community, working with others is one of the most important skills youโll develop in open source. 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.
(a).๐ฎ๐๐๐ ๐ช๐๐๐๐๐๐ : 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. If youโre suggesting a new idea, explain why you think itโd be useful to the project (not just to you!).
(b).๐ซ๐ ๐๐๐๐ ๐๐๐๐๐๐๐๐ ๐๐๐๐๐๐๐๐๐๐ : 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 answer. People will appreciate when you demonstrate that youโre trying to learn.
(c).๐ฒ๐๐๐ ๐๐๐๐๐๐๐๐ ๐๐๐๐๐ ๐๐๐ ๐ ๐๐๐๐๐: Much like sending an email, every contribution, no matter how simple or helpful, requires someone elseโs review. Many projects have more incoming requests than people available to help. Be concise. You will increase the chance that someone will be able to help you.
(d).๐ฒ๐๐๐ ๐๐๐ ๐๐๐๐๐๐๐๐๐๐๐๐๐ ๐๐๐๐๐๐: Although itโs tempting, donโt reach out to maintainers privately unless you need to share sensitive information (such as a security issue or serious conduct violation). When you keep the conversation public, more people can learn and benefit from your exchange. Discussions can be, in themselves, contributions.
(e).๐ฐ๐โ๐ ๐๐๐๐ ๐๐ ๐๐๐ ๐๐๐๐๐๐๐๐๐ (๐๐๐ ๐๐ ๐๐๐๐๐๐๐!): Everybody was new to the project at some point, and even experienced contributors need to get up to speed when they look at a new project. By the same token, even longtime maintainers are not always familiar with every part of the project. Show them the same patience that youโd want them to show to you.
(f).๐น๐๐๐๐๐๐ ๐๐๐๐๐๐๐๐๐ ๐ ๐๐๐๐๐๐๐๐: Your ideas may differ from the communityโs priorities or vision. They may offer feedback or decide not to pursue your idea. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will. If you disagree with their direction, you can always work on your own fork or start your own project.
(g).๐จ๐๐๐๐ ๐๐๐, ๐๐๐๐ ๐๐ ๐๐๐๐๐๐: Open source is made up of collaborators from all over the world. Context gets lost across languages, cultures, geographies, and time zones. In addition, written communication makes it harder to convey a tone or mood. Assume good intentions in these conversations. Itโs fine to politely push back on an idea, ask for more context, or further clarify your position. Just try to leave the internet a better place than when you found it.
2.๐๐๐ฉ๐๐๐ง๐๐ฃ๐ ๐๐ค๐ฃ๐ฉ๐๐ญ๐ฉ: Before doing anything, do a quick check to make sure your idea hasnโt been discussed elsewhere. Skim the projectโs README, issues (open and closed), mailing list, and Stack Overflow. You donโt have to spend hours going through everything, but a quick search for a few key terms goes a long way. If you canโt find your idea elsewhere, youโre ready to make a move. If the project is on GitHub, youโll likely communicate by opening an issue or pull request:
(a).Issues are like starting a conversation or discussion (b).Pull requests are for starting work on a solution
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 Before you open an issue or pull request, check the projectโs contributing docs (usually a file called CONTRIBUTING, or in the README), to see whether you need to include anything specific. For example, they may ask that you follow a template, or require that you use tests. If you want to make a substantial contribution, open an issue to ask before working on it. Itโs helpful to watch the project for a while (on GitHub, you can click โWatchโ to be notified of all conversations), and get to know community members, before doing work that might not get accepted.
3.๐๐ฅ๐๐ฃ๐๐ฃ๐ ๐๐ฃ ๐๐จ๐จ๐ช๐: You should usually open an issue in the following situations:
(a).Report an error you canโt solve yourself (b).Discuss a high-level topic or idea (for example, community, vision or policies) (c).Propose a new feature or other project idea
Tips for communicating on issues:
(a).If you see an open issue that you want to tackle, comment on the issue to let people know youโre on it. That way, people are less likely to duplicate your work. (b).If an issue was opened a while ago, itโs possible that itโs being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work. (c).If you opened an issue, but figured out the answer later on your own, comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project.
4.๐๐ฅ๐๐ฃ๐๐ฃ๐ ๐ ๐ฅ๐ช๐ก๐ก ๐ง๐๐ฆ๐ช๐๐จ๐ฉ: You should usually open a pull request in the following situations:
(a).Submit trivial fixes (for example, a typo, a broken link or an obvious error) (b).Start work on a contribution that was already asked for, or that youโve already discussed, in an issue (c).A pull request doesnโt have to represent finished work. Itโs usually better to open a pull request early on, so others can watch or give feedback on your progress. Just mark it as a โWIPโ (Work in Progress) in the subject line. You can always add more commits later.
If the project is on GitHub, hereโs how to submit a pull request:
(a).Fork the repository and clone it locally. 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. (See more detailed instructions here.) (b).Create a branch for your edits. (c).Reference any relevant issues or supporting documentation in your PR (for example, โCloses #37.โ) (d).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. (e).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. (f).Contribute in 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, others to understand and maintain in the future.
๐๐๐ ๐ ๐๐ ๐๐ !! ๐ฏ Whether you just made your first open source contribution, or youโre looking for new ways to contribute, we hope youโre inspired to take action.