𝗔𝗯𝗼𝘂𝘁 𝗟-𝗕𝘆𝗗𝗼 𝗰𝗼𝗺𝗺𝘂𝗻𝗶𝘁𝘆 :- 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.