Skip to main content
added 273 characters in body
Source Link
Abhi Beckert
  • 2.9k
  • 1
  • 15
  • 24

Just do it!


Don't worry about what changes you should or should not do. Pick whatever problem bothers you the most (even if it's GUI related and you have no GUI experience, and even if it's assigned to somebody else but they haven't fixed it yet) and solve it.

If the project is using Git, make sure you adhere to best practices with regards to branching and pull requests:

  • Create a clone of their repository (in GitHub this is referred to as a "fork")
  • Create a branch in your clone for each bug/feature/refactor that you work on.
  • Don't merge it into master, send a pull request from your branch to the original project developer.
  • If he/she doesn't like something, you'll be told to improve it.
  • Make those changes in your branch.
  • He/She will merge your changes into the master branch.
  • You pull their merge into your clone, and now it's part of your master.

The above process is especially important when you're working with unfamiliar code, so that any mistakes can easily be fixed.

Trust me, the project maintainer will be happy to receive any (good quality) work you send their way. Even if it's something they intended to do, they haven't done it yet so you can jump ahead.

If you're only comfortable working on documentation, then do you could do that. But if something outside your comfort zone is more important, then that's a great opportunity to learn something new and (as is your primary motivation) it will be a big step up on your CV.

Worst case scenario is you do some terrible work and the project maintainer tells you why it's terrible, so you can fix it up. You've got yourself a golden opportunity here to learn from someone more experienced.

Just do it!


Don't worry about what changes you should or should not do. Pick whatever problem bothers you the most (even if it's GUI related and you have no GUI experience, and even if it's assigned to somebody else but they haven't fixed it yet) and solve it.

If the project is using Git, make sure you adhere to best practices with regards to branching and pull requests:

  • Create a clone of their repository (in GitHub this is referred to as a "fork")
  • Create a branch in your clone for each bug/feature/refactor that you work on.
  • Don't merge it into master, send a pull request from your branch to the original project developer.
  • If he/she doesn't like something, you'll be told to improve it.
  • Make those changes in your branch.
  • He/She will merge your changes into the master branch.
  • You pull their merge into your clone, and now it's part of your master.

The above process is especially important when you're working with unfamiliar code, so that any mistakes can easily be fixed.

Trust me, the project maintainer will be happy to receive any (good quality) work you send their way. Even if it's something they intended to do, they haven't done it yet so you can jump ahead.

Just do it!


Don't worry about what changes you should or should not do. Pick whatever problem bothers you the most (even if it's GUI related and you have no GUI experience, and even if it's assigned to somebody else but they haven't fixed it yet) and solve it.

If the project is using Git, make sure you adhere to best practices with regards to branching and pull requests:

  • Create a clone of their repository (in GitHub this is referred to as a "fork")
  • Create a branch in your clone for each bug/feature/refactor that you work on.
  • Don't merge it into master, send a pull request from your branch to the original project developer.
  • If he/she doesn't like something, you'll be told to improve it.
  • Make those changes in your branch.
  • He/She will merge your changes into the master branch.
  • You pull their merge into your clone, and now it's part of your master.

The above process is especially important when you're working with unfamiliar code, so that any mistakes can easily be fixed.

Trust me, the project maintainer will be happy to receive any (good quality) work you send their way. Even if it's something they intended to do, they haven't done it yet so you can jump ahead.

If you're only comfortable working on documentation, then do you could do that. But if something outside your comfort zone is more important, then that's a great opportunity to learn something new and (as is your primary motivation) it will be a big step up on your CV.

Worst case scenario is you do some terrible work and the project maintainer tells you why it's terrible, so you can fix it up. You've got yourself a golden opportunity here to learn from someone more experienced.

Source Link
Abhi Beckert
  • 2.9k
  • 1
  • 15
  • 24

Just do it!


Don't worry about what changes you should or should not do. Pick whatever problem bothers you the most (even if it's GUI related and you have no GUI experience, and even if it's assigned to somebody else but they haven't fixed it yet) and solve it.

If the project is using Git, make sure you adhere to best practices with regards to branching and pull requests:

  • Create a clone of their repository (in GitHub this is referred to as a "fork")
  • Create a branch in your clone for each bug/feature/refactor that you work on.
  • Don't merge it into master, send a pull request from your branch to the original project developer.
  • If he/she doesn't like something, you'll be told to improve it.
  • Make those changes in your branch.
  • He/She will merge your changes into the master branch.
  • You pull their merge into your clone, and now it's part of your master.

The above process is especially important when you're working with unfamiliar code, so that any mistakes can easily be fixed.

Trust me, the project maintainer will be happy to receive any (good quality) work you send their way. Even if it's something they intended to do, they haven't done it yet so you can jump ahead.