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
5 Likes
We are in the middle of Announcing the BioJuliaDocs initiative! · BioJulia · Discussion #10 · GitHub, 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?
9 Likes
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 
- Join the slack
- Maybe post on a discourse mega thread for a GitHub invite?(Rust bio says to join the discord, nf-core it’s a slack channel)
On the admin side setting up the GitHub org to have proper permissions for more contributiors.
1 Like
Follow along! Pull requests · BioJulia/biojulia.github.io · GitHub
Can you say more about what you mean here?
1 Like
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.
1 Like
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
2 Likes
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.
4 Likes
Not quite. The former will be at https://biojulia.dev., and the latter at 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, and the later from GitHub - BioJulia/BioJuliaDocs.
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.
Also agree here. I think that taking too many preventative efforts for problems that are merely hypothetical is counter-productive.