# How to get involved in BioJulia

**URL:** <https://discourse.julialang.org/t/how-to-get-involved-in-biojulia/102215>\
**Category:** Biology, Health, and Medicine\
**Created:** [July 28, 2023, 9:10pm UTC](https://discourse.julialang.org/t/how-to-get-involved-in-biojulia/102215 "2023-07-28T21:10:52Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Emiller](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/emiller/32/33727_2.png) [@Emiller](https://discourse.julialang.org/u/Emiller)\
**Post date:** [July 28, 2023, 9:10pm UTC](https://discourse.julialang.org/t/how-to-get-involved-in-biojulia/102215/1 "2023-07-28T21:10:52Z")

</div>

Hoping we could create a similar page for at least BioJulia. I’m happy to take on the leg work to make a PR to the site, but I don’t know what the process 😬

I’m hoping to mimic: [Join nf-core](https://nf-co.re/join)

---

<div class="post-metadata">

**Author:** ![kevbonham](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kevbonham/32/216165_2.png) [@kevbonham](https://discourse.julialang.org/u/kevbonham)\
**Post date:** [July 29, 2023, 2:10am UTC](https://discourse.julialang.org/t/how-to-get-involved-in-biojulia/102215/2 "2023-07-29T02:10:37Z")

</div>

We are in the middle of [Announcing the BioJuliaDocs initiative! · BioJulia · Discussion #10 · GitHub](https://github.com/orgs/BioJulia/discussions/10), which I think / hope will make that a bit easier. For the hackathon tomorrow, I’m gonna try to rebuild the main Julia page in Franklin, and @M-PERSIC is working on unifying the BioJulia docs.

I think a “how to get involved” would ultimately be prominently linked to, but not 100% sure where makes the most sense in this moment - maybe just start working on a markdown file and we’ll figure out where to put it?

---

<div class="post-metadata">

**Author:** ![Emiller](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/emiller/32/33727_2.png) [@Emiller](https://discourse.julialang.org/u/Emiller)\
**Post date:** [July 29, 2023, 3:01am UTC](https://discourse.julialang.org/t/how-to-get-involved-in-biojulia/102215/3 "2023-07-29T03:01:21Z")

</div>

a Franklin rewrite sounds awesome. Completely agree just get the content out there in a markdown file and it can find a home.

I’m still just missing the action steps for people to take 😅

1. Join the slack
2. Maybe post on a discourse mega thread for a GitHub invite?([Rust bio says to join the discord](https://github.com/rust-bio/rust-bio#contribute), nf-core it’s a slack channel)

On the admin side setting up the GitHub org to have proper permissions for more contributiors.

---

<div class="post-metadata">

**Author:** ![kevbonham](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kevbonham/32/216165_2.png) [@kevbonham](https://discourse.julialang.org/u/kevbonham)\
**Post date:** [July 29, 2023, 8:23pm UTC](https://discourse.julialang.org/t/how-to-get-involved-in-biojulia/102215/4 "2023-07-29T20:23:51Z")

</div>

> [@Emiller](#):
>
> Franklin rewrite sounds awesome

Follow along! [Pull requests · BioJulia/biojulia.github.io · GitHub](https://github.com/BioJulia/biojulia.github.io/pulls)

> [@Emiller](#):
>
> On the admin side setting up the GitHub org to have proper permissions for more contributiors.

Can you say more about what you mean here?

---

<div class="post-metadata">

**Author:** ![Emiller](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/emiller/32/33727_2.png) [@Emiller](https://discourse.julialang.org/u/Emiller)\
**Post date:** [July 30, 2023, 1:33am UTC](https://discourse.julialang.org/t/how-to-get-involved-in-biojulia/102215/5 "2023-07-30T01:33:13Z")

</div>

Looks great I’ll give it a review!

> Can you say more about what you mean here?

I can get the exact permissions from nf-core but we have a “core”, maintainers, and general members.

In general:

The core group has the keys to the kingdom.

Maintainers have the rights to merge PRs.

General members can create branches and add issue tags etc.

We also have pipeline maintainers who have nearly full access to their individual repos.

I think a similar model would work well here.

---

<div class="post-metadata">

**Author:** ![kevbonham](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kevbonham/32/216165_2.png) [@kevbonham](https://discourse.julialang.org/u/kevbonham)\
**Post date:** [July 30, 2023, 10:34am UTC](https://discourse.julialang.org/t/how-to-get-involved-in-biojulia/102215/6 "2023-07-30T10:34:57Z")

</div>

> [@Emiller](#):
>
> Maintainers have the rights to merge PRs.
> 
> General members can create branches and add issue tags etc.

Interesting - I think we don’t have either of these tiers. Me and @jakobnissen have full permissions everywhere (also Sabrina and Kento, but they’re inactive), and we have people who have admin rights to individual repos, but nothing really in between.

I’d be in favor of this model

---

<div class="post-metadata">

**Author:** ![jakobnissen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jakobnissen/32/13477_2.png) [@jakobnissen](https://discourse.julialang.org/u/jakobnissen)\
**Post date:** [July 30, 2023, 4:23pm UTC](https://discourse.julialang.org/t/how-to-get-involved-in-biojulia/102215/7 "2023-07-30T16:23:20Z")

</div>

Re: How to get involved:

This sounds like a great idea. It could be on the BioJulia website, or on the upcoming org-wide docs (are these two the same website?). I think it would be nice if the text was relatively brief and basically said that people should feel free to open PRs and issues, and that we are open to help with PRs and discuss design, and where to find us.

I think it’s a good idea to have as little process associated with contributing as possible and make it clear that you don’t need to be someone special or have an ingenious package idea to start contributing. At least I remember when I wanted to do my first BioJulia and Julia PRs I found it slightly intimidating because I wanted to do it the right way, but didn’t know the process or the right channels to work through. Now I know that there aren’t really any channels or social process involved, you just show up and do the work and then people like you. There is _some_ process, but it’s technical, not social, such as following Julian coding best practices, and using git and CI correctly. These are hard, but there is no point to mentioning them on the website. We can just make it clear on the website that we are willing to help with any PR and answer questions to the extent we have time. Then we can guide any newbies when they actually make a PR.

Re: Who to give access

I think it’s a good idea to have a small group of vetted people who are admins with broad access to everything, like Kevin and I currently have. These admins are the only real dangerous ones in that only we have the ability to mess BioJulia up really badly. Outside of admin powers, I’m in favor of being very generous with giving out commit and merge rights to people. It’s not really a big deal if someone deletes all the code in a repo - we can easily restore it, that’s kind of the point of version control. And I just don’t see it being realistic that people would sneak malware into obscure Julia bioinfo packages. And the upside is pretty clear: If we remove barriers to contributing, contributors might find themselves with a sense of ownership and may find greater joy in working for BioJulia.

The most realistic potential problem would be if someone is overeager to contribute, and merges a bunch of code that is poorly designed or tested, without asking for code reviews or listening to our comments, such that it causes problems for the package down the road. If that happens, I think we just need to take the awkward confrontation and tell them that while we appreciate their work, they merge code too carelessly and temporarily take away their commit rights. This might cause some drama, but it’s not a big deal. And I specifically think it’s a very bad idea to try to design bureaucratic process to prevent social drama.

---

<div class="post-metadata">

**Author:** ![kevbonham](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kevbonham/32/216165_2.png) [@kevbonham](https://discourse.julialang.org/u/kevbonham)\
**Post date:** [July 31, 2023, 2:54pm UTC](https://discourse.julialang.org/t/how-to-get-involved-in-biojulia/102215/8 "2023-07-31T14:54:07Z")

</div>

> [@jakobnissen](#):
>
> This sounds like a great idea. It could be on the BioJulia website, or on the upcoming org-wide docs (are these two the same website?)

Not _quite_. The former will be at [https://biojulia.dev](https://biojulia.dev)., and the latter at [https://biojulia.dev/BioJuliaDocs](https://biojulia.dev/BioJuliaDocs) (I think ultimately we should change that to `docs.biojulia.dev`), but they are not connected unless explicitly linked (which we should). The former is built from [GitHub - BioJulia/biojulia.github.io: BioJulia's Website](http://github.com/BioJulia/biojulia.github.io), and the later from [GitHub - BioJulia/BioJuliaDocs](http://github.com/BioJulia/BioJuliaDocs).

> [@jakobnissen](#):
>
> Outside of admin powers, I’m in favor of being very generous with giving out commit and merge rights to people. It’s not really a big deal if someone deletes all the code in a repo - we can easily restore it, that’s kind of the point of version control. And I just don’t see it being realistic that people would sneak malware into obscure Julia bioinfo packages. And the upside is pretty clear: If we remove barriers to contributing, contributors might find themselves with a sense of ownership and may find greater joy in working for BioJulia.

100% agree with this, though @Emiller if you can point me to someone in nf-core that can help me out that would be great. I tried playing around with github teams and they seem pretty terrible. I have to maybe add people one-by-one? Seems like there has to be a better way.

> [@jakobnissen](#):
>
> I think we just need to take the awkward confrontation and tell them that while we appreciate their work, they merge code too carelessly and temporarily take away their commit rights. This might cause some drama, but it’s not a big deal. And I specifically think it’s a very bad idea to try to design bureaucratic process to prevent social drama.

Also agree here. I think that taking too many preventative efforts for problems that are merely hypothetical is counter-productive.