mirror of
https://github.com/LucasVbr/first-contributions.git
synced 2026-05-13 17:21:50 +00:00
Merge branch 'main' into main
This commit is contained in:
Roshan Jossy
@@ -122,3 +122,40 @@ Most of all, listen to what people around you discuss. See if you can recognize
|
||||
16. **Teach and Help others**:
|
||||
The best way to learn more about a topic is to try to teach it.
|
||||
The best teacher is the one who can explain complex stuff with simple examples. So you need to try to be the best teacher to be the best learner and the best in your programming world. Teaching others will make you feel better about yourself and it will help you get better skills and knowledge in your profession. When you get help from someone don't keep it to yourself share it with others. Make the world a better place to live.
|
||||
|
||||
17. **Improve Accessibility**
|
||||
- Audit project documentation/websites for:
|
||||
- Alt text for images.
|
||||
- Screen reader compatibility.
|
||||
- Suggest fixes for:
|
||||
- Color contrast.
|
||||
- Keyboard navigation.
|
||||
- Semantic HTML.
|
||||
|
||||
18. **Organize Community Events**
|
||||
- Help organize:
|
||||
- Virtual meetups or hackathons.
|
||||
- "Ask Me Anything" (AMA) sessions with maintainers.
|
||||
- Moderate forums/Discord/Slack to keep discussions productive.
|
||||
|
||||
19. **Curate Resources**
|
||||
- Create an **"Awesome [Project Name]"** list with:
|
||||
- Tutorials, videos, third-party tools.
|
||||
- Compile a **FAQ section** from common questions in forums/issues.
|
||||
|
||||
20. **Social Media & Outreach**
|
||||
- Manage project’s Twitter/LinkedIn:
|
||||
- Share updates, milestones, or contributor spotlights.
|
||||
- Write **"Getting Started" threads** or tweetorials for new users.
|
||||
|
||||
21. **Localization & Internationalization**
|
||||
- Translate UI strings (via Crowdin/Weblate).
|
||||
- Adapt docs for regional contexts (e.g., date formats, idioms).
|
||||
|
||||
22. **Design & UX Feedback**
|
||||
- Mockup UI improvements (Figma/Canva sketches).
|
||||
- Report confusing workflows (e.g., "Settings menu is hard to find").
|
||||
|
||||
23. **Grant Writing & Fundraising**
|
||||
- Apply for open-source grants (GitHub Sponsors, NLnet).
|
||||
- Draft **case studies** showcasing project impact.
|
||||
|
||||
@@ -1,73 +1,73 @@
|
||||
# .gitignore
|
||||
## Understanding .gitignore
|
||||
|
||||
The .gitignore file is a text file that tells Git which files or folders to ignore in a project.
|
||||
The `.gitignore` file is an essential component of Git's workflow. It tells Git which files and folders to ignore, preventing unnecessary or sensitive data from being tracked in your repository.
|
||||
|
||||
A local .gitignore file is usually placed in the root directory of a project. You can also create a global .gitignore file and any entries in that file will be ignored in all of your Git repositories.
|
||||
## Why Use .gitignore?
|
||||
|
||||
## Why .gitignore
|
||||
Now you may wonder why would you want git to ignore certain files and folders. Its because you don't want files like build files, cache files, other local configuration files like node modules, compilation files, temporary files IDE's create, etc to be tracked by git. It's usually used to avoid committing transient files from your working directory that aren't useful to other collaborators.
|
||||
Certain files should not be included in version control because they are either:
|
||||
- Temporary or system-generated (e.g., cache, build files, logs)
|
||||
- Large dependencies that can be reinstalled (e.g., `node_modules`)
|
||||
- Personal or sensitive configuration files (e.g., API keys, environment variables)
|
||||
- IDE or editor-specific files (e.g., `.vscode/`, `.idea/`)
|
||||
|
||||
## Getting started
|
||||
To create a local .gitignore file, create a text file and name it .gitignore (remember to include the . at the beginning). Then edit this file as needed. Each new line should list an additional file or folder that you want Git to ignore.
|
||||
Ignoring these files keeps the repository clean, reduces conflicts, and prevents security risks.
|
||||
|
||||
The entries in this file can also follow a matching pattern.
|
||||
## Creating a .gitignore File
|
||||
|
||||
```
|
||||
* is used as a wildcard match
|
||||
/ is used to ignore path names relative to the .gitignore file
|
||||
# is used to add comments to a .gitignore file
|
||||
To create a `.gitignore` file:
|
||||
1. In your project root directory, create a new text file named `.gitignore`.
|
||||
2. List the files and folders you want to ignore, one per line.
|
||||
3. Save the file.
|
||||
|
||||
This is an example of what the .gitignore file could look like:
|
||||
### Basic Syntax for .gitignore
|
||||
- `*` → Wildcard for matching multiple files.
|
||||
- `/` → Specifies path relative to `.gitignore`.
|
||||
- `#` → Adds comments.
|
||||
|
||||
### Example .gitignore File:
|
||||
```sh
|
||||
# Ignore Mac system files
|
||||
.DS_store
|
||||
.DS_Store
|
||||
|
||||
# Ignore node_modules folder
|
||||
node_modules
|
||||
# Ignore dependency folders
|
||||
node_modules/
|
||||
venv/
|
||||
|
||||
# Ignore log and cache files
|
||||
*.log
|
||||
.cache/
|
||||
|
||||
# Ignore environment files
|
||||
.env
|
||||
|
||||
# Ignore all text files
|
||||
*.txt
|
||||
|
||||
# Ignore files related to API keys
|
||||
.env
|
||||
|
||||
# Ignore SASS config files
|
||||
.sass-cache
|
||||
|
||||
```
|
||||
To add or change your global .gitignore file, run the following command:
|
||||
|
||||
```
|
||||
## Global .gitignore (For All Projects)
|
||||
To create a global `.gitignore` file (applies to all repositories):
|
||||
```sh
|
||||
git config --global core.excludesfile ~/.gitignore_global
|
||||
|
||||
```
|
||||
This will create the file ~/.gitignore_global. Now you can edit that file the same way as a local .gitignore file. All of your Git repositories will ignore the files and folders listed in the global .gitignore file.
|
||||
Then, edit `~/.gitignore_global` as you would a local `.gitignore`.
|
||||
|
||||
## How to Untrack Files Previously Committed from New Gitignore
|
||||
## Removing Files from Git Tracking
|
||||
|
||||
To untrack a single file, ie stop tracking the file but not delete it from the system use:
|
||||
If a file was already committed before adding it to `.gitignore`, you need to remove it from tracking:
|
||||
|
||||
- **Untrack a single file** (but keep it locally):
|
||||
```sh
|
||||
git rm --cached filename
|
||||
```
|
||||
|
||||
- **Untrack all ignored files**:
|
||||
```sh
|
||||
git rm -r --cached .
|
||||
git add .
|
||||
git commit -m "Updated .gitignore"
|
||||
```
|
||||
|
||||
To undo `git rm --cached filename`, use:
|
||||
```sh
|
||||
git add filename
|
||||
```
|
||||
git rm --cached filename
|
||||
```
|
||||
|
||||
To untrack every file in .gitignore:
|
||||
|
||||
First, commit any outstanding code changes, and then run:
|
||||
|
||||
```
|
||||
git rm -r --cached
|
||||
```
|
||||
|
||||
This removes any changed files from the index(staging area), then run:
|
||||
|
||||
```
|
||||
git add .
|
||||
```
|
||||
Commit it:
|
||||
|
||||
```
|
||||
git commit -m ".gitignore is now working"
|
||||
```
|
||||
|
||||
To undo ```git rm --cached filename```, use ```git add filename```
|
||||
|
||||
@@ -1,53 +1,75 @@
|
||||
# WHY USING BRANCHES DURING CONTRIBUTING
|
||||
## Why Use Branches When Contributing?
|
||||
Git branches are an essential tool for collaboration in software development. They allow multiple developers to work on different features or bug fixes simultaneously without interfering with the main project code. By using branches, you can experiment freely, test new ideas, and merge only the best changes into the main project.
|
||||
|
||||
## What are branches.
|
||||
## What Are Branches?
|
||||
A **branch** in Git is essentially a separate line of development. It allows you to create an isolated version of the project where you can make changes without affecting the main codebase. When you're ready, you can merge your branch back into the main project.
|
||||
|
||||
Branches are simply pointers to a commit.
|
||||
### How Branches Work
|
||||
Every branch is just a pointer to a specific commit in the project history. When you create a new branch, Git duplicates the state of the current branch, allowing you to work independently. New commits are added to this branch's history without affecting the main branch.
|
||||
|
||||
When you branch out, git is essentially making a new state of your current code, upon which you can work, without affecting the important main state of the code (which is in master branch).
|
||||
- To switch between branches, use `git checkout`.
|
||||
- To combine changes from one branch into another, use `git merge`.
|
||||
|
||||
When you are happy with your experiments, and want to merge you experiments in main code, you run git merge
|
||||
<branch name> master.
|
||||
This will tell git, to add in all changes from your experiment branch into master.
|
||||
## Why Use Branches?
|
||||
Branches make collaboration **structured and efficient**. Without them, all changes would be made directly to the main project, leading to confusion, errors, and conflicting code.
|
||||
|
||||
This way, while working in an open source project with a number of contributors, it becomes easy to merge the best suited code without altering the main code or master branch.
|
||||
### Example: The Car Paint Job Analogy
|
||||
Imagine a car manufacturing team deciding on the default color for a new car model. Initially, the car is set to be **olive green**. However, a few team members want to see how it looks in **red**.
|
||||
|
||||
## How it works?
|
||||
- Instead of repainting the original car, they create a **prototype** with red paint.
|
||||
- If the red color is approved, it replaces the original color (i.e., the branch is merged into the main project).
|
||||
- If the red color is rejected, the prototype is discarded (i.e., the branch is deleted).
|
||||
|
||||
A branch represents an independent line of development. Branches serve as an abstraction for the edit/stage/commit process. You can think of them as a way to request a brand new working directory, staging area, and project history. New commits are recorded in the history for the current branch, which results in a fork in the history of the project.
|
||||
Similarly, in Git, branches allow developers to test new features without directly modifying the main codebase.
|
||||
|
||||
The git branch command lets you create, list, rename, and delete branches. It doesn’t let you switch between branches or put a forked history back together again. For this reason, git branch is tightly integrated with the git checkout and git merge commands.
|
||||
## Feature Branching
|
||||
Instead of having one branch per developer, it's better to create **one branch per feature**. This keeps things organized and prevents unnecessary conflicts.
|
||||
|
||||
## Why to use branches?
|
||||
### Example: Alice & Bob's Feature Development
|
||||
- **Alice** is working on **Feature A** and makes several commits.
|
||||
- She then switches to **Feature C** and makes more commits.
|
||||
- Meanwhile, **Bob** finishes **Feature B** and wants to start working on **Feature A**.
|
||||
- Bob pulls in Alice’s branch, but now his branch contains **Feature A, Feature B, and some incomplete parts of Feature C**.
|
||||
- When he tries to merge his branch, he faces conflicts because Feature C is unfinished.
|
||||
|
||||
If the question "Why do we use branching in version control like git?" still persists in your mind, here's a quick explanation:
|
||||
To avoid this:
|
||||
- Alice should have separate branches for **Feature A** and **Feature C**.
|
||||
- Bob should have separate branches for **Feature B** and **Feature A**.
|
||||
|
||||
Let's take a simple example to understand the branching strategy. A production car needs a paint job before its launch. Prior to its official sale, it was decided that the car would come in 'olive green' color as default. But some of the members in the manufacturing team decided to showcase the car in 'red' color. Hence an ambiguous situation arises and to avoid this problem branching was introduced.The red color paint job is like a branch to the master repository 'Car'. Pushing this branch will suggest the red color. If merged with the master repository the car will get the red color otherwise it will continue with olive green. Merging a contributors branch to the master repo of the organization depends on the project head.
|
||||
This way, they can work without interfering with each other's progress.
|
||||
|
||||
## Example
|
||||
|
||||
Alice is working on Feature A and Bob is working on Feature B. Alice is halfway done with Feature A and has made a few commits in alice. However, Feature A is quite hard to implement so Alice decides that she should rather work on Feature C and makes a few commits onto alice. Bob finished Feature B and decides that he would like to tackle Feature A and so pulls alice into bob.
|
||||
|
||||
After Bob finishes Feature A he would like to merge bob into master. However, bob now contains Feature A, Feature B and parts of Feature C, but Feature C is not ready to be merged! It's easy to see that a workflow like this can lead to many confusing merge conflicts.
|
||||
|
||||
The trick is that instead of having personal branches one should have feature branches. Alice should have a branch for Feature A and Feature C and Bob should have a branch for Feature B and Feature A. That way they both can work on different features without tramping on each other's toes.
|
||||
|
||||
## How to create branches?
|
||||
|
||||
#### Create a branch
|
||||
## Creating and Managing Branches
|
||||
|
||||
### Create a New Branch
|
||||
```sh
|
||||
git branch my-new-branch
|
||||
```
|
||||
git branch AnyBranchName
|
||||
This creates a new branch named `my-new-branch` without switching to it.
|
||||
|
||||
### Switch to a Branch
|
||||
```sh
|
||||
git checkout my-new-branch
|
||||
```
|
||||
This moves you to `my-new-branch`, allowing you to work on it.
|
||||
|
||||
A new branch will be created named AnyBranchName and all the file changes in this branch will not be affected in the main branch.
|
||||
For detailed explanation refer [How to create branch](https://www.atlassian.com/git/tutorials/using-branches)
|
||||
|
||||
#### Delete the branch
|
||||
|
||||
```
|
||||
git branch -d AnyBranchName
|
||||
### Create and Switch to a Branch (Shortcut)
|
||||
```sh
|
||||
git checkout -b my-new-branch
|
||||
```
|
||||
This creates and switches to the new branch in a single step.
|
||||
|
||||
Branch name AnyBranchName will be deleted from the git repository.
|
||||
Refer to [Removing branch from your repository](https://github.com/jashnimje/first-contributions/blob/7dcae72208e4b42fcf834b4f189fa8ee78238077/additional-material/git_workflow_scenarios/removing-branch-from-your-repository.md)
|
||||
### Delete a Branch (After Merging)
|
||||
```sh
|
||||
git branch -d my-new-branch
|
||||
```
|
||||
This removes `my-new-branch` if it has already been merged.
|
||||
|
||||
### Force Delete a Branch (Without Merging)
|
||||
```sh
|
||||
git branch -D my-new-branch
|
||||
```
|
||||
Use this with caution! It deletes the branch even if it has unmerged changes.
|
||||
|
||||
## Additional Resources
|
||||
- [Git Branching Guide (Atlassian)](https://www.atlassian.com/git/tutorials/using-branches)
|
||||
- [Removing a Branch from Your Repository](https://github.com/jashnimje/first-contributions/blob/7dcae72208e4b42fcf834b4f189fa8ee78238077/additional-material/git_workflow_scenarios/removing-branch-from-your-repository.md)
|
||||
|
||||
@@ -0,0 +1,84 @@
|
||||
# গিট কনফিগারেশন
|
||||
|
||||
প্রথমবারের মতো যখন আপনি `commit` করার চেষ্টা করবেন, তখন এই ধরনের বার্তা দেখতে পাবেন:
|
||||
|
||||
```bash
|
||||
$ git commit
|
||||
*** Please tell me who you are.
|
||||
|
||||
Run
|
||||
|
||||
git config --global user.email "you@example.com"
|
||||
git config --global user.name "Your Name"
|
||||
|
||||
to set your account's default identity.
|
||||
Omit --global to set the identity only in this repository.
|
||||
```
|
||||
|
||||
একটি `commit` তৈরি করতে গিটকে জানতে হবে যে এর লেখক কে। সহযোগী কাজের ক্ষেত্রে, প্রকল্পের বিভিন্ন অংশের পরিবর্তন করেছেন কে এবং কবে, তা জানা খুবই গুরুত্বপূর্ণ। তাই গিটে প্রতিটি `commit`-এর সাথে ব্যবহারকারীর নাম এবং ইমেল ঠিকানা সংযুক্ত করা হয়।
|
||||
|
||||
এখানে কিছু উপায় আছে যার মাধ্যমে আপনি আপনার ইমেল এবং নাম `git commit` কমান্ডের সাথে যুক্ত করতে পারেন।
|
||||
|
||||
### গ্লোবাল কনফিগারেশন
|
||||
|
||||
গ্লোবাল কনফিগারেশনে সংরক্ষিত তথ্য সমস্ত গিট রিপোজিটরিতে প্রযোজ্য। এটি হল সবচেয়ে ব্যবহৃত পদ্ধতি।
|
||||
|
||||
গ্লোবাল কনফিগারেশনে কিছু সেট করতে, আপনি `config` কমান্ডটি এভাবে ব্যবহার করতে পারেন:
|
||||
|
||||
```bash
|
||||
$ git config --global <variable name> <value>
|
||||
```
|
||||
|
||||
ব্যবহারকারীর তথ্য সেট করার জন্য, এটি এভাবে হবে:
|
||||
|
||||
```bash
|
||||
$ git config --global user.email "you@example.com"
|
||||
$ git config --global user.name "Your Name"
|
||||
```
|
||||
|
||||
### রিপোজিটরি স্তরের কনফিগারেশন
|
||||
|
||||
এই ধরনের কনফিগারেশন শুধুমাত্র আপনার বর্তমান রিপোজিটরিতে প্রযোজ্য। যদি আপনি কোনও নির্দিষ্ট রিপোজিটরিতে কাজ করতে চান (উদাহরণস্বরূপ, কোম্পানির প্রকল্পে), তবে এই পদ্ধতি ব্যবহার করতে পারেন।
|
||||
|
||||
রিপোজিটরি স্তরের কনফিগারেশন সেট করতে, `--global` বাদ দিয়ে `config` কমান্ডটি ব্যবহার করুন:
|
||||
|
||||
```bash
|
||||
$ git config <variable name> <value>
|
||||
```
|
||||
|
||||
ব্যবহারকারীর তথ্য সেট করার জন্য, এটি এভাবে হবে:
|
||||
|
||||
```bash
|
||||
$ git config user.email "you@alternate.com"
|
||||
$ git config user.name "Your Name"
|
||||
```
|
||||
|
||||
### কমান্ড লাইনে কনফিগারেশন
|
||||
|
||||
এই ধরনের কনফিগারেশন শুধুমাত্র একটি নির্দিষ্ট কমান্ডের জন্য প্রযোজ্য। সব গিট কমান্ডে `-c` ব্যবহার করে আপনি কনফিগারেশন পরামিতি সেট করতে পারেন।
|
||||
|
||||
একটি কমান্ডের জন্য কনফিগারেশন পরিবর্তন করতে, গিট কমান্ডটি এভাবে ব্যবহার করুন:
|
||||
|
||||
```bash
|
||||
$ git -c <variable-1>=<value> -c <variable-2>=<value> <command>
|
||||
```
|
||||
|
||||
আমাদের ক্ষেত্রে, `commit` কমান্ডটি এভাবে হবে:
|
||||
|
||||
```bash
|
||||
git -c user.name='Your Name' -c user.email='you@example.com' commit -m "Your commit message"
|
||||
```
|
||||
|
||||
### অগ্রাধিকারের ক্রম
|
||||
|
||||
এই তিনটি কনফিগারেশন পদ্ধতির মধ্যে অগ্রাধিকারের ক্রম হল: `কমান্ড লাইন > রিপোজিটরি > গ্লোবাল`। এর মানে হল যদি কোনও পরিবর্তনশীল গ্লোবাল এবং কমান্ড লাইনে উভয় ক্ষেত্রেই সেট করা থাকে, তবে কমান্ড লাইনের মান ব্যবহার করা হবে।
|
||||
|
||||
## শুধু ব্যবহারকারীর তথ্য নয়
|
||||
|
||||
এখন পর্যন্ত আমরা গিট কনফিগারেশন নিয়ে আলোচনা করেছি শুধু ব্যবহারকারীর তথ্যের ক্ষেত্রে। কিন্তু গিট আরও অনেক পরামিতি কনফিগার করতে দেয়। এখানে কিছু উল্লেখযোগ্য উদাহরণ:
|
||||
|
||||
1. `core.editor` - কমিট মেসেজ এডিট করার জন্য ব্যবহৃত টেক্সট এডিটর,
|
||||
2. `commit.template` - কমিটের জন্য প্রাথমিক টেমপ্লেট ফাইল,
|
||||
3. `color.ui` - টার্মিনালে গিট মেসেজে রঙিন ফন্ট ব্যবহার করা যাবে কিনা তা নির্ধারণ করে।
|
||||
|
||||
আরও বিস্তারিত জানতে [git-scm.com](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration) দেখুন।
|
||||
@@ -0,0 +1,58 @@
|
||||
# ওপেন সোর্স অবদানের জন্য Git অনুমতি ত্রুটি সমাধান
|
||||
|
||||
## সমস্যা
|
||||
|
||||
আমি "first-contributions" রিপোজিটরিতে অবদান রাখার চেষ্টা করার সময় একটি অনুমতি ত্রুটি পেয়েছিলাম। আমি নতুন ব্রাঞ্চ তৈরি করে এবং পরিবর্তনগুলি পুশ করার চেষ্টা করার পর:
|
||||
|
||||
```bash
|
||||
$ git checkout -b fahimar_oss_YYYY
|
||||
Switched to a new branch 'fahimar_oss_YYYY'
|
||||
|
||||
$ git push origin fahimar_oss_YYYY
|
||||
remote: Permission to firstcontributions/first-contributions.git denied to fahimar.
|
||||
fatal: unable to access 'https://github.com/firstcontributions/first-contributions.git/': The requested URL returned error: 403
|
||||
```
|
||||
|
||||
সমস্যাটি ছিল যে, আমি মূল রিপোজিটরিটি সরাসরি ক্লোন করেছিলাম এবং সেখানে পুশ করার চেষ্টা করেছিলাম। একজন বাইরের অবদানকারী হিসেবে, আমার মূল রিপোজিটরিতে লেখার অনুমতি নেই।
|
||||
|
||||
## সমাধান
|
||||
|
||||
আমি নিম্নলিখিত উপায়ে এই সমস্যাটি সমাধান করেছি:
|
||||
|
||||
1. আমার রিমোট URL পরিবর্তন করে এটিকে আমার ব্যক্তিগত ফর্কে পয়েন্ট করানো:
|
||||
|
||||
```bash
|
||||
$ git remote set-url origin https://github.com/yourname/first-contributions.git
|
||||
```
|
||||
|
||||
2. রিমোট ঠিকভাবে আপডেট হয়েছে কিনা তা যাচাই করা:
|
||||
|
||||
```bash
|
||||
$ git remote -v
|
||||
origin https://github.com/yourname/first-contributions.git (fetch)
|
||||
origin https://github.com/yourname/first-contributions.git (push)
|
||||
```
|
||||
|
||||
3. সফলভাবে আমার ফর্কে পুশ করা:
|
||||
|
||||
```bash
|
||||
$ git push origin fahimar_oss_YYYY
|
||||
```
|
||||
|
||||
4. GitHub আমাকে একটি লিঙ্ক দিয়েছিল যাতে আমি আমার ব্রাঞ্চ থেকে পুল রিকোয়েস্ট তৈরি করতে পারি:
|
||||
```
|
||||
remote: Create a pull request for 'fahimar_oss_YYYY' on GitHub by visiting:
|
||||
remote: https://github.com/fahimar/first-contributions/pull/new/fahimar_oss_YYYY
|
||||
```
|
||||
|
||||
## প্রধান শিক্ষা
|
||||
|
||||
ওপেন সোর্স অবদানের জন্য সঠিক কাজের ধারাবাহিকতা হল:
|
||||
|
||||
1. মূল রিপোজিটরিটি আপনার GitHub অ্যাকাউন্টে ফর্ক করুন
|
||||
2. আপনার ফর্কটি স্থানীয়ভাবে ক্লোন করুন
|
||||
3. একটি নতুন ব্রাঞ্চে পরিবর্তন করুন
|
||||
4. আপনার ফর্কে পুশ করুন
|
||||
5. আপনার ফর্ক থেকে মূল রিপোজিটরিতে পুল রিকোয়েস্ট তৈরি করুন
|
||||
|
||||
যদি আপনি আগে মূল রিপোজিটরি ক্লোন করে থাকেন এবং আপনার ফর্ক না করে থাকেন, তবে উপরে দেখানো মতো রিমোট URL আপডেট করে এটি ঠিক করতে পারেন।
|
||||
@@ -0,0 +1,164 @@
|
||||
# حاجات ممكن اللي مش مبرمج يعملها
|
||||
## اسمع الأول
|
||||
|
||||
كل حاجة في الـ Open Source بتعتمد على الناس اللي شغالة فيها.
|
||||
إنت عايز تنضم لفريق، وده معناه إنك تفهم المجتمع شغال إزاي.
|
||||
لو دخلت على مشروع وقلت "هاي، أنا شايف إن المشروع المفروض يعمل كذا" غالبًا ده مش هيكون مقبول.
|
||||
ممكن مشاريع معينة تكون بتحب الأسلوب ده، لكن لو المشروع ليه فترة شغال، نسبة إن الناس تتقبل الكلام ده قليلة.
|
||||
**أحسن حاجة تعملها في الأول إنك تسمع وتشوف الناس شغالة إزاي.**
|
||||
|
||||
1. **اشترك في Mailing List**: في مشاريع كتير، الـ mailing list هي وسيلة التواصل الرئيسية بين الناس اللي بتطور المشروع.
|
||||
في المشاريع الكبيرة، هتلاقي كذا mailing list.
|
||||
مثلاً، مشروع PostgreSQL عنده أكتر من 12 mailing list للمستخدمين و6 للمطورين.
|
||||
ابدأ بمتابعة الـ list الأساسية للمستخدمين وواحدة من بتوع المطورين علشان تفهم اللي بيحصل.
|
||||
|
||||
2. **تابع Blog**: المطورين الكبار غالبًا بيكتبوا تدوينات بيشرحوا فيها اللي هيحصل في النسخ الجاية،
|
||||
وبيتكلموا عن اللي اتعمل علشان نوصل للمرحلة دي.
|
||||
في مواقع اسمها Planet بتجمع التدوينات والأخبار من كذا مصدر عن المشروع.
|
||||
لو فيه planet زي planet.gnome.org أو planet.mysql.com، يبقى ده مكان كويس تبدأ منه.
|
||||
اكتب في جوجل "planet <اسم المشروع>".
|
||||
|
||||
3. **ادخل على قناة IRC**: معظم مشاريع الـ Open Source عندها قنوات IRC الناس بتدخل تتكلم فيها عن المشاكل والتطوير.
|
||||
ادخل على موقع المشروع وشوف اسم القناة على أي شبكة IRC.
|
||||
|
||||
**اشتغل على التذاكر**
|
||||
الكود هو الأساس في أي مشروع مفتوح المصدر، بس ده مش معناه إن الكود هو الطريقة الوحيدة اللي ممكن تساهم بيها.
|
||||
فيه حاجات تانية كتير الناس بتكسل تعملها، زي صيانة النظام أو متابعة المشاكل.
|
||||
ابدأ من هنا وهتلاقي نفسك بقيت جزء من الفريق.
|
||||
|
||||
معظم المشاريع عندها نظام تذاكر على الموقع الرسمي.
|
||||
ده بيكون وسيلة تواصل بين الناس اللي بتستخدم البرنامج والمطورين.
|
||||
تنضيف التذاكر دي وتحديثها بيساعد الفريق جدًا.
|
||||
|
||||
ممكن تحتاج صلاحيات علشان تعدل على التذاكر، بس صدقني، أول ما تقول إنك عايز تساعد، هيدوك الصلاحيات دي على طول.
|
||||
|
||||
4. **حلل مشكلة (Bug)**: ساعات الناس بتبلّغ عن مشاكل بشكل مش واضح.
|
||||
لو حد قال "البرنامج بيهنّج لما بعمل كذا"، خد وقتك وحاول تعرف المشكلة دي بتحصل إزاي.
|
||||
هل بتتكرر؟ تقدر تكتب خطوات تثبت بيها إنها بتحصل؟ بتحصل على متصفح معين؟ ولا في نظام تشغيل معين؟
|
||||
|
||||
حتى لو معرفتش تحلها، إنك توضّح المشكلة أكتر بيسهّل على حد تاني ييجي يحلها.
|
||||
وكل اللي تكتشفه، اكتبه في التذكرة علشان غيرك يستفيد.
|
||||
|
||||
5. **اقفل التذاكر القديمة**: كتير من المشاكل بتكون اتحلت، بس التذاكر لسه مفتوحة.
|
||||
البحث في التذاكر القديمة وتنضيفها حاجة مهمة جدًا.
|
||||
|
||||
ابدأ بدور على تذاكر بقالها أكتر من سنة وشوف هل المشكلة لسه موجودة ولا اتصلحت.
|
||||
راجع سجل التغييرات في الإصدارات وشوف لو فيه ذكر للمشكلة.
|
||||
لو اتحلت، اكتب رقم النسخة في التذكرة واقفلها.
|
||||
|
||||
جرّب تعيد المشكلة في آخر نسخة من البرنامج.
|
||||
لو مشتغلتش، اكتب ده في التذكرة واقفلها.
|
||||
لو لسه موجودة، اكتبه برضو وسيب التذكرة مفتوحة.
|
||||
|
||||
## الشغل على الكود
|
||||
الناس اللي عندها خبرة مختلفة في البرمجة تقدر تساعد في الكود.
|
||||
مش لازم تكون مبرمج جامد علشان تساهم.
|
||||
|
||||
لو ناوي تعدل على الكود، اعرف الأول المشروع بيشتغل إزاي في موضوع استلام التعديلات.
|
||||
كل مشروع ليه طريقة معينة، فاسأل الأول.
|
||||
|
||||
مثلاً، PostgreSQL بيستقبل التعديلات على شكل Patch في mailing list، والمطورين بيراجعوها كويس جدًا.
|
||||
لكن في مشروع زي Parrot، ممكن تاخد صلاحيات التعديل بسهولة.
|
||||
لو المشروع على GitHub، غالبًا بيستخدموا Pull Requests.
|
||||
كل مشروع وليه طريقته.
|
||||
|
||||
لما تعدل حاجة، خليك محترم مع باقي الفريق وحافظ على تنسيق الكود زي ما هو.
|
||||
ما تحاولش تفرض أسلوبك.
|
||||
الكود اللي بتكتبه لازم يشبه اللي موجود، حتى لو مش عاجبك.
|
||||
|
||||
6. **اختبر نسخة Beta أو Release Candidate**:
|
||||
المشاريع اللي بتشتغل على كذا نظام تشغيل ساعات بيكون فيها مشاكل توافق.
|
||||
قبل الإصدارات، المطورين بينزلوا نسخ تجريبية علشان الناس تجربها.
|
||||
لو شغّلت البرنامج على نظام تشغيل مختلف واشتغل، ده بيساعدهم يعرفوا إن النسخة كويسة.
|
||||
|
||||
مش لازم تعمل حاجة غير إنك تبني البرنامج وتفتحه وتجربه.
|
||||
لو شغال، بلغهم.
|
||||
ده بيفرق كتير جدًا مع المطورين.
|
||||
|
||||
7. **صلّح Bug**: ده غالبًا أول حاجة الناس بتعملها لما تبدأ تشتغل في الكود.
|
||||
دور على Bug شكله بسيط، وجرب تصلحه.
|
||||
اكتب ملاحظاتك جوه الكود، ولو في Test يوضح إن المشكلة اتحلت، ضيفه.
|
||||
لو معرفتش تصلحها، اكتب اللي وصلتله في التذكرة.
|
||||
|
||||
8. **اكتب Test**:
|
||||
معظم المشاريع عندها Tests، بس دايمًا فيه مكان لإضافة تانية.
|
||||
استخدم أدوات بتقيس مدى التغطية، زي `gcov` أو `Devel::Cover`.
|
||||
وشوف أجزاء الكود اللي مش متغطية، وضيف لها Test.
|
||||
|
||||
9. **اسكت تحذير من الكومبايلر**:
|
||||
لما تبني برامج C، ممكن يطلعلك تحذيرات.
|
||||
مش دايمًا معناها إن فيه مشكلة، بس بتشوّش.
|
||||
لو شفت تحذير، شوف هل فعلاً فيه مشكلة؟
|
||||
لو لأ، عدل الكود علشان تسكت التحذير.
|
||||
|
||||
10. **ضيف تعليق**:
|
||||
لو لقيت جزء في الكود مش مفهوم، اكتبه تعليق.
|
||||
أكيد في ناس غيرك هتتلخبط برضو.
|
||||
ابعت تعديل فيه التعليقات دي.
|
||||
|
||||
## الشغل على التوثيق
|
||||
المستندات دايمًا بتتاخد بشكل بسيط.
|
||||
وساعات بتكون مكتوبة كأن اللي بيقراها أصلاً فاهم المشروع.
|
||||
لو حسيت إن التوثيق مش واضح، قول.
|
||||
اللي عنيهم جديدة بيشوفوا حاجات الناس اللي شغالة عليها مش شايفاها.
|
||||
|
||||
11. **اعمل مثال**:
|
||||
مفيش مشروع عنده أمثلة كتير كفاية.
|
||||
لو فيه API، أو مكتبة، أو برنامج GUI زي Gimp، أو حتى أداة سطر أوامر – اعمل مثال عملي بيشرح ازاي تستخدمه.
|
||||
|
||||
ممكن المثال يكون حاجة بسيطة من كود انت كتبته، أو حتى فيديو Screen Recording وانت بتستخدمه.
|
||||
الناس بتحب تشوف التطبيق العملي أكتر من الكلام.
|
||||
|
||||
## اشتغل مع المجتمع
|
||||
الـ Open Source مش بس كود. المجتمع هو اللي بيخلي المشاريع دي تعيش وتكبر.
|
||||
فيه طرق كتير تقدر تساعد بيها في تقوية المجتمع حوالي المشروع.
|
||||
|
||||
12. **جاوب على سؤال**:
|
||||
أحسن طريقة تساعد بيها المشروع والمجتمع هي إنك تساعد غيرك.
|
||||
لما حد جديد يسأل سؤال، وحضرتك تجاوبه بدل ما تقول له "روح اقرأ الـ Manual"، كده إنت مش بس ساعدته،
|
||||
إنت كمان شجّعته يكمل، ويمكن كمان يبقى عضو نشيط في المشروع بعد كده.
|
||||
|
||||
كلنا بدأنا من الصفر، والمشاريع محتاجة دايمًا ناس جديدة تدخل علشان تفضل عايشة.
|
||||
|
||||
13. **اكتب تدوينة (Blog Post)**:
|
||||
لو عندك مدونة، احكي فيها عن تجربتك مع المشروع اللي بتستخدمه.
|
||||
قول واجهت إيه مشاكل، وازاي حليتها.
|
||||
كده بتساعد المشروع بطريقتين:
|
||||
- إنك بتخلي الناس تفكر في المشروع وتسمع عنه.
|
||||
- وإنك بتسيب أثر للي بعدك لو حد واجه نفس المشكلة وعمل بحث على جوجل.
|
||||
|
||||
(والتدوينة دي كمان ممكن تبقى وسيلة كويسة توري بيها خبرتك الحقيقة في الشغل لما تيجي تدور على شغل.)
|
||||
|
||||
14. **طوّر موقع المشروع**:
|
||||
لو عندك خبرة في تصميم المواقع، وساعدت في تحسين الموقع أو شكله العام، ده وقتك مش بيضيع.
|
||||
يمكن المشروع محتاج لوجو، أو ستايل أحسن، أو تنظيم أحسن للمحتوى.
|
||||
الحاجات دي ساعات بتكون ناقصة عند المبرمجين، وساعتها أي حد عنده ذوق أو خبرة في التصميم بيفرق جامد.
|
||||
أنا عن نفسي بتمنى ألاقي حد يساعدني في التصميم في مشاريعي!
|
||||
|
||||
15. **اكتب توثيق تقني (Documentation)**:
|
||||
لو تقدر تشرح ازاي برنامج أو أداة شغالة، يبقى تقدر تكتب توثيق تقني عنها.
|
||||
مشاريع Open Source كتير بتبقى محتاجة توثيق جديد، أو تطوير اللي موجود، أو تبسيطه للناس.
|
||||
|
||||
كل ما كانت كتابتك أبسط وأوضح، كل ما كانت أحسن.
|
||||
وأجمل حاجة؟ مش لازم تكون مبرمج علشان تكتب Documentation.
|
||||
|
||||
والأهم من كل ده، اسمع الناس بتتكلم عن إيه.
|
||||
حاول تلاحظ المشاكل اللي محتاجة حل.
|
||||
مثلاً، في مرة على Mailing List لمشروع Parrot، قرروا ينقلوا من Trac لـ GitHub في نظام التذاكر.
|
||||
ناس كتير كانوا ضد القرار علشان مفيش طريقة ينقلوا التذاكر القديمة.
|
||||
دخلت وقلت "طب ما أكتب أنا برنامج يحوّل التذاكر؟" والناس فرحت جدًا.
|
||||
فعلاً كتبت برنامج نقل أكتر من 450 تذكرة، واحتفظنا بتاريخهم.
|
||||
نجاح جميل، وساعدت الفريق، والمطورين ركزوا في شغلهم بدل وجع الدماغ.
|
||||
|
||||
16. **علّم وساعد غيرك**:
|
||||
أحسن طريقة تتعلم بيها أكتر، إنك تشرح اللي فهمته لحد تاني.
|
||||
المدرّس الشاطر هو اللي يقدر يشرح حاجة معقدة بطريقة بسيطة.
|
||||
|
||||
لو علمت حد، أو ساعدته، مش بس هتحس إنك عملت حاجة كويسة،
|
||||
ده كمان هيثبت المعلومة في دماغك، ويقوّي مهاراتك.
|
||||
ولما حد يساعدك، ما تحتفظش بالمعلومة لنفسك.
|
||||
شارك اللي عرفته، وخلّي الدنيا مكان أحسن.
|
||||
|
||||
والسلام عليكم ورحمة الله وبركاته.
|
||||
|
||||
|
||||
+1
-1
@@ -101,7 +101,7 @@ Menjawab pertanyaan, terutama dari seseorang yang baru saja memulai, sangat pent
|
||||
Waktu yang Anda luangkan untuk membantu seorang pemula, bahkan jika mereka mengajukan pertanyaan di mana Anda dapat dengan mudah menjawab “RTFM” dengan cepat, akan terbayar di kemudian hari dengan mendapatkan anggota aktif lainnya di dalam komunitas.
|
||||
Semua orang memulai dari suatu tempat, dan proyek membutuhkan arus masuk orang yang konstan jika ingin tetap hidup.
|
||||
|
||||
13. **Tulislah sebuah postingan blog:
|
||||
13. **Tulislah sebuah postingan blog**:
|
||||
Jika Anda memiliki sebuah blog, tulislah tentang pengalaman Anda dengan proyek yang Anda gunakan.
|
||||
Ceritakan tentang masalah yang Anda hadapi dengan menggunakan perangkat lunak dan apa yang Anda lakukan untuk menyelesaikannya.
|
||||
Anda akan membantu dengan dua cara, yaitu dengan membantu menjaga proyek tetap berada di benak orang lain di sekitar Anda,
|
||||
@@ -0,0 +1,124 @@
|
||||
プログラマーでなくてもできること
|
||||
聞くことから始めよう
|
||||
|
||||
オープンソースはすべて、他の人々を巻き込むことです。
|
||||
あなたはチームに加わろうとしており、それにはコミュニティとその仕組みを理解する必要があります。
|
||||
プロジェクトに参加して「こんにちは、このプロジェクトにはこうしたほうがいいと思います」と言うのは、通常あまり歓迎されません。
|
||||
一部のプロジェクトではそのようなアプローチを歓迎するかもしれませんが、長く続いているプロジェクトでは、その考え方はあまり受け入れられません。
|
||||
プロジェクトのニーズを理解するには、まず聞くことが最も重要です。
|
||||
|
||||
1. メーリングリストに参加する
|
||||
|
||||
多くのプロジェクトでは、メーリングリストが開発に関する主なコミュニケーション手段となっています。
|
||||
大規模なプロジェクトには、複数のメーリングリストがあります。
|
||||
たとえば、PostgreSQLプロジェクトには、少なくとも12のユーザー向けリストと6つの開発者リストがあります。
|
||||
主要なユーザー向けと開発者向けリストをフォローし、まずは「聞くこと」から始めましょう。
|
||||
2. ブログをフォローする
|
||||
|
||||
主要な開発者が運営しているブログでは、今後のリリースや現在進行中の作業についての情報が得られます。
|
||||
Planetサイトは、関連する複数のニュースソースやブログ投稿を一か所でまとめて表示します。
|
||||
たとえば planet.gnome.org や planet.mysql.com のようなサイトがそうです。
|
||||
Googleで「Planet <プロジェクト名>」と検索してみましょう。
|
||||
|
||||
3. IRCチャンネルに参加する
|
||||
|
||||
多くのオープンソースプロジェクトにはIRC（インターネットリレーチャット）チャンネルがあり、開発者やユーザーが問題や開発について話し合っています。
|
||||
プロジェクトのWebサイトで、チャンネル名や使用しているIRCネットワークを確認しましょう。
|
||||
チケットを使った作業
|
||||
|
||||
コードはオープンソースプロジェクトの中心ですが、貢献方法はそれだけではありません。
|
||||
コードの周囲のシステムの保守は、新機能の追加やバグ修正の際に見過ごされがちです。
|
||||
こうした分野に関わることは、プロジェクトへの入り口となります。
|
||||
多くのプロジェクトには、公開されているトラブルチケットシステムがあり、公式Webサイトのトップページやドキュメントからリンクされています。
|
||||
これはユーザーと開発者間の主なコミュニケーション手段です。これを最新に保つことは、大きな貢献となります。
|
||||
一部の操作には特別な権限が必要ですが、多くのプロジェクトリーダーは喜んで協力してくれます。
|
||||
|
||||
4. バグの診断
|
||||
|
||||
バグはしばしば不正確に報告されます。
|
||||
バグを診断して説明することは、開発者が問題の原因を特定する助けになります。
|
||||
たとえば「Xをしたときにソフトが動かない」と報告された場合、再現できるか確認しましょう。
|
||||
特定のブラウザでのみ発生するのか、特定のディストリビューションでのみ発生するのかを絞り込むことが重要です。
|
||||
原因が分からなくても、可能な限り情報を絞り込むことで他の人が修正しやすくなります。
|
||||
見つけたことはすべてチケットに記録しましょう。
|
||||
|
||||
5. 修正されたバグを閉じる
|
||||
|
||||
バグがコードで修正されても、チケットが更新されていないことがあります。
|
||||
このような「ごみ」を掃除するのは時間がかかりますが、プロジェクト全体にとっては非常に重要です。
|
||||
1年以上前のチケットを検索し、バグがまだ存在するか確認してください。
|
||||
リリースの変更ログを確認し、修正されたことが明らかであればチケットを閉じてください。
|
||||
バグが再現できなければそれを記録し、閉じます。再現できれば、続けてオープンにしておきます。
|
||||
コードを使った作業
|
||||
|
||||
経験レベルに関係なく、誰でもコードで貢献できます。
|
||||
貢献するために天才である必要はありません。
|
||||
コードの修正を行う場合は、そのプロジェクトがどのようにコードを受け入れているか確認してください。
|
||||
各プロジェクトには独自のワークフローがあります。
|
||||
たとえば PostgreSQL ではパッチをメーリングリストに送る厳格なルールがありますが、Parrot のようなプロジェクトではもっと簡単です。
|
||||
GitHubを使用している場合は、Pull Requestを通じて貢献できます。
|
||||
修正時は、既存のコードスタイルに従い、責任あるメンバーとして行動してください。
|
||||
|
||||
6. ベータ版やリリース候補版をテストする
|
||||
|
||||
さまざまな環境で動作するソフトウェアには、移植性に関する問題が多く存在します。
|
||||
リリース前にベータ版やRC版が公開された際は、異なる環境でのテストが期待されます。
|
||||
あなたもその一員となり、自分の環境でビルド・実行・テストをして、動作報告を送りましょう。
|
||||
|
||||
7. バグを修正する
|
||||
|
||||
これはコードに貢献したい人のための一般的な方法です。
|
||||
チケットシステムから興味のあるバグを探し、修正に挑戦してください。
|
||||
テストが必要であれば、それも追加しましょう。
|
||||
修正できなかった場合でも、調査内容を記録することが次の人の助けになります。
|
||||
|
||||
8. テストを書く
|
||||
|
||||
ほとんどのプロジェクトにはテストスイートがありますが、十分にカバーされていないこともあります。
|
||||
テストカバレッジツールを使用して未カバー部分を探し、そこに対するテストを追加しましょう。
|
||||
|
||||
9. コンパイラ警告を修正する
|
||||
|
||||
多くのC系プロジェクトでは、ビルド時に警告が出ます。
|
||||
それらの多くは深刻な問題ではありませんが、見た目が悪く、重要な警告を埋もれさせてしまうことがあります。
|
||||
警告を解消するためのコード変更は、プロジェクトにとって役立ちます。
|
||||
|
||||
10. コメントを追加する
|
||||
|
||||
コードを読む中で混乱する箇所があれば、他の人も同じように困る可能性があります。
|
||||
そこにコメントを追加し、パッチとして提出しましょう。
|
||||
ドキュメントで貢献する
|
||||
|
||||
ドキュメントはしばしば軽視されがちであり、経験者の視点で書かれていることが多いため、初心者にはわかりにくいことがあります。
|
||||
新しい視点から欠点を見つけ、改善することができます。
|
||||
|
||||
11. 使用例を作成する
|
||||
|
||||
どんなプロジェクトでも、How-toの使用例は歓迎されます。
|
||||
API、GUIアプリ、CLIツールなど、実用的な例を作りましょう。
|
||||
セットアップ手順のスクリーンショットを追加するのも良いアイデアです。
|
||||
コミュニティとの関わり方
|
||||
|
||||
オープンソースはコードだけではありません。コミュニティこそがそれを支える柱です。
|
||||
|
||||
12. 質問に答える
|
||||
|
||||
他人を助けることは、コミュニティを強くする最高の方法です。
|
||||
特に初心者の質問に親切に答えることで、活発な参加者が増え、プロジェクトの将来が明るくなります。
|
||||
|
||||
13. ブログ投稿を書く
|
||||
|
||||
使っているソフトウェアに関して、経験や問題・解決策を書いてください。
|
||||
他のユーザーが同様の問題に直面したとき、あなたのブログが役立つかもしれません。
|
||||
また、将来そのソフトを使って職探しをする際の実績としても使えます。
|
||||
|
||||
14. Webサイトを改善する
|
||||
|
||||
もしWebデザインのスキルがあれば、プロジェクトのWebサイトを改善することで貢献できます。
|
||||
新しいロゴやバナー、レイアウトの改善など、あなたのスキルが生かされる場面は多くあります。
|
||||
|
||||
最も重要なのは、周囲の人々がどんな話をしているのか、耳を傾けることです。
|
||||
必要なものに気づき、積極的に提案・行動することで、大きなインパクトを残すことができます。
|
||||
|
||||
たとえば、Parrotの開発者がTracからGitHubへチケットを移行するか議論していた際、
|
||||
「コンバーターを書きましょうか？」と申し出たことで、450以上のチケットを失わずに済み、大きな成功となりました。
|
||||
+64
@@ -0,0 +1,64 @@
|
||||
|
||||
# ಓಪನ್ ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ಗಳಿಗೆ ಹೇಗೆ ಕೊಡುಗೆ ನೀಡುವುದು: ಆರಂಭಿಕರಿಗಾಗಿ ಸಂಪೂರ್ಣ ಮಾರ್ಗದರ್ಶಿ
|
||||
|
||||
**ಸಂಕ್ಷಿಪ್ತವಾಗಿ:** ನೀವು ನಿಮ್ಮ ಮೊದಲ Pull Request ಅನ್ನು ಒಂದು ಓಪನ್ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ಗೆ ಸಲ್ಲಿಸಲು ಕಾತರರಾಗಿದ್ದರೆ, ಈ ಸೂಚನೆಗಳನ್ನು ಅನುಸರಿಸಿ: [Readme](https://github.com/firstcontributions/first-contributions)
|
||||
|
||||
ಓಪನ್ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ಗಳಿಗೆ ಕೊಡುಗೆ ನೀಡುವುದು ಒಬ್ಬ ಪ್ರೋಗ್ರಾಮರ್ ಆಗಿ ಬೆಳೆಯಲು, ನಿಮ್ಮ ಪೋರ್ಟ್ಫೋಲಿಯೋವನ್ನು ನಿರ್ಮಿಸಲು ಮತ್ತು ಸಮುದಾಯಕ್ಕೆ ಹಿಂದಿರುಗಿಸಲು ಅತ್ಯುತ್ತಮ ಮಾರ್ಗಗಳಲ್ಲಿ ಒಂದು. ನೀವು ಅನುಭವಸಂಪನ್ನ ಪ್ರೋಗ್ರಾಮರ್ ಆಗಿರಲಿ ಅಥವಾ ಪ್ರಾರಂಭದಲ್ಲೇ ಇರಲಿ, ಓಪನ್ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ಗಳು ಕಲಿಯಲು, ಸಹಕರಿಸಲು ಮತ್ತು ಸಕಾರಾತ್ಮಕ ಪರಿಣಾಮವನ್ನುಂಟುಮಾಡಲು ಹಲವಾರು ಅವಕಾಶಗಳನ್ನು ಒದಗಿಸುತ್ತವೆ. ಈ ಮಾರ್ಗದರ್ಶಿಯಲ್ಲಿ, ಸರಿಯಾದ ಪ್ರಾಜೆಕ್ಟ್ನ್ನು ಹುಡುಕುವುದರಿಂದ ಹಿಡಿದು ನಿಮ್ಮ ಮೊದಲ ಕೊಡುಗೆಯನ್ನು ನೀಡುವವರೆಗಿನ ಎಲ್ಲಾ ಹಂತಗಳನ್ನು ನೋಡೋಣ.
|
||||
|
||||
## ಏಕೆ ಓಪನ್ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ಗಳಿಗೆ ಕೊಡುಗೆ ನೀಡಬೇಕು?
|
||||
|
||||
"ಹೇಗೆ" ಎಂಬುದರ ಮೊದಲು, "ಏಕೆ" ಎಂಬುದನ್ನು ತಿಳಿಯೋಣ:
|
||||
|
||||
* **ಕೌಶಲ್ಯ ಅಭಿವೃದ್ಧಿ:** ನೈಜ ಪ್ರಾಜೆಕ್ಟ್ಗಳ ಕೋಡ್ಗಳನ್ನು ನೋಡಿ ಕಲಿಯುವ ಮೂಲಕ ನಿಮ್ಮ ಪ್ರೋಗ್ರಾಮಿಂಗ್, ಡಿಬಗ್ಗಿಂಗ್ ಮತ್ತು ಸಹಕಾರದ ಕೌಶಲ್ಯಗಳು ಬೆಳೆಯುತ್ತವೆ.
|
||||
* **ಪೋರ್ಟ್ಫೋಲಿಯೋ ನಿರ್ಮಾಣ:** ಪ್ರಸಿದ್ಧ ಪ್ರಾಜೆಕ್ಟ್ಗಳಲ್ಲಿ ಕೊಡುಗೆ ನೀಡುವುದು ನಿಮ್ಮ CV ಮತ್ತು GitHub ಪ್ರೊಫೈಲ್ ಅನ್ನು ಬಲಪಡಿಸುತ್ತದೆ.
|
||||
* **ನೆಟ್ವರ್ಕಿಂಗ್:** ಜಗತ್ತಿನಾದ್ಯಂತದ ಡೆವಲಪರ್ಗಳ ಜೊತೆ ಸಂಪರ್ಕ ಬೆಳೆಸಿ, ತಜ್ಞರಿಂದ ಕಲಿಯಿರಿ ಮತ್ತು ಸಮುದಾಯದ ಭಾಗವಾಗಿರಿ.
|
||||
* **ಹಿಂದಿರುಗಿಸುವುದು:** ನಾವು ಪ್ರತಿದಿನ ಬಳಸುವ ಅನೇಕ ಸಾಫ್ಟ್ವೇರ್ಗಳ ಆಧಾರ ಓಪನ್ಸೋರ್ಸ್ ಆಗಿದೆ. ಕೊಡುಗೆ ನೀಡುವುದು ಧನ್ಯವಾದ ಹೇಳುವ ಮಾರ್ಗ.
|
||||
* **ವೃತ್ತಿ ಅವಕಾಶಗಳು:** ಅನೇಕ ಕಂಪನಿಗಳು ಓಪನ್ಸೋರ್ಸ್ ಅನುಭವ ಹೊಂದಿರುವ ಡೆವಲಪರ್ಗಳನ್ನು ಹುಡುಕುತ್ತವೆ ಏಕೆಂದರೆ ಇದು ಪ್ರೊಆಕ್ಟಿವಿಟಿ ಮತ್ತು ತಂಡದ ಕೆಲಸವನ್ನು ತೋರಿಸುತ್ತದೆ.
|
||||
|
||||
## ಹೇಗೆ ಪ್ರಾರಂಭಿಸಬೇಕು?
|
||||
|
||||
### 1. ಸರಿಯಾದ ಪ್ರಾಜೆಕ್ಟ್ ಆಯ್ಕೆಮಾಡಿ
|
||||
|
||||
ನಿಮ್ಮ ಆಸಕ್ತಿಗಳು ಮತ್ತು ಕೌಶಲ್ಯಗಳಿಗೆ ಹೊಂದಿಕೊಳ್ಳುವ ಪ್ರಾಜೆಕ್ಟ್ಗಳನ್ನು ಆರಿಸಿ:
|
||||
|
||||
* **GitHub ಅನ್ವೇಷಿಸಿ:** `good-first-issue`, `help-wanted` ಮುಂತಾದ ಲೇಬಲ್ಗಳಿರುವ ಟಾಸ್ಕ್ಗಳನ್ನು ಹುಡುಕಿ.
|
||||
* **ಪ್ರೋಗ್ರಾಂಗಳಲ್ಲಿ ಭಾಗವಹಿಸಿ:** Google Summer of Code, Hacktoberfest ಮುಂತಾದವು ಉತ್ತಮ ಅವಕಾಶಗಳು.
|
||||
* **ನೀವು ಬಳಸುವ ಉಪಕರಣಗಳು:** ನೀವು ಬಳಸುವ ಲೈಬ್ರರಿ ಅಥವಾ ಫ್ರೇಮ್ವರ್ಕ್ಗಳಲ್ಲಿ ಕೊಡುಗೆ ನೀಡಿ.
|
||||
|
||||
### 2. ಪ್ರಾಜೆಕ್ಟ್ನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ
|
||||
|
||||
* **ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಓದಿ:** README ಮತ್ತು ಕೊಡುಗೆ ಮಾರ್ಗಸೂಚಿಗಳನ್ನು ಗಮನಿಸಿ.
|
||||
* **ಕೋಡ್ನ್ನು ಅಧ್ಯಯನ ಮಾಡಿ:** ಪ್ರಾಜೆಕ್ಟ್ನ ರಚನೆ ಮತ್ತು ಕೋಡಿಂಗ್ ಶೈಲಿಯನ್ನು ತಿಳಿದುಕೊಳ್ಳಿ.
|
||||
* **ಸಮುದಾಯಕ್ಕೆ ಸೇರಿ:** Slack, Discord ಅಥವಾ ಫೋರಮ್ಗಳಲ್ಲಿ ಚರ್ಚೆಗಳಲ್ಲಿ ಭಾಗವಹಿಸಿ.
|
||||
|
||||
### 3. ಚಿಕ್ಕ ಹಂತಗಳಿಂದ ಪ್ರಾರಂಭಿಸಿ
|
||||
|
||||
* **ಬಗ್ಗಳನ್ನು ಸರಿಪಡಿಸಿ:** ಆರಂಭಿಕರಿಗೆ ಅನುಕೂಲಕರವಾದ issues ಹುಡುಕಿ.
|
||||
* **ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಸುಧಾರಿಸಿ:** ಬಹಳ ಉಪಯುಕ್ತವಾದರೂ ಹೆಚ್ಚಾಗಿ ಗಮನಿಸದೆ ಬಿಡಲಾಗುತ್ತದೆ.
|
||||
* **ಟೆಸ್ಟ್ಗಳನ್ನು ಬರೆಯಿರಿ:** ಕೋಡ್ ತಿಳಿಯಲು ಉತ್ತಮ ವಿಧಾನ.
|
||||
|
||||
### 4. ಉತ್ತಮ ಅಭ್ಯಾಸಗಳನ್ನು ಅನುಸರಿಸಿ
|
||||
|
||||
* **Fork ಮತ್ತು Clone ಮಾಡಿ**
|
||||
* **ಪ್ರತ್ಯೇಕ branch ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಿ**
|
||||
* **ಸ್ವಚ್ಛ ಕೋಡ್ ಬರೆಯಿರಿ**
|
||||
* **ನಿಮ್ಮ ಬದಲಾವಣೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ**
|
||||
* **Pull Request ಕಳುಹಿಸಿ:** ಸ್ಪಷ್ಟ ವಿವರಣೆ ನೀಡಿ, ಸಂಬಂಧಿತ issueಗಳನ್ನು ಉಲ್ಲೇಖಿಸಿ ಮತ್ತು feedback ಸ್ವೀಕರಿಸಲು ತೆರೆದಿರಲಿ.
|
||||
|
||||
## ಯಶಸ್ಸಿಗೆ ಸಲಹೆಗಳು
|
||||
|
||||
* **ಸಮರ್ಪಕ ಸಂವಹನ ಮಾಡಿ:** ಗೌರವಪೂರ್ವಕವಾಗಿ ವರ್ತಿಸಿ ಮತ್ತು ಸ್ಪಷ್ಟವಾಗಿ ಪ್ರಶ್ನೆ ಮಾಡಿ.
|
||||
* **ಸ್ಥಿರತೆಯಿಂದಿರಿ:** ಸಣ್ಣ ಕೊಡುಗೆಗಳೂ ಸಮಯದೊಂದಿಗೆ ದೊಡ್ಡ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ.
|
||||
* **ಫೀಡ್ಬ್ಯಾಕ್ನಿಂದ ಕಲಿಯಿರಿ:** ಕೋಡ್ ರಿವ್ಯೂ ಒಳ್ಳೆಯ ಕಲಿಕೆಯ ಅವಕಾಶ.
|
||||
* **ಇತರರಿಗೆ ಸಹಾಯ ಮಾಡಿ:** ನೀವು ಅನುಭವ ಹೊಂದಿದ ಮೇಲೆ ಹೊಸಬರಿಗೆ ಮಾರ್ಗದರ್ಶನ ನೀಡಿ.
|
||||
|
||||
## ಸಾಮಾನ್ಯ ಸವಾಲುಗಳು ಮತ್ತು ಪರಿಹಾರಗಳು
|
||||
|
||||
* **Impostor Syndrome:** ಚಿಕ್ಕ ಕೊಡುಗೆಗಳೂ ಮುಖ್ಯ. ಎಲ್ಲರೂ ಎಲ್ಲಿಂದೋ ಆರಂಭಿಸಿದ್ದಾರೆ.
|
||||
* **ಸಮಯದ ಕೊರತೆ:** ಸಣ್ಣ ಟಾಸ್ಕ್ಗಳಿಂದ ಪ್ರಾರಂಭಿಸಿ. ವಾರಕ್ಕೆ 30 ನಿಮಿಷ ಕೂಡ ಸಾಕು.
|
||||
* **ದೊಡ್ಡ ಕೋಡ್ಬೇಸ್ ಅನ್ನು ನಾವಿಗೇಟ್ ಮಾಡುವುದು:** ಒಂದೊಂದೇ ಘಟಕ concentrate ಮಾಡಿ, documentation ಓದಿ, ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಿ.
|
||||
|
||||
## ಸಮಾರೋಪ
|
||||
|
||||
ಓಪನ್ಸೋರ್ಸ್ಗೆ ಕೊಡುಗೆ ನೀಡುವುದು ವೈಯಕ್ತಿಕ ಮತ್ತು ವೃತ್ತಿಪರ ಬೆಳವಣಿಗೆಗೆ ದೊಡ್ಡ ಅವಕಾಶ. ಸಣ್ಣ ಹಂತಗಳಿಂದ ಆರಂಭಿಸಿ, ನಿಯಮಿತವಾಗಿರಿ, ಸಮುದಾಯದೊಂದಿಗೆ ಸಂವಹನ ಮಾಡಿ — ಹೀಗೆ ನಿಮ್ಮ ಕೌಶಲ್ಯಗಳನ್ನು ಬೆಳೆಸುತ್ತಾ ಪರಿಣಾಮಕಾರಿ ಕೊಡುಗೆಗಳನ್ನು ನೀಡಬಹುದು. ಪ್ರತಿಯೊಂದು ಕೊಡುಗೆಯೂ ಮಹತ್ವದ್ದೇ. ಇಂದೇ ಪ್ರಾರಂಭಿಸಿ — ನಿಮಗೆ ಇಷ್ಟವಾದ ಪ್ರಾಜೆಕ್ಟ್ ಹುಡುಕಿ, ಮೊದಲ ಕೊಡುಗೆ ನೀಡಿ ಮತ್ತು ಜಾಗತಿಕ ಓಪನ್ಸೋರ್ಸ್ ಚಳುವಳಿಯ ಭಾಗವಾಗಿರಿ!
|
||||
|
||||
@@ -0,0 +1,81 @@
|
||||
## 오픈소스 프로젝트는 프로그래머만 기여할 수 있는 것이 아닙니다. 코딩 실력이 없어도 오픈소스 프로젝트에 참여하고 기여할 수 있는 다양한 방법들이 있습니다.
|
||||
|
||||
## 경청하기
|
||||
|
||||
오픈소스의 모든 것은 다른 사람들과의 상호작용을 포함합니다. 여러분은 팀에 합류하려는 것이므로, 커뮤니티와 그 작동 방식을 이해하는 것이 중요합니다. 프로젝트에 불쑥 끼어들어 "안녕하세요, 이 프로젝트는 이렇게 해야 한다고 생각합니다"라고 말하는 것은 일반적으로 좋게 받아들여지지 않습니다. 그런 접근 방식을 환영하는 프로젝트도 있겠지만, 프로젝트가 오랫동안 진행되어 온 경우 그러한 태도가 받아들여질 가능성은 적습니다.
|
||||
**경청하는 것이 프로젝트에 필요한 것을 아는 가장 좋은 방법입니다.**
|
||||
|
||||
1. **메일링 리스트 가입하기**: 많은 프로젝트에서 메일링 리스트는 프로젝트 개발에 대한 주요 커뮤니케이션 수단입니다. 대규모 프로젝트에는 선택할 수 있는 메일링 리스트가 많습니다. 예를 들어, PostgreSQL 프로젝트는 메일링 리스트 페이지에 사용자 중심 리스트 12개 이상과 개발자 리스트 6개를 보유하고 있습니다. 시작하려면 주요 사용자 중심 리스트와 핵심 개발자 리스트를 팔로우하여 경청하는 것을 추천합니다.
|
||||
|
||||
2. **블로그 팔로우하기**: 핵심 개발자들이 운영하는 블로그는 종종 향후 릴리스에 대한 정보와 그 과정에 대한 정보를 제공합니다. 플래닛 사이트는 프로젝트와 관련된 여러 출처의 뉴스 및 블로그 게시물을 모아 보여줍니다. planet.gnome.org나 planet.mysql.com과 같은 플래닛 사이트가 있다면 거기서부터 시작하세요. Google에서 "planet <프로젝트 이름>"으로 검색해보세요.
|
||||
|
||||
3. **IRC 채널 가입하기**: 많은 오픈소스 프로젝트에는 개발자와 사용자가 문제 및 개발에 대해 논의하는 전용 IRC(Internet Relay Chat) 채널이 있습니다. 프로젝트 웹사이트에서 채널 이름과 IRC 네트워크 세부 정보를 확인하세요.
|
||||
|
||||
|
||||
## 티켓 작업하기
|
||||
|
||||
코드는 모든 오픈소스 프로젝트의 핵심이지만, 코드를 작성하는 것만이 기여하는 유일한 방법이라고 생각하지 마세요. 코드 유지 보수 및 코드를 둘러싼 시스템은 새로운 기능을 만들고 버그를 수정하는 데 급급하여 종종 소홀히 다루어집니다. 이러한 영역을 프로젝트에 발을 들여놓을 수 있는 쉬운 방법으로 살펴보세요. 대부분의 프로젝트에는 프로젝트 웹사이트 첫 페이지에 링크되어 있고 문서에 포함된 공개적으로 볼 수 있는 문제 티켓 시스템이 있습니다. 이는 사용자와 개발자 간의 주요 커뮤니케이션 수단입니다. 이를 최신 상태로 유지하는 것은 프로젝트를 돕는 좋은 방법입니다. 티켓 시스템에서 특별한 권한을 얻어야 할 수도 있는데, 대부분의 프로젝트 리더는 티켓 정리를 돕고 싶다고 말하면 기꺼이 권한을 부여할 것입니다.
|
||||
|
||||
4. **버그 진단하기**: 버그는 종종 제대로 보고되지 않습니다.
|
||||
버그를 진단하고 분류하는 것은 개발자가 문제의 세부 사항을 파악하는 데 드는 수고를 덜어줄 수 있습니다. 사용자가 "X를 하면 소프트웨어가 작동하지 않습니다"라고 보고했다면, 그 문제의 구체적인 내용이 무엇인지 파악하는 데 시간을 투자하세요. 반복 가능한가요? 문제를 반복적으로 발생시킬 수 있는 일련의 단계를 만들 수 있나요? 특정 브라우저에서만 발생하거나 특정 배포판에서만 발생하는 등 문제를 좁힐 수 있나요?
|
||||
|
||||
문제의 원인을 모르더라도, 상황을 좁히기 위해 기울인 노력은 다른 사람이 문제를 해결하는 것을 더 쉽게 만듭니다. 발견한 모든 것을 모든 사람이 볼 수 있도록 버그 시스템의 티켓에 추가하세요.
|
||||
|
||||
5. **수정된 버그 닫기**: 종종 버그는 코드베이스에서 수정되지만, 이에 대해 보고된 티켓은 티켓 시스템에서 업데이트되지 않습니다. 이러한 불필요한 것들을 정리하는 것은 시간이 많이 걸릴 수 있지만, 전체 프로젝트에 매우 중요합니다.
|
||||
|
||||
먼저 1년 이상 된 티켓을 티켓 시스템에서 쿼리하여 버그가 여전히 존재하는지 확인하세요. 프로젝트의 릴리스 변경 로그를 확인하여 버그가 수정되었고 닫을 수 있는지 확인하세요. 수정된 것으로 알려져 있다면 티켓에 버전 번호를 기록하고 닫으세요.
|
||||
|
||||
소프트웨어의 최신 버전으로 버그를 재현해보세요. 최신 버전으로 재현할 수 없다면 티켓에 기록하고 닫으세요. 여전히 존재한다면 티켓에 기록하고 열어 두세요.
|
||||
|
||||
|
||||
|
||||
## 코드 작업하기
|
||||
|
||||
모든 경험 수준의 프로그래머가 프로젝트의 코드를 도울 수 있습니다. 좋아하는 프로젝트에 실질적인 기여를 하기 위해 코딩 천재가 되어야 한다고 생각하지 마세요.
|
||||
|
||||
작업에 코드 수정이 포함된다면, 프로젝트가 기여자로부터 코드를 받는 데 사용하는 방법을 조사하세요. 각 프로젝트마다 고유한 워크플로우가 있으므로, 코드를 제출하기 전에 어떻게 해야 하는지 물어보세요.
|
||||
|
||||
예를 들어, PostgreSQL 프로젝트는 매우 엄격한 프로세스를 따릅니다. 코드 수정은 핵심 개발자들이 변경 사항의 모든 측면을 면밀히 조사하는 메일링 리스트에 패치 형태로 전송됩니다. 반대편에는 Parrot과 같이 코드베이스에 커밋 권한을 쉽게 얻을 수 있는 프로젝트도 있습니다. 프로젝트가 GitHub를 사용하는 경우, GitHub의 풀 리퀘스트 기능을 사용하는 워크플로우가 있을 수 있습니다. 어떤 프로젝트도 똑같지 않습니다.
|
||||
|
||||
코드를 수정할 때마다 커뮤니티의 책임 있는 구성원으로서 행동하고 코드 스타일을 나머지 코드베이스와 일치시키도록 하세요. 추가하거나 수정하는 코드는 다른 코드와 같아야 합니다. 중괄호 스타일이나 들여쓰기를 위한 공백 처리가 마음에 들지 않을 수도 있지만, 기존 표준과 일치하지 않는 코드 변경을 제출하는 것은 무례한 행동입니다. 이는 "당신의 스타일이 마음에 들지 않고 내 스타일이 더 낫다고 생각하므로 내 방식대로 해야 합니다"라고 말하는 것과 같습니다.
|
||||
|
||||
6. **베타 또는 릴리스 후보 테스트하기**: 여러 플랫폼에서 실행되도록 설계된 모든 프로젝트는 온갖 종류의 이식성 문제를 겪을 수 있습니다. 릴리스가 다가오고 베타 또는 릴리스 후보가 게시되면 프로젝트 리더는 많은 다른 사람들이 많은 다른 플랫폼에서 테스트하기를 바랍니다. 여러분은 그 사람들 중 한 명이 되어 패키지가 자신의 플랫폼에서 작동하는지 확인하는 데 도움을 줄 수 있습니다.
|
||||
|
||||
일반적으로 소프트웨어를 다운로드, 빌드 및 테스트하기만 하면 되지만, 흔하지 않은 배포판이나 하드웨어를 사용하고 있다면 프로젝트에 엄청난 가치를 제공할 수 있습니다. 빌드 및 테스트가 작동한다고 보고하는 것만으로도 프로젝트 리더는 임박한 릴리스가 견고하다는 것을 알 수 있습니다.
|
||||
|
||||
|
||||
7. **버그 수정하기**: 이것은 일반적으로 코드 작업을 시작하려는 기여자들의 시작점입니다. 간단합니다. 티켓 시스템에서 흥미롭게 들리는 버그를 찾아 코드에서 수정하려고 시도하세요. 적절하다면 코드에 수정 사항을 문서화하세요. 수정한 코드 부분을 테스트하기 위해 테스트 스위트에 테스트를 추가하는 것이 좋습니다. 일부 프로젝트에서는 버그 수정에 테스트를 포함하도록 요구합니다. 이 익숙하지 않은 코드베이스를 살펴보면서 메모를 계속 작성하세요. 버그를 수정할 수 없더라도 수정 시도의 일환으로 발견한 내용을 티켓에 문서화하세요. 여러분이 발견한 내용은 다음에 오는 사람들에게 도움이 됩니다.
|
||||
|
||||
|
||||
8. **테스트 작성하기**: 대부분의 프로젝트에는 코드를 테스트하는 테스트 스위트가 있지만, 더 많은 테스트를 추가할 수 없는 테스트 스위트는 상상하기 어렵습니다. C 언어용 gcov 또는 Perl용 Devel::Cover와 같은 테스트 커버리지 도구를 사용하여 테스트 스위트에서 테스트되지 않는 소스 코드 영역을 식별하세요. 그런 다음, 테스트를 스위트에 추가하여 해당 영역을 커버하세요.
|
||||
|
||||
|
||||
9. **컴파일러 경고 잠재우기**: 많은 C 기반 프로젝트의 빌드 프로세스는 종종 이상한 컴파일러 경고 플래그를 화면에 뿜어냅니다. 이러한 경고는 일반적으로 문제의 지표는 아니지만 그렇게 보일 수 있습니다. 너무 많은 경고는 컴파일러가 거짓 경고를 하는 것처럼 들리게 할 수 있습니다. 코드가 실제로 버그를 숨기고 있는지 확인하세요. 그렇지 않다면, 소스를 수정하여 잠재우는 것은 이러한 오탐을 숨기는 데 도움이 됩니다.
|
||||
|
||||
|
||||
10. **주석 추가하기**: 코드를 살펴보는 동안 혼란스러운 부분이 있을 수 있습니다. 여러분이 혼란스러웠다면 다른 사람들도 마찬가지일 가능성이 높습니다. 코드에 문서화하고 패치를 제출하세요.
|
||||
|
||||
|
||||
## 문서 작업하기
|
||||
|
||||
문서는 일반적으로 프로젝트에서 소홀히 다루어지는 부분입니다. 또한 프로젝트에 익숙한 사람들의 관점에서 작성되어, 막 시작하는 사람의 관점이 아닌 경우도 있습니다. "이 매뉴얼은 내가 이미 이 패키지를 사용하는 방법을 알고 있다고 기대하는 것 같아"라고 생각한 적이 있다면 제가 무슨 말을 하는지 아실 겁니다. 종종 새로운 시선은 프로젝트와 가까운 사람들이 알아차리지 못하는 문서의 결함을 지적할 수 있습니다.
|
||||
|
||||
11. **예시 만들기**: 예시가 너무 많은 프로젝트는 없습니다. 웹 API든, 루틴 라이브러리든, Gimp와 같은 GUI 앱이든, 명령줄 도구든, 올바른 사용법에 대한 좋은 예시는 수백 페이지의 문서보다 더 명확하고 빠르게 소프트웨어의 올바른 사용법을 설명할 수 있습니다. API나 라이브러리의 경우, 도구를 사용하는 예시 프로그램을 만드세요. 이는 여러분이 작성한 코드에서 최소한의 필수적인 부분만 추출하여 만들 수도 있습니다. 도구의 경우, 일상생활에서 어떻게 사용했는지에 대한 실제 사례를 보여주세요. 시각적인 것을 선호한다면, 애플리케이션 설치 방법과 같은 중요한 프로세스의 화면 캡처를 만드는 것을 고려해 보세요.
|
||||
|
||||
|
||||
|
||||
## 커뮤니티와 함께 작업하기
|
||||
|
||||
오픈소스는 코드에 관한 것만이 아닙니다. 커뮤니티가 오픈소스가 작동하도록 만듭니다. 커뮤니티를 구축하는 데 도움을 줄 수 있는 방법은 다음과 같습니다.
|
||||
|
||||
12. **질문에 답하기**: 커뮤니티를 구축하는 가장 좋은 방법은 다른 사람들을 돕는 것입니다. 특히 막 시작하는 사람들의 질문에 답하는 것은 프로젝트가 성장하고 번성하는 데 매우 중요합니다. 초보자를 돕는 데 시간을 투자하는 것은, 비록 "RTFM(매뉴얼을 읽으세요)"이라고 간단히 대답할 수 있는 질문일지라도, 나중에 또 다른 활발한 커뮤니티 구성원을 얻는 데 도움이 됩니다. 모든 사람은 어디서든 시작하며, 프로젝트는 활력을 유지하려면 꾸준한 인력 유입이 필요합니다.
|
||||
|
||||
13. **블로그 게시물 작성하기**: 블로그가 있다면, 사용하고 있는 프로젝트에 대한 경험에 대해 글을 써보세요. 소프트웨어를 사용하면서 직면했던 문제와 그것을 해결하기 위해 무엇을 했는지 이야기해 주세요. 이렇게 하면 두 가지 방식으로 도움이 됩니다. 하나는 프로젝트를 주변 사람들의 마음에 계속 각인시키는 데 도움이 되고, 다른 하나는 미래에 여러분과 같은 문제를 겪고 웹에서 해결책을 검색하는 모든 사람을 위한 기록을 만드는 데 도움이 됩니다. (기술적인 모험에 대한 블로그는 나중에 해당 소프트웨어를 사용하는 직업을 찾을 때 실제 경험을 보여주는 훌륭한 방법이기도 합니다.)
|
||||
|
||||
14. **웹사이트 개선하기**: 웹 디자인 기술이 있고 웹사이트를 개선하여 프로젝트의 대중적인 이미지를 향상시킬 수 있다면, 이는 잘 보낸 시간입니다. 아마도 프로젝트는 그래픽 전면 개편이나 프로젝트를 식별할 로고가 필요할 수도 있습니다. 이러한 기술은 커뮤니티에 부족할 수 있습니다. 저도 제 프로젝트 웹사이트에 그래픽 디자인 지원을 받을 수 있다면 좋을 것 같습니다.
|
||||
|
||||
15. **기술 문서 작성하기**: 애플리케이션이나 소프트웨어가 어떻게 작동하는지 설명할 수 있다면, 그것에 대한 기술 문서를 작성할 수 있습니다. 특히 일반 대중이 읽을 수 있도록 기술 문서를 업데이트, 개편, 확장 또는 만들고자 하는 오픈소스 프로젝트라면 더욱 그렇습니다. 일반 영어로 더 많이 쓸수록 좋습니다. 가장 좋은 점은 기술 문서를 작성하기 위해 프로그래머가 될 필요가 없다는 것입니다.
|
||||
|
||||
무엇보다도, 주변 사람들이 논의하는 내용을 경청하세요. 절실한 필요를 알아볼 수 있는지 살펴보세요. 예를 들어, 최근 Parrot 개발자 메일링 리스트에서 기존 Trac 설치를 버리고 GitHub를 문제 티켓 시스템으로 사용하기로 결정했습니다. 일부 사람들은 티켓을 GitHub 시스템으로 변환할 방법이 없었기 때문에 이 결정에 반대했습니다. 하루 동안 논쟁이 오고 간 후, 제가 끼어들어 "제가 변환기를 작성하면 어떨까요?"라고 말했습니다. 사람들은 그 아이디어에 열광했습니다. 저는 450개 이상의 티켓에 대한 변환 프로그램을 작성하는 데 시간을 보냈고, 그래서 티켓 기록을 하나도 잃지 않았습니다. 큰 성공이었습니다. 저는 참여할 수 있었고, 핵심 개발자들은 Parrot 작업에 집중할 수 있었습니다.
|
||||
|
||||
16. **다른 사람들을 가르치고 돕기**: 어떤 주제에 대해 더 많이 배우는 가장 좋은 방법은 그것을 가르치려고 노력하는 것입니다. 최고의 교사는 복잡한 내용을 간단한 예시로 설명할 수 있는 사람입니다. 따라서 최고의 학습자가 되고 프로그래밍 세계에서 최고가 되려면 최고의 교사가 되기 위해 노력해야 합니다. 다른 사람들을 가르치는 것은 자신에 대해 더 나은 기분을 느끼게 하고 직업에서 더 나은 기술과 지식을 얻는 데 도움이 될 것입니다. 누군가에게 도움을 받으면 혼자 간직하지 말고 다른 사람들과 공유하세요. 세상을 더 살기 좋은 곳으로 만드세요.
|
||||
+71
@@ -0,0 +1,71 @@
|
||||
# Cum sa contribuiti la proiectele Open Source: Un ghid detaliat pentru incepatori
|
||||
|
||||
Pe scurt: Daca sunteti nerabdator/nerabdatoare sa creati primul Pull Request pe un proiect Open Source, folositi instructiunile de aici: [Readme](https://github.com/firstcontributions/first-contributions)
|
||||
|
||||
Contributiile la proiectele Open Source reprezinta una dintre cele mai bune metode de a te dezvolta ca programator/programatoare, a-ti dezvolta portofoliul si a da ceva inapoi comunitatii. Fie ca esti un programator senior sau doar ai inceput, proiectele Open Source ofera foarte multe oportunitati de a invata, colabora si a avea un impact pozitiv. In acest ghid, vom trece prin tot ceea ce trebuie sa stiti pentru a contribui la proiectele Open Source, de la a gasi proiectul protrivit si pana la a realiza prima contributie.
|
||||
|
||||
## De ce sa contribuiti la proiectele Open Source?
|
||||
|
||||
Inainte sa vorbim despre "cum", sa exploram "de ce". Contribuirea la proiectele Open Source ofera numeroase beneficii:
|
||||
|
||||
* Dezvoltarea abilitatilor: Proiectele Open Source va expun la cod sursa din proiecte reale, ajutandu-va la imbunatatirea abilitatilor dvs. de programare, depanare si colaborare.
|
||||
* Construirea unui Portofoliu: Contributiile la proiectele bine cunoscute va pot imbogati CV-ul si profilul dvs. de pe Github, ajutandu-va sa iesiti in evidenta in fata potentialilor angajatori.
|
||||
* Networking (Colaborarea, socializarea cu scop profesional): Va veti conecta cu dezvoltatori din intreaga lume, veti invata de la experti si veti face parte la randul dvs. din aceasta comunitate globala.
|
||||
* Sa dai inapoi (ca multumire): Proiectele Open Source stau la baza multor aplicatii/programe software pe care le folosim zilnic. Contributiile sunt un mod de a sustine uneltele si tehnologiile pe care va bazati/de care depindeti.
|
||||
* Oportunitati de cariera: Multe companii cauta in mod activ programatori cu experienta pe proiecte Open Source deoarece astfel se demonstreaza initiativa, proactivitatea si lucrul in echipa.
|
||||
|
||||
## Cum sa incepeti sa contribuiti pe proiectele Open Source
|
||||
|
||||
### 1. Alegeti Proiectul potrivit
|
||||
|
||||
Identificarea proiectului potrivit este cruciala. Cautati proiecte care se aliniaza intereselor, nivelurilor abilitatilor si telurilor dvs.. Le puteti gasi intr-unul din modurile urmatoare:
|
||||
|
||||
* Explorati Github: Folositi pagina Github Explore sau cautati topicurile precum "necesita-ajutor", "ajutor-cerut", "good-first-issue", "help-wanted" etc.
|
||||
* Cautati programe dedicate Open Source: Programe ca Google Summer of Code, Hacktoberfest si altele sunt bune pentru incepatori.
|
||||
* Urmariti proiectele dedicate uneltelor/programelor tale (favorite): Contribuie la librarii, frameworks, unelte sau programe pe care deja le folositi.
|
||||
|
||||
### 2. Intelegeti proiectul
|
||||
|
||||
Inainte sa contribuiti, este indicat sa dedicati timp pentru a intelege proiectul:
|
||||
|
||||
* Cititi documentatia: Incepeti cu fisierul README, cele mai bune practici, reguli si indicatii pentru contributii si regulamentul de conduita.
|
||||
* Exploreaza codul sursa: Familiarizati-va cu structura proiectului si stilul de programare (indentari, conventii de nume, etc.).
|
||||
* Alaturati-va comunitatii: Participati la discutiile de pe forumuri, Slack sau Discord pentru a va acomoda mai usor in comunitate.
|
||||
|
||||
### 3. Incepeti cu pasi mici
|
||||
|
||||
Incepeti cu pasi mici, sarcini de lucru pe care le puteti dezvolta, care va vor ajuta sa deveniti mai increzator/increzatoare, precum:
|
||||
|
||||
* Repararea defectelor: Cauta "issues" ((cerinte de) sarcini de lucru) pe pagina dedicata, care au etichete precum "sarcina-buna-de-inceput", "pentru-incepatori", "incepatori", "good-first-issue", "beginner-friendly" etc.
|
||||
* Imbunatatiti documentatia: Actualizarile documentatiei sunt adesea trecute cu vederea, insa aduc multa plus-valoare.
|
||||
* Scrieti teste: Adaugarea de teste (teste unitare, teste de integrare, etc.) este un mod foarte bun de a contribui si a invata mai bine codul sursa.
|
||||
|
||||
### 4. Folositi cele mai bune practici
|
||||
|
||||
Cand contribuiti, este bine sa respectati indicatiile pentru cele mai bune practici:
|
||||
|
||||
* Bifurca si Cloneaza: Bifurcati (fork) si clonati codul sursa (depozitul) pe masina dvs. locala.
|
||||
* Creati o ramura: Lucrati pe o ramura separata pentru a face modificarile dvs..
|
||||
* Scrieti cod curat: Urmariti standardele de a scrie cod sursa si scrieti cod clar, curat, citibil, concis.
|
||||
* Testati modificarile: Asigurati-va ca modificarile dvs. nu vor afecta functionalitatea existenta.
|
||||
* Creati un Pull Request (cerere de unificare cod sursa intre doua ramuri): Faceti o cerere de unificare a versiunii dvs. de cod sursa cu cel existent pe alta ramura (de obicei cea principala), unde trebuie sa aveti o descriere clara a PR-ului, referentiati alte sarcini de lucru corelate si fiti deschisi la feedback.
|
||||
|
||||
## Sfaturi pentru a avea succes in proiectele Open Source
|
||||
|
||||
Comunicati eficient si eficace: Fiti respectuosi si comportati-va in mod profesional in toate interactiunile. Puneti intrebari cand nu sunteti siguri de cerinte. Aveti rabdare in timpul procesului de evaluare/revizuire.
|
||||
|
||||
Fiti consistenti: Contributiile regulate, chiar si cele mici, pot avea un impact mare in timp.
|
||||
|
||||
Invatati din feedback: Evaluarile de cod sursa sunt un prilej de invatare. Acceptati rezultatele acestor evaluari si va veti imbunatati abilitatile.
|
||||
|
||||
Dati inapoi (ceva comunitatii): Odata ce sunteti comfortabil(a) cu procesul de PR, ajutati-i si pe altii in acest proces, raspundeti-le la intrebari sau chiar fiti mentor pentru incepatori.
|
||||
|
||||
## Provocari comune si cum sa le depasiti
|
||||
|
||||
* Sindromul Impostorului: Multi incepatori simt ca nu au destule abilitati pentru a contribui. Retineti ca toti au inceput de undeva si ca pana si contributiile mici conteaza.
|
||||
* Gasirea timpului necesari: Incepeti cu sarcini de lucru mici, pe care le puteti face. Pana si 30 de minute pe saptamana pot face o diferenta.
|
||||
* Navigarea unui depozit mare de cod sursa: Impartiti procesul de invatare: Incepeti prin a citi in detaliu documentatia - Concentrati-va pe intelegerea unei singure componente la un moment dat - Folositi toate uneltele pentru depanare de care dispuneti - Nu ezitati sa puneti intrebari pentru clarificari
|
||||
|
||||
## Concluzie
|
||||
|
||||
Contributia la proiectele Open Source este o calatorie/aventura/un proces care va ofera imense posibilitati de dezvoltare personala si profesionala. Incepand cu pasi mici, ramanand consistenti si interactionand cu comunitatea, puteti face contributii de impact in timp ce va imbunatatiti abilitatile. Tineti minte ca proiectele Open Source se dezvolta prin colaborare si ca fiecare contributie - indiferent de cat de mica ar fi - ajuta la imbunatatirea mediului digital. Sunteti gata sa incepeti? Gasiti un proiect care va atrage, realizati prima contributie si alaturati-va miscarii globale Open Source astazi!
|
||||
+94
@@ -0,0 +1,94 @@
|
||||
# ஓபன் சோர்ஸிற்குப் பயனளிக்க எப்படி: ஒரு விரிவான வழிகாட்டி (குவிகட்டிய தொடக்கத்திற்காக)
|
||||
|
||||
**TL;DR** - நீங்கள் ஓபன் சோர்ஸ் திட்டத்தில் உங்கள் முதல் புல் ரிக்வஸ்டை செய்ய விரும்பினால், [Readme](https://github.com/firstcontributions/first-contributions) லுள்ள வழிமுறைகளைப் பின்பற்றுங்கள். நான் ஒரு சிறிய பிழையை திருத்தும் பங்களிப்பை என் முதல் பங்களிப்பாகச் செய்கிறேன்.
|
||||
|
||||
ஓபன் சோர்ஸிற்குப் பயனளிப்பது ஒரு மென்பொருள் டெவலப்பராக வளரவும், உங்கள் போர்ட்ஃபோலியோவை உருவாக்கவும், சமூகத்திற்குப் பங்களிக்கவும் சிறந்த வழிகளில் ஒன்றாகும். நீங்கள் அனுபவம் வாய்ந்த நிரலாளராக இருந்தாலும், அல்லது புதியதாக இருந்தாலும், ஓபன் சோர்ஸ் உங்களுக்கு நிறைய கற்றல், இணைப்பு, மற்றும் தாக்கம் செலுத்தும் வாய்ப்புகளை வழங்குகிறது.
|
||||
|
||||
இந்த வழிகாட்டியில், சரியான திட்டத்தைத் தேர்ந்தெடுப்பதிலிருந்து உங்கள் முதல் பங்களிப்பைச் செய்வது வரை, ஓபன் சோர்ஸில் பங்களிப்பதற்கான அனைத்து முக்கிய விஷயங்களையும் ஆராய்வோம்.
|
||||
|
||||
---
|
||||
|
||||
## ஏன் ஓபன் சோர்ஸில் பங்களிக்க வேண்டும்?
|
||||
|
||||
"எப்படி" என்பதைப் பார்க்கும் முன், "ஏன்" என்பதை ஆராய்வோம். ஓபன் சோர்ஸில் பங்களிப்பது பல நன்மைகளை வழங்குகிறது:
|
||||
|
||||
- **திறமைகளை மேம்படுத்துதல்** – உண்மையான புரொஜெக்ட் கோடுகளைப் பார்க்க வாய்ப்பு கிடைக்கும், எங்கேயும் சேர முடியாத அனுபவம் கிடைக்கும்.
|
||||
- **போர்ட்ஃபோலியோ உருவாக்கம்** – பிரபலமான ஓபன் சோர்ஸ் திட்டங்களில் பங்களிப்பது உங்கள் ரெஸ்யூமேயை மெருகூட்டும்.
|
||||
- **நெட்வொர்க்கிங்** – உலகளாவிய டெவலப்பர்களுடன் இணைவது, புதிய விஷயங்களைப் பழகுவது.
|
||||
- **சமூகத்திற்குப் பங்களிக்க** – நாம் தினமும் பயன்படுத்தும் மென்பொருள்களுக்கு உதவிக்கரம் நீட்டும் வாய்ப்பு.
|
||||
- **வேலை வாய்ப்புகள்** – ஓபன் சோர்ஸ் அனுபவம் கொண்டவர்களை பல நிறுவனங்கள் விரும்பி பணியமர்த்துகின்றன.
|
||||
|
||||
---
|
||||
|
||||
## ஓபன் சோர்ஸில் பங்களிக்க எப்படி தொடங்கலாம்?
|
||||
|
||||
### 1. சரியான திட்டத்தைத் தேர்ந்தெடுங்கள்
|
||||
|
||||
உங்களுக்குப் பொருத்தமான திட்டத்தை கண்டுபிடிப்பது முக்கியம். இதைப் பற்றிச் சில வழிகள்:
|
||||
|
||||
- **GitHub-ஐ ஆராயுங்கள்** – ["good-first-issue"](https://github.com/search?q=label%3Agood-first-issue) போன்ற தொடக்க நபர்களுக்கான குறிச்சொற்களைப் பயன்படுத்தி தேடுங்கள்.
|
||||
- **ஓபன் சோர்ஸ் நிகழ்ச்சிகளைப் பின்பற்றுங்கள்** – Google Summer of Code, Hacktoberfest போன்றவை சிறந்த தொடக்க புள்ளிகள்.
|
||||
- **உங்களுக்குப் பழக்கமான கருவிகளைத் தேர்வு செய்யுங்கள்** – நீங்கள் பயன்படுத்தும் புத்தகங்கள், libraries, frameworks ஆகியவற்றில் பங்களிக்கலாம்.
|
||||
|
||||
---
|
||||
|
||||
### 2. திட்டத்தைப் புரிந்துகொள்ளுங்கள்
|
||||
|
||||
பங்களிக்க முன்பாக, திட்டத்தை முழுமையாகப் புரிந்துகொள்ள முயற்சி செய்யுங்கள்:
|
||||
|
||||
- **README மற்றும் வழிமுறைகளை வாசிக்கவும்** – பங்களிப்பு வழிகாட்டி, கோட்பாடு (code of conduct) போன்றவற்றைப் பாருங்கள்.
|
||||
- **கோட்பணியை ஆராயுங்கள்** – கோப்புகளின் அமைப்பு, கோடிங் ஸ்டைல் போன்றவற்றை அறிந்து கொள்ளுங்கள்.
|
||||
- **சமூகத்தில் ஈடுபடுங்கள்** – Forums, Slack, Discord போன்ற இடங்களில் கலந்துரையாடுங்கள்.
|
||||
|
||||
---
|
||||
|
||||
### 3. சிறிய பங்களிப்புகளுடன் தொடங்குங்கள்
|
||||
|
||||
முதலில் எளிதான விடயங்களில் பங்களிக்கலாம்:
|
||||
|
||||
- **பிழைகளை சரிசெய்யுங்கள்** – "good-first-issue" அல்லது "beginner-friendly" போன்ற குறிச்சொற்களைப் பயன்படுத்தி சரிபாருங்கள்.
|
||||
- **ஆவணங்களை மேம்படுத்துங்கள்** – Documentation முக்கியமான பங்களிப்பு வழியாக இருக்கலாம்.
|
||||
- **Unit Testing எழுதுங்கள்** – Code coverage அதிகரிக்க இது உதவும்.
|
||||
|
||||
---
|
||||
|
||||
### 4. சிறந்த நடைமுறைகளைப் பின்பற்றுங்கள்
|
||||
|
||||
ஒரு நிரல்பாக பங்களிக்கும்போது, திட்ட விதிமுறைகளைப் பின்பற்றுங்கள்:
|
||||
|
||||
- **Fork & Clone செய்யுங்கள்** – உங்கள் கணக்கில் repository-ஐ fork செய்து, அதை local க்கு clone செய்யுங்கள்.
|
||||
- **Branch-ஐ உருவாக்குங்கள்** – தனியான branch-ல் வேலை செய்யுங்கள்.
|
||||
- **சுத்தமான கோட்களை எழுதுங்கள்** – திட்டத்திற்கேற்ப coding style-ஐ பின்பற்றுங்கள்.
|
||||
- **Test செய்யுங்கள்** – உங்கள் மாற்றங்கள் ஏதாவது பிரச்சனை ஏற்படுத்துகிறதா என்று சரிபாருங்கள்.
|
||||
- **Pull Request (PR) சமர்ப்பியுங்கள்** – PR-க்கு சரியான விளக்கம், issue reference, மற்றும் தயார் இருக்கும் மனப்பான்மை ஆகியவற்றுடன் சமர்ப்பியுங்கள்.
|
||||
|
||||
---
|
||||
|
||||
## ஓபன் சோர்ஸில் வெற்றி பெற சில குறிப்புகள்
|
||||
|
||||
✅ **தெளிவாக தொடர்புகொள்ளுங்கள்** – கேள்விகள் கேளுங்கள், புல்ல ரிக்வஸ்டுக்கு மறுமொழி கொடுப்பவர்களுக்கு நன்றி சொல்லுங்கள்.
|
||||
✅ **தொடர்ச்சியாக பங்களியுங்கள்** – சிறிய சிறிய பங்களிப்புகள் கூட பெரிய தாக்கத்தை ஏற்படுத்தும்.
|
||||
✅ **விமர்சனத்திலிருந்து கற்றுக்கொள்ளுங்கள்** – Code review மூலம் மேம்படுங்கள்.
|
||||
✅ **மற்றவர்களுக்கு உதவுங்கள்** – புல்ல ரிக்வஸ்டுகளை மதிப்பாய்வு செய்யுங்கள், புதியவர்களை வழிநடத்துங்கள்.
|
||||
|
||||
---
|
||||
|
||||
## பொதுவான சவால்கள் & அதை சமாளிக்க வழிகள்
|
||||
|
||||
❌ **Imposter Syndrome (நான் போதுமான திறமையுள்ளவரா? 🤔)**
|
||||
➡️ எல்லோருக்கும் இது வரும். சிறிய பங்களிப்புகளாலும் பெரிய தாக்கத்தை ஏற்படுத்தலாம்.
|
||||
|
||||
❌ **நேரம் இல்லாமை**
|
||||
➡️ ஒரு வாரத்திற்கும் 30 நிமிடங்கள் செலுத்தினாலும், நீங்கள் மெல்ல வளர முடியும்.
|
||||
|
||||
❌ **பெரிய கோட்பணியை புரிந்துகொள்வது கடினம்**
|
||||
➡️ டாக்குமென்டேஷனை வாசியுங்கள், ஒரு பிரிவில் கவனம் செலுத்துங்கள், Debugging tool-களை பயன்படுத்துங்கள்.
|
||||
|
||||
---
|
||||
|
||||
## முடிவுரை
|
||||
|
||||
ஓபன் சோர்ஸில் பங்களிப்பது வளர்ச்சிக்கு மிக நல்ல வழியாகும். சிறிய செயல்களில் தொடங்குங்கள், தொடர்ந்து பங்களியுங்கள், சமூகத்தில் ஈடுபடுங்கள். ஒவ்வொரு பங்களிப்பும் ஓபன் சோர்ஸை மேம்படுத்த உதவுகிறது.
|
||||
|
||||
🚀 **தொடங்க தயார்?**
|
||||
உங்களுக்கு பிடித்த திட்டத்தை தேடுங்கள், உங்கள் முதல் பங்களிப்பைச் செய்யுங்கள், மற்றும் உலகளாவிய ஓபன் சோர்ஸ் இயக்கத்தில் சேருங்கள்! 🎉
|
||||
+73
@@ -0,0 +1,73 @@
|
||||
# ఓపెన్ సోర్స్కు ఎలా సహకరించాలి: ప్రారంభకులకు సమగ్ర మార్గదర్శి
|
||||
|
||||
TL;DR మీరు ఓపెన్ సోర్స్ ప్రాజెక్ట్కి మీ మొదటి పుల్ అభ్యర్థనను చేయాలనుకుంటున్నట్లయితే, [Readme](https://github.com/firstcontributions/first-contributions)లోని సూచనలను అనుసరించండి.
|
||||
|
||||
డెవలపర్గా ఎదగడానికి, మీ పోర్ట్ఫోలియోను రూపొందించడానికి మరియు కమ్యూనిటీకి తిరిగి ఇవ్వడానికి ఓపెన్ సోర్స్కు సహకారం అందించడం అనేది అత్యంత బహుమతినిచ్చే మార్గాలలో ఒకటి. మీరు అనుభవజ్ఞుడైన ప్రోగ్రామర్ అయినా లేదా ఇప్పుడే ప్రారంభించినా, ఓపెన్ సోర్స్ తెలుసుకోవడానికి, సహకరించడానికి మరియు ప్రభావం చూపడానికి అంతులేని అవకాశాలను అందిస్తుంది. ఈ గైడ్లో, సరైన ప్రాజెక్ట్ను కనుగొనడం నుండి మీ మొదటి సహకారం అందించడం వరకు ఓపెన్ సోర్స్కు సహకరించడం గురించి మీరు తెలుసుకోవలసిన ప్రతిదానిని మేము మీకు తెలియజేస్తాము.
|
||||
|
||||
## ఓపెన్ సోర్స్కి ఎందుకు సహకరించాలి?
|
||||
|
||||
"ఎలా"లోకి ప్రవేశించే ముందు, "ఎందుకు" అనేదాన్ని అన్వేషిద్దాం. ఓపెన్ సోర్స్కు సహకారం అందించడం వలన అనేక ప్రయోజనాలను అందిస్తుంది:
|
||||
|
||||
* నైపుణ్యాభివృద్ధి: ఓపెన్ సోర్స్ ప్రాజెక్ట్లు మిమ్మల్ని వాస్తవ ప్రపంచ కోడ్బేస్లకు బహిర్గతం చేస్తాయి, మీ కోడింగ్, డీబగ్గింగ్ మరియు సహకార నైపుణ్యాలను మెరుగుపరచడంలో మీకు సహాయపడతాయి.
|
||||
* పోర్ట్ఫోలియో బిల్డింగ్: ప్రసిద్ధ ప్రాజెక్ట్లకు విరాళాలు మీ రెజ్యూమ్ మరియు GitHub ప్రొఫైల్ను మెరుగుపరుస్తాయి, తద్వారా మీరు సంభావ్య యజమానులకు ప్రత్యేకంగా నిలుస్తారు.
|
||||
* నెట్వర్కింగ్: మీరు ప్రపంచవ్యాప్తంగా ఉన్న డెవలపర్లతో కనెక్ట్ అవుతారు, నిపుణుల నుండి నేర్చుకుంటారు మరియు గ్లోబల్ కమ్యూనిటీలో భాగం అవుతారు.
|
||||
* గివింగ్ బ్యాక్: ఓపెన్ సోర్స్ మనం రోజూ ఉపయోగించే చాలా సాఫ్ట్వేర్లకు శక్తినిస్తుంది. మీరు ఆధారపడే సాధనాలు మరియు సాంకేతికతలకు మద్దతు ఇవ్వడానికి సహకారం అందించడం ఒక మార్గం.
|
||||
* కెరీర్ అవకాశాలు: చాలా కంపెనీలు ఓపెన్ సోర్స్ అనుభవంతో డెవలపర్లను చురుకుగా కోరుకుంటాయి, ఎందుకంటే ఇది చొరవ మరియు జట్టుకృషిని ప్రదర్శిస్తుంది.
|
||||
|
||||
## ఓపెన్ సోర్స్ కంట్రిబ్యూషన్లతో ఎలా ప్రారంభించాలి
|
||||
|
||||
### 1. సరైన ప్రాజెక్ట్ను ఎంచుకోండి
|
||||
|
||||
సరైన ప్రాజెక్ట్ను కనుగొనడం చాలా ముఖ్యం. మీ ఆసక్తులు, నైపుణ్యం స్థాయి మరియు లక్ష్యాలకు అనుగుణంగా ఉండే ప్రాజెక్ట్ల కోసం చూడండి. వాటిని ఎలా కనుగొనాలో ఇక్కడ ఉంది:
|
||||
|
||||
* GitHubని అన్వేషించండి: GitHub యొక్క అన్వేషణ పేజీని ఉపయోగించండి లేదా "గుడ్-ఫస్ట్-ఇష్యూ" లేదా "హెల్ప్-వాంటెడ్" వంటి అంశాల కోసం శోధించండి.
|
||||
* ఓపెన్ సోర్స్ ప్రోగ్రామ్లను తనిఖీ చేయండి: గూగుల్ సమ్మర్ ఆఫ్ కోడ్ లేదా హ్యాక్టోబర్ఫెస్ట్ వంటి ప్రోగ్రామ్లు ప్రారంభకులకు గొప్పవి.
|
||||
* మీ సాధనాలను అనుసరించండి: మీరు ఇప్పటికే ఉపయోగిస్తున్న లైబ్రరీలు, ఫ్రేమ్వర్క్లు లేదా సాధనాలకు సహకరించండి.
|
||||
|
||||
### 2. ప్రాజెక్ట్ను అర్థం చేసుకోండి
|
||||
|
||||
సహకరించే ముందు, ప్రాజెక్ట్ను అర్థం చేసుకోవడానికి సమయాన్ని వెచ్చించండి:
|
||||
|
||||
* డాక్యుమెంటేషన్ను చదవండి: README ఫైల్, సహకార మార్గదర్శకాలు మరియు ప్రవర్తనా నియమావళితో ప్రారంభించండి.
|
||||
* కోడ్బేస్ను అన్వేషించండి: ప్రాజెక్ట్ నిర్మాణం మరియు కోడింగ్ శైలితో మిమ్మల్ని మీరు పరిచయం చేసుకోండి.
|
||||
* సంఘంలో చేరండి: కమ్యూనిటీ కోసం ఒక అనుభూతిని పొందడానికి ఫోరమ్లు, స్లాక్ లేదా డిస్కార్డ్పై చర్చల్లో పాల్గొనండి.
|
||||
|
||||
### 3. చిన్నగా ప్రారంభించండి
|
||||
|
||||
విశ్వాసాన్ని పెంపొందించడానికి చిన్న, నిర్వహించదగిన పనులతో ప్రారంభించండి:
|
||||
|
||||
* బగ్లను పరిష్కరించండి: "మంచి-మొదటి సమస్య" లేదా "బిగినర్స్-ఫ్రెండ్లీ" అని లేబుల్ చేయబడిన సమస్యల కోసం చూడండి.
|
||||
* డాక్యుమెంటేషన్ను మెరుగుపరచండి: డాక్యుమెంటేషన్ అప్డేట్లు తరచుగా విస్మరించబడతాయి కానీ చాలా విలువైనవి.
|
||||
* పరీక్షలు రాయండి: పరీక్షలను జోడించడం అనేది కోడ్బేస్ గురించి తెలుసుకోవడానికి మరియు సహకరించడానికి ఒక గొప్ప మార్గం.
|
||||
|
||||
### 4. ఉత్తమ పద్ధతులను అనుసరించండి
|
||||
|
||||
సహకరించేటప్పుడు, ప్రాజెక్ట్ మార్గదర్శకాలకు కట్టుబడి ఉండండి:
|
||||
|
||||
* ఫోర్క్ మరియు క్లోన్: రిపోజిటరీని ఫోర్క్ చేసి మీ స్థానిక మెషీన్కు క్లోన్ చేయండి.
|
||||
* ఒక శాఖను సృష్టించండి: మీ మార్పుల కోసం ప్రత్యేక శాఖలో పని చేయండి.
|
||||
* క్లీన్ కోడ్ వ్రాయండి: ప్రాజెక్ట్ యొక్క కోడింగ్ ప్రమాణాలను అనుసరించండి మరియు స్పష్టమైన, సంక్షిప్త కోడ్ను వ్రాయండి.
|
||||
* మీ మార్పులను పరీక్షించండి: మీ మార్పులు ఇప్పటికే ఉన్న కార్యాచరణను విచ్ఛిన్నం చేయలేదని నిర్ధారించుకోండి.
|
||||
* ఒక పుల్ అభ్యర్థన (PR) సమర్పించండి: స్పష్టమైన PR వివరణ, సూచన సంబంధిత సమస్యలను వ్రాయండి మరియు అభిప్రాయానికి సిద్ధంగా ఉండండి.
|
||||
|
||||
## ఓపెన్ సోర్స్లో విజయం కోసం చిట్కాలు
|
||||
|
||||
ప్రభావవంతంగా కమ్యూనికేట్ చేయండి: అన్ని పరస్పర చర్యలలో గౌరవప్రదంగా మరియు వృత్తిపరంగా ఉండండి. అవసరాల గురించి అస్పష్టంగా ఉన్నప్పుడు ప్రశ్నలు అడగండి. సమీక్షకులకు వారి సమయం మరియు అభిప్రాయానికి ధన్యవాదాలు. సమీక్ష ప్రక్రియలో ఓపికగా ఉండండి
|
||||
|
||||
స్థిరంగా ఉండండి: రెగ్యులర్ కంట్రిబ్యూషన్లు, చిన్నవి కూడా, కాలక్రమేణా పెద్ద ప్రభావాన్ని చూపుతాయి.
|
||||
|
||||
అభిప్రాయం నుండి నేర్చుకోండి: కోడ్ సమీక్షలు నేర్చుకునే అవకాశం. అభిప్రాయాన్ని స్వీకరించండి మరియు మీ నైపుణ్యాలను మెరుగుపరచండి.
|
||||
|
||||
తిరిగి ఇవ్వండి: మీరు సౌకర్యవంతంగా ఉన్న తర్వాత, PRలను సమీక్షించడం, ప్రశ్నలకు సమాధానం ఇవ్వడం లేదా కొత్తవారికి మార్గదర్శకత్వం చేయడం ద్వారా ఇతరులకు సహాయం చేయండి.
|
||||
|
||||
## సాధారణ సవాళ్లు మరియు వాటిని ఎలా అధిగమించాలి
|
||||
|
||||
* ఇంపోస్టర్ సిండ్రోమ్: చాలా మంది ప్రారంభకులు తమకు సహకరించడానికి తగినంత నైపుణ్యం లేదని భావిస్తారు. గుర్తుంచుకోండి, ప్రతి ఒక్కరూ ఎక్కడో ఒకచోట ప్రారంభించబడతారు మరియు చిన్న విరాళాలు కూడా ముఖ్యమైనవి.
|
||||
* సమయాన్ని కనుగొనడం: చిన్న, నిర్వహించదగిన పనులతో ప్రారంభించండి. వారానికి 30 నిమిషాలు కూడా తేడా రావచ్చు.
|
||||
* పెద్ద కోడ్బేస్లను నావిగేట్ చేయడం: అభ్యాస ప్రక్రియను విచ్ఛిన్నం చేయండి: - డాక్యుమెంటేషన్ను పూర్తిగా చదవడం ద్వారా ప్రారంభించండి - ఒక సమయంలో ఒక భాగాన్ని అర్థం చేసుకోవడంపై దృష్టి పెట్టండి - కోడ్ అమలును ట్రేస్ చేయడానికి డీబగ్గింగ్ సాధనాలను ఉపయోగించండి - స్పష్టత కోసం అడగడానికి వెనుకాడకండి
|
||||
|
||||
## తీర్మానం
|
||||
|
||||
ఓపెన్ సోర్స్కు సహకరించడం అనేది అపారమైన వ్యక్తిగత మరియు వృత్తిపరమైన వృద్ధిని అందించే ప్రయాణం. చిన్నగా ప్రారంభించడం ద్వారా, స్థిరంగా ఉండటం మరియు సంఘంతో సన్నిహితంగా ఉండటం ద్వారా, మీరు మీ నైపుణ్యాలను మెరుగుపరుచుకుంటూ అర్ధవంతమైన సహకారాన్ని అందించవచ్చు. గుర్తుంచుకోండి, ఓపెన్ సోర్స్ సహకారంతో అభివృద్ధి చెందుతుంది మరియు ప్రతి సహకారం-ఎంత చిన్నదైనా-మెరుగైన డిజిటల్ ప్రపంచాన్ని నిర్మించడంలో సహాయపడుతుంది. మునిగిపోవడానికి సిద్ధంగా ఉన్నారా? మిమ్మల్ని ఉత్తేజపరిచే ప్రాజెక్ట్ను కనుగొనండి, మీ మొదటి సహకారాన్ని అందించండి మరియు ఈరోజే గ్లోబల్ ఓపెన్ సోర్స్ ఉద్యమంలో చేరండి!
|
||||
|
||||
## చివరి సమాధా
|
||||
Reference in New Issue
Block a user