How to get started to contribute to Julia and packages

[bvilmann]

I have coded in Julia for a little month and I am very excited about many things.

Since it is a programming language in its freshman year, improvements are to be made.
And I would like to contribute to these but I am quite new to the open-source community, Julia, and working with Github - so I actually don’t know where to start.

So, my questions are maybe a little naive and maybe not all the questions should be addressed here but let me be excused if that is the case:

1. How do you contribute to a package?

2. How do you debug code from Github in a Julia environment easily?

3. How and where do you reach out to the contributors when you want to share your idea or work?

4. Do you have any advice for being part of the Julia open-source community that would be nice to know?

All the best,
Benjamin

PS: I could find a topic on this, which is why I am posting.

[juliohm]

@bvilmann

How do you contribute to a package?

Each package has a set of contributing guidelines. Check if a CONTRIBUTING.md file is present in the repository of the package you are interested in contributing to.

@bvilmann

How do you debug code from Github in a Julia environment easily?

Watch this video: https://youtu.be/IdhnP00Y1Ks

@bvilmann

How and where do you reach out to the contributors when you want to share your idea or work?

Projects have issue trackers. For example, you can open issues on repositories hosted on GitHub.

@bvilmann

Do you have any advice for being part of the Julia open-source community that would be nice to know?

• Be ready to interact with competent professionals from various scientific domains.
• Try to think out of the box as opposed to enforcing a view of the world inherited from other programming languages and communities.
• Many users coming from other popular languages get frustrated when they don’t know how to do something in Julia. Be patient and assume that a very elegant and well-thought alternative solution already exists. You will experience many “A-HA” moments in this journey.
• Contribute to packages from your domain of expertise, and only then start writing your own. The Julia community tends to solve problems very systematically, and this leads to major and carefully thought projects that compose well with various ecosystems as opposed to tiny isolated projects. In other words, do your research before you write a third version of an existing package. Use your time wisely, and do not reinvent the wheel as many newcomers do.

[kevbonham]

I cosign all of @juliohm’s post. Reaching out to people here or on slack/zulip (if they’re on these forums) can be a slightly lower threshold way to gauge interest.

And I also want to add that it’s ok to start small. Go through all the documentation of a package looking for typos or things that are unclear. Look for good first issue tags in the issues tracker.

If you don’t have any experience with git, it might be worth watching some tutorials, but many people in the community will be willing to help. You can also read this post by @hyatt Making a first Julia pull request | Katharine Hyatt. It’s about making a PR to julia itself, but all of the same principles apply when contributing to a package.

[Oscar_Smith]

I should also add that as someone new to Julia, you have a massive advantage. You’re probably using the docs to figure out how to do things. This means that whenever you have an “Oh, those docs suck!” moment, you’ve found a great first (or 50th) PR.

[bvilmann]

Thank you for all your great answers! They all really helped and the links are great!

@juliohm

Try to think out of the box as opposed to enforcing a view of the world inherited from other programming languages and communities.

Duly noted! I am very surprised how many “I just want my py-syntax!” packages there are. I really find Julia elegant - like you also mention! But I will try to refrain from thinking pythonic when I hit a wall.

@kevbonham

Reaching out to people here or on slack/zulip (if they’re on these forums) can be a slightly lower threshold way to gauge interest.

That was also my immediate impression, so thanks for pointing it out.

@kevbonham

You can also read this post by @hyatt https://kshyatt.github.io/post/firstjuliapr/ . It’s about making a PR to julia itself, but all of the same principles apply when contributing to a package.

That was a really helpful link for rookies like me. It links really nice to the fundamental concepts of git. Thanks!

@Oscar_Smith

This means that whenever you have an “Oh, those docs suck!” moment, you’ve found a great first (or 50th) PR.

I am glad you are saying that! However, I think trying to contribute to a package is the subtle distinction between constructive criticism and saying “hey, your voluntary work suck!”. Or is this impression wrong from the contributer’s perspective so that every hint is “nice to know” (of course delivered with manners)?

[kevbonham]

@bvilmann

But I will try to refrain from thinking pythonic when I hit a wall

I think it’s ok to think in python first if that’s what you’re used to, many python idioms work just fine in julia. I could be wrong, but I think the point was more that if someone explains a more Julian approach, you should try to take it rather than sticking to your old way - sounds like that won’t be a problem for you

@bvilmann

the subtle distinction between constructive criticism and saying “hey, your voluntary work suck!”. Or is this impression wrong from the contributer’s perspective so that every hint is “nice to know” (of course delivered with manners)?

Everyone knows their docs could use work, but it’s also low on everyone’s priority list. In this sense, pointing out that you found something wrong or confusing in the docs, especially if it’s accompanied by a willingness to put in the work to fix them, is almost always going to be welcomed with gratitude.

[oxinabox]

@juliohm

Each package has a set of contributing guidelines. Check if a CONTRIBUTING.md file is present in the repository of the package you are interested in contributing to.

Some packages rather than, or in addition to, the CONTRIBUTING.md display a badge in the readme.
ColPrac is kind of like a common standard contributors guide that many packages follow.
Defining a kind of collection of norms and expectations and guidance around things.
Its probably worth a read, as in general the kind of (implict or explict) guidelines most packages follow is omething approximately like that, like PRs need review etc.
(Though if a package doesn’t say it follows colprac you can’t be sure everything applies exactly)

---

Some general advice:

• Be Bold: one of the easiest ways to learn is to do what you think is right, and if it is wrong someone will correct you. Its leveraging Cunninham’s Law.
• This is a good blog post about making good PRs (ignore the weird title and intro.)
• If a PR is waiting for review for more than 10 days, it is reasonable to “bump” it, by posting something like “Anything blocking this from review?”. When you are maintaining a lot of packages it is easy to loose track of something, so rather than bumping it being rude, it is actually helpful.