
Ask HN: What are good OSS projects for beginners/students to contribute to? - rcarndrums
What are some good open source projects for people with less software development experience to contribute to? Specifically junior devs or students with internship experience in software development (people who are experienced writing software but aren&#x27;t experts).
======
gus_massa
My recommendation is to contribute to the projects they use.

* Did they found a bug? Can they fix it?

* What is a pain point? Can they add a feature to solve it?

* Do they need to use the project in another platform/configuration?

* Does the project have some easy bugs/issues that they can solve?

Always start with small changes, perhaps only 1 or 2 days of work (or less,
sometimes 2 or 4 hours are enough). You are never sure that the
owner/maintainer is going to merge it. Or if they have weird requirements. Or
if they don't like the change (for good or bad reasons). Or if they have a
better option in development. If you invest less than 2 days, it's not big
deal if it isn't merged.

------
whb07
The newer or smaller projects will always take in a good pull request. Take a
look at any number of “issues” and see if they are legitimate bugs and try and
tackle those. What this means is don’t expect to submit a PR right away to
<insert hottest project we’ve all heard of>.

When submitting a PR, mention what it’s for, it’s written in the style
conventions of the project and language, and that it’s got tests!

Lastly, I realize that these types of questions that a true rookie asks
because once they realize how obvious it is and then will move on.

------
odomojuli
Their own!

I often place beginners, very beginners, and maybe some reluctant junior
developers into a room and give them some exercises. I like to include some
open discussion on side projects, OSS projects they use, the fact that GitHub
is also a social network and things like Glitch and Repl.it exist to be
shared. OSS is not just "open", it is social. Good open source software to me
begins with a discussion of what they consider to be in good taste.

1\. Set up a bunch of accounts on GitHub or GitLab, or whatever. It's better
if they have a preference for one and don't use the other - make them use the
one they're least familiar with. Get them used to using things they're not
familiar or comfortable with doing. Sound familiar?

2\. Divide the group into equal sizes if you can. If the group is prime, then
it is also abelian (bad joke). I let groups assimilate and trade with each
other. The macrocosm of tech's demographic tends to reify itself in microcosms
as well, so you'll notice some groups get larger than others but some reach
peak efficiency at specific sizes. This is good for you to know if you're in
management. It's okay to let a bunch of beginners be without anyone in their
group who has experience, sometimes they end up being the dark horse in the
race.

3\. So you have a bunch of groups, give them an exercise that has nothing to
do with whatever they're supposed to be doing. Main idea: You're trying to
show them how good practices can be interdisciplinary or better, that they
know how to think, organize, and collaborate their efforts on new things. If
it's a bunch of quants, make them use Figma or Sketch and design a layout. If
it's backend, make them do frontend. If they're UI/UX give them a bunch of
problems from [https://projecteuler.net/](https://projecteuler.net/)

4\. Now, the task for all groups is to present something by the end of the
session whether it is finished or not. A lot of the time is spent teaching
other how to set up their account, doing basic version control, picking a
language to choose, how they're going to architect the whole thing - a lot of
time is wasted trying to optimize their time. This is a good lesson and also
shows people how they lack fundamentals. Junior devs tend to try to assert
authority and have it backfire almost immediately. That's why they're junior
developers still.

5\. So some time rolls by. About the halfway mark I check in on their
repositories not their team. I want to see what work they've committed to more
than what they plan to do. It's also good for me to know how they catalog
their mistakes and what sort of basic documentation they provide themselves
out of utility rather than obligation.

6\. Time's up. Let's present. Says a lot about how a team works by who does
the presentation. You'll notice some people have become part of projects where
they know they'll shine rather than try to struggle with a team where they
know they won't succeed, even if there's nothing to risk. This says a lot
about the person's appetite for code.

7\. Now, the optional flavor for this exercise is to have them develop a
competing app in an hour. This is obviously a questionable and risky thing to
ask your team to do. My opinion is that I've hired the right team and I
believe in our culture and I already know our competition so its fine. But
let's say, we want our team to build a competing app - how would they do it?
They already know what they hate about our company or the work they do. This
exercises lets them call the shots and give themselves fake titles and lets
them dream a bit. Good, I want to foster their growth here, not extract work
out of them like some kind of time vampire. I like to have them pitch to each
other and just try on the shoes of someone who will be someday more than what
they are.

~~~
otras
Is this a workshop you ran at a company?

