How to structure open science collaborations online
Practicalities for optimizing Discord-based science-in-the-open research
“Science-in-the-open” [1] has the potential to redefine the traditional scientific framework and greatly accelerate high-impact research. It usually involves a large team of volunteer researchers asynchronously working together in a public Discord server. This approach allows one to harness crowd-sourced intelligence to tackle ambitious problems collaboratively and attract specialized expertise and creative approaches you might not find in a traditional lab.
Unfortunately, in practice, the benefits are often outweighed by management challenges. With an open invite, you’ll likely have a heterogeneous group of contributors: different backgrounds, skill levels, time zones, and commitment levels. Coordinating a larger, decentralized team is hard. There’s a risk of wasting time onboarding people who later disappear, or trying to mentor enthusiastic novices at the expense of research progress. Newcomers may find it impossible to figure out the project status or how to contribute amidst the chatter. Progress can stall as volunteers are under no obligation to stay or finish tasks.
Below, I outline strategies that have worked in my experience to optimally steer open science collaborations. Our MindEye papers [2, 3] implemented these strategies for successful publication in NeurIPS and ICML, and we are now introducing the below structure into all projects conducted in our MedARC Discord server. Relatedly, today we are re-launching MedARC with three public research projects (fMRI foundation model, pathology foundation model, real-time MindEye). If you are interested in collaborating with us on medical AI research, please join our Discord!
Summary
In my opinion, the following strategies promote the best open science collaborations:
Flat and simple codebase so contributors can easily acquaint themselves with the codebase.
Strong, reliable project lead who provides consistent, immediate progress updates and handles task delegation.
Communicate frequently and transparently. Use a central hub like Discord for real-time updates and hold regular group video calls to summarize progress and delegate tasks.
Simple 3-platform organization: Discord as the core hub for all communication, GitHub for sharing code (using forks and small, minimally changed pull requests), and Notion for summarizing everyone’s updates before the next video call.
Self-onboarding: interested new contributors should spectate the next group video call and be assigned a low priority “gatekeeping” task (e.g., fork the repo and reproduce a certain analysis) as a low-effort means to weed out unserious volunteers. 1-on-1 conversations with volunteers should be avoided unless they’ve already demonstrated they are a serious, reliable contributor.
Provide a free, shared computing workspace so everyone has access to the same resources and file system.
Keep the project focused by working towards doing the minimal steps necessary to reach a tangible deliverable (i.e., research paper).
Devise a fair and low-barrier system for authorship and credit to reward volunteers, while ensuring that author contributions are transparent.
Bad actors stealing your ideas/code is not a huge concern in practice, and there are various ways to mitigate this risk.
I’ll dive into each of these points below, then conclude with some optimistic thoughts on MedARC’s future ideals to support open science collaborations.
Keep the Codebase Simple and Flat
For open collaborations, it’s important to maintain an interpretable and lightweight codebase. Your repository should be as welcoming as possible to a newcomer who might be browsing it to understand the project. A flat code structure [4] with minimal dependencies seems to work best.
Limit complexity: Minimize the number of folders, files, and external dependencies. Ideally, everything needed to run the project fits in a single directory tree without deep nesting. This makes it easier to navigate and grasp the pipeline.
Include only what’s used: Do not accumulate dead code or experimental scripts in the main repository. Such code should be in branches outside main.
Fewer abstractions: Aim for straightforward code that a person can read and follow without digging through many layers of indirection. It’s fine if some code is duplicated a bit for clarity, see Hugging Face’s “Repeat Yourself” philosophy [5] and Dan Abramov's talk on the "WET" codebase [6].
Core libraries only: Rely on well-known, widely used libraries (for example, in Python stick to NumPy, PyTorch, etc.) and try to avoid niche packages or complex framework setups. Fewer moving parts means fewer things to install or break for a newcomer setting up the environment.
Keep it short: Fewer total lines of code is better. There’s less surface area for bugs and less for someone new to wrap their head around.
To implement these ideas, we are adopting a policy that the main branch of the repository always reflects the current best working implementation. Use branches or forks for experimental ideas and side explorations. If an experiment proves successful or outperforms the current method, you can merge those changes into the main branch (after proper review), ideally replacing older code. Collaborators should not be able to push directly to main—they should fork the branch and open PRs and the project lead should approve pushes to main. By doing this, the master branch remains the up-to-date reference that any new contributor can pull and run without confusion. It also prevents the codebase from bloating with multiple alternative versions of algorithms; the master branch is always the one that works best, and it contains only the necessities for that approach.
Make sure to provide a clear README at the root of the repository that explains the project’s purpose, how to get started, and the high-level directory structure. The README is effectively your first onboarding document for new contributors. It should outline the research goal, briefly summarize the method, and list any setup steps (environment, data downloads, etc.) needed to reproduce results. With a well-written README and a tidy codebase, you drastically lower the barrier for a motivated volunteer to start contributing without needing hand-holding.
For specific information on this coding approach, see our MedARC Coding standards / philosophy Notion page.
Define Clear Goals and Deliverables
One common failure mode in open-ended research collaborations is meandering without ever producing a coherent result. To avoid this, define upfront what your intended deliverable for the project looks like – usually, this is a paper addressing a single research question. As project lead, keep the team oriented on the most direct path to that goal. In practice, this means identifying the minimal set of experiments or features needed to support your hypothesis and working towards that, rather than endlessly adding new features or branching into tangents.
It’s fine (and often necessary) to explore different ideas, and this is especially useful with a larger group where people may take various approaches to see what works. But always be evaluating those explorations against the question: “Does this help us make a publishable finding or a compelling story for our paper?” If not, be ready to cut it or put it on the back burner. Part of the project lead’s role is to recognize which avenues aren’t paying off or aren’t essential to the core contribution, and curtail them so that energy is redirected to the main goal.
I recommend aiming to reach a viable end-to-end result quickly, even if it’s not state-of-the-art at first, and then iteratively refining it. For example, get a basic model working and confirm your idea works in principle, then improve its performance or add refinements as needed.
Once you do achieve the key results for your paper, write it up sooner rather than later (more on writing below). Completing a written draft consolidates the project’s narrative. If there are additional experiments or improvements you’d like to pursue, you can often note them as future work or, better yet, spin them off as a new project after wrapping up the current one. Keeping the scope tight for each project increases the likelihood of reaching the finish line with a publishable outcome.
In summary, decide what the minimum successful outcome is, focus the team on reaching that outcome, and be disciplined about excluding or postponing tasks that don’t serve the main story. Volunteers will appreciate a clear target to work towards, and it prevents the project from feeling like a moving target that never solidifies.
Establish Strong Project Leadership
Every open science project needs a project lead who acts as the navigator. In a volunteer-driven setting, having a clear leader is even more critical than in traditional labs. If nobody takes on this role (or if leadership is too diffuse), the project can stall due to lack of direction or devolve into disagreements.
The project lead should be someone deeply invested in the project’s success and able to commit through the entire lifecycle. Ideally, this is a person who would be doing this project regardless; for example, a PhD student for whom the project is their thesis topic, or a full-time researcher/employee whose job includes this project. If the lead is a volunteer doing it on the side, carefully consider their incentives to stick around. Are they just free for the summer, or are they intrinsically motivated long-term? If they might leave after a short period, you either need a contingency plan for who takes over, or it may not be a good fit.
The project lead should also ideally be the top contributor (aka, first author) to the research work. They don’t just manage; they actively do a large share of the core tasks (experiment design, coding, analysis). This accomplishes two things: (1) It sets the pace and standard for the rest of the team. When members see the lead frequently posting progress updates, it signals that the project is moving and inspires others to contribute as well. (2) It avoids ambiguity or conflict about contribution levels. If the lead barely contributes and mostly manages, you might end up with a scenario where someone else feels they did more and there’s confusion about who deserves credit. (By the way, it’s great if a volunteer ends up contributing so much that they merit co-first-authorship!)
A good lead communicates research updates frequently and transparently. Whenever the lead obtains a new result, figure, or insight, they should share it in the Discord channel as soon as possible (rather than keeping results private until the next group call). This real-time transparency keeps the team in the loop and maintains momentum. It also creates an atmosphere where sharing progress (and even intermediate failures) is the norm for everyone. Regular updates from the lead help avoid the perception of stagnation. If the lead goes quiet, others might assume the project has stalled or lose motivation, whereas consistent activity from the lead can energize the whole group.
Communicate Frequently and Transparently
Effective communication is the lifeblood of an open science project. This includes both asynchronous communication (Discord chat) and synchronous meetings (video calls).
Asynchronous updates (Discord): All team members should be encouraged to post updates in the Discord channel as soon as they have something noteworthy. This might be a new experiment result, a figure, a question about the data, or even an obstacle they ran into. Sharing updates in real time serves several purposes: it creates a log of progress, keeps everyone aware of what others are doing, and invites timely feedback. For example, if a contributor is exploring an approach that another team member suspects won’t pan out (perhaps due to prior experience), catching that early via a quick Discord discussion can save days of wasted effort. An active Discord channel with frequent research chatter also signals to potential new contributors that the project is alive and making progress.
Regular video meetings: In addition to the fluidity of chat, schedule a recurring video call (weekly, or biweekly at most) for the whole team. These meetings sustain a productive research cadence where everyone aims to have something to show or discuss. Video calls humanize the collaboration but perhaps more importantly, the meeting is where the project lead can synthesize all the threads of work: each person can briefly report what they did since the last meeting, show any results, and voice blockers or plans. The lead should moderate to ensure everyone gets a turn and the discussion stays on track.
During the call, it’s useful for someone (often the lead or the supervisor) to keep notes of the key points—what was decided, who is assigned to which task, any deadlines or experimental directions agreed upon. We use Notion to log weekly meetings, but a Google Doc or PowerPoint could also work. Some teams record the calls and share the videos, which is nice for full transparency; in practice, however, not everyone will watch an hour-long recording, so written summaries are more immediately useful for catching up and remembering past discussions.
Combining async and sync: The asynchronous Discord chat and the synchronized video meetings complement each other. Continuous Discord updates ensure information is flowing at all times and nothing waits just for a meeting. Meanwhile, the periodic meeting helps organize and compress that information into a coherent update, which is easier to digest if someone wasn’t following every Discord message. It also provides a forum for more complex discussions or brainstorming that is easier in real-time than over text. In our experience, this dual approach (active chat + weekly calls) strikes a good balance. If time zones are an issue, you can consider rotating meeting times or having two meetings (for different regions).
Transparency: Wherever possible, keep communications public within the project. Avoid side conversations in DMs or private sub-channels about project work, unless there’s a specific reason (like discussing a sensitive matter).
Use Minimal Platforms/Tools For Organization
One of the advantages of running a project on Discord is that you can integrate various tools, but it’s important not to overload the team with too many platforms. Keep the tool stack minimal and focused. Here’s our setup:
Discord for collaboration: Use Discord as the central hub for all communication. Too many channels can fragment the discussion, usually a single channel per project is sufficient.
GitHub for code and issues: All code should live in a shared GitHub repository. This allows contributors to fork the repo, make changes, and submit pull requests. The project lead or maintainers can review and merge these. Use GitHub issues in a lightweight way, e.g., to keep track of delegable tasks or bugs.
Notion for summaries & note-taking: As mentioned, a simple shared document can be used to store meeting summaries, project roadmaps, and any additional documentation that doesn’t fit neatly in GitHub or which can get lost across Discord messages. We use Notion to archive weekly meeting notes and generate AI summaries for quick reading. The Project Lead can screen share the Notion page for that week’s summaries and walk everyone through it.
Video conferencing (Zoom/Meet): Choose a video platform accessible to everyone, and share a Google Calendar with your meeting times to all contributors. Ideally you have a consistent schedule so everyone easily knows when the next meeting takes place.
Overall, I think a common pitfall is to set up an overly complex system – for example, a multi-tier Kanban board, dozens of labeled issue trackers, Slack and Discord, etc. This can intimidate newcomers and burden everyone with bureaucratic overhead. Instead, lean into the simplest tools that can get the job done. In our case, Discord is the central communication hub, GitHub is for code, and Notion is for weekly update summaries/group video calls.
Use a Shared Compute Workspace
Many research projects require significant compute or data storage. In a professional lab, this is taken for granted (everyone has access to the lab’s servers), but in an open project your volunteers might have very uneven access to computing resources. If possible, arrange a shared computing environment for the project. This could be a cloud VM or an HPC cluster where you can create accounts for team members. Having a shared environment yields huge advantages:
Everyone can work with the same data and software environment, reducing compatibility issues. A common file system means results and datasets can be accessed by all.
Contributors who don’t have a powerful GPU or large memory on their own can still run experiments and contribute meaningfully by using the shared resources.
When someone new joins, giving them access to the shared compute can immediately empower them to reproduce results or test changes without lengthy setup.
We learned the importance of this the hard way. In the MindEye project’s early phases, an external sponsor (Stability AI) provided generous cloud compute for the volunteers, which led to incredible research progress. After that support was paused, everyone was forced back to their personal machines and collaboration slowed dramatically. Now, with our MedARC projects, Sophont supports a shared compute workspace for the team.
Delegate Tasks Carefully
When working with volunteers, task delegation is a delicate art. You want to maximize the contributions from the crowd, but you also need to hedge against the unreliability and wasted onboarding time inherent in volunteer work. Here are some tactics I recommend:
Assign by priority and reliability: Not all tasks are equal. Identify which tasks are high-priority or on the critical path for the project’s goals. These tasks should be handled by the most dependable contributors (often the project lead themselves will take on many of these). Lower-priority or “nice-to-have” tasks can be given to newer or less proven members. This way, if a new volunteer flakes on a low priority item, the project doesn’t derail – it might just be a minor delay or something that can be done later by someone else.
Don’t fear duplicate work: It may sound counterintuitive, but it’s okay to have multiple people work on the same task in parallel, especially if it’s important. For example, if you need a certain analysis done, two volunteers might approach it; the one who finishes first or produces the better result can have their work merged, and the other’s efforts aren’t entirely wasted either – at worst they learned something or their approach might reveal insights or alternative methods. Redundancy provides a safety net: if one person disappears, the task isn’t abandoned; and a bit of friendly competition can motivate folks to be timely.
Set clear expectations, then step back: When delegating, clearly explain what outcome you need, but avoid the temptation to micromanage how the person does it. You should not be mentoring people through every step. Provide any necessary data, point them to relevant parts of the codebase, and perhaps outline a general approach. But let them figure out the rest. If they have questions, they can ask in the Discord (so others can help or learn from the Q&A as well). This approach filters for contributors who are proactive and capable of independent work. It also frees the project lead from becoming a full-time teacher or tech support.
Use a gatekeeping task for newcomers: When a brand-new person wants to contribute, give them a small, self-contained task as a trial. Something easy to do that involves the current codebase and which can be finished fairly quickly. This serves two purposes: it helps them get familiar with the project on a small scale, and it’s a quick way to gauge their ability and reliability. Do not waste your time sharing compute with someone who has not demonstrated that they are at least able to stay up-to-date with meetings and can do a simple gatekeeping task.
At the same time, it’s good to encourage an environment where it’s okay for someone to say “I don’t have time to finish X this week” so that tasks can be reassigned. Volunteers are essentially providing free labor and so the project lead should be grateful for any volunteer contributions and be accepting of volunteers’ personal workload constraints.
Onboard New Contributors Efficiently
A major challenge in open projects is handling the flow of new people who express interest. You want to welcome them (more hands can help), but you also can’t afford to spend hours onboarding each curious passerby who might not actually contribute in the end.
Use group meetings as an entry point: Rather than scheduling lengthy one-on-one orientations for every newcomer, invite interested folks to sit in and silently spectate on the next team video call. This allows them to observe the project’s working style, hear the updates, and get context – all at once, along with everyone else. It’s an efficient way for someone new to sense if they are truly interested and able to commit. At the end of the call, you can spare a few minutes to greet them, answer a couple of quick questions, and gauge what aspects of the project align with their skills.
Self-orientation: Ideally, a newcomer should be able to get up to speed independently by exploring the resources you’ve already made public. This includes the GitHub README (for the project overview and setup), the Discord channel history (for recent discussions and progress), and any logged meeting notes or project documentation. Encourage them to read through these on their own time. Many basic questions (e.g. “What is the current goal?” or “Where is the data stored?”) are likely answered there. If a newcomer isn’t willing to invest some time to read the available materials, that’s a soft signal they might not be committed enough.
Minimal direct hand-holding: Resist the urge to give full private tutorials. If a new person asks for a separate call to “learn the codebase” or “get a detailed briefing,” say no until after they’ve proven they have made an effort to understand things themselves.
Encourage questions in public: When new contributors do have questions, encourage them to ask in the public Discord channel rather than in private messages. Other newcomers might have the same question, and even existing team members could learn from the answers. It also shares the support load – maybe someone else on the team can answer, not always the lead.
Integrate gradually: Once a newcomer has attended a meeting and succeeded in the gatekeeping task, you can integrate them into the regular workflow. Add them to the schedule for giving updates in meetings. Make sure they have access to the GitHub and any compute resources needed. Pair them with another member for a task if appropriate. Basically, treat them as part of the team, and see if they engage. If they contribute code, review it promptly and give feedback or merge it, to positively reinforce their effort.
Establish Fair System for Authorship and Incentives
In traditional academia, authorship often corresponds to formal roles but in an open project you need a clear and inclusive policy to keep things fair and motivating.
Low barrier to co-authorship: In general, if someone actively contributes to the project in any meaningful way, I advocate including them as an author on the publication. Writing code that in any way benefits the project (even if it’s exploring a research direction that doesn’t end up in the final paper) should warrant co-authorship. There’s usually little harm in having a longer author list, and a lot of upside in goodwill and recognition for volunteers. By keeping the bar low, you encourage participation: people know that even a modest contribution could earn them credit in a published paper, which is a tangible reward (especially for students or those trying to break into research).
Author order and contribution statements: Of course, not everyone contributes equally. We handle this by ordering authors roughly by contribution level and by providing a detailed author contributions section in the paper. Typically, the project lead is first author, followed by core contributors, followed by those with more minor roles, and ending with the last-author who acted as supervisor. We once used asterisks to mark core authors on a project, signifying a subset who did the heavy lifting, which is another way to acknowledge differences without excluding people. In the paper’s author contributions or acknowledgments, you can spell out exactly who did what (see our MindEye papers for examples). This transparency ensures that adding an extra name doesn’t “take away” credit from others.
Dealing with inactive contributors: Sometimes a person may do some work early on but then disengage. Should they remain an author? My view: if their work was beneficial to the research product, then yes, they should be credited (their limited involvement can be noted in the “author contributions” section). On the other hand, if someone contributed no tangible code and only attended a handful of meetings, then it’s acceptable to omit them. Make this a known policy so that people understand that hanging around in the chat without doing anything won’t earn authorship; contributing does.
Avoid honorary or unjustified authors: Do not add someone as an author if they truly didn’t contribute to the research. In academia, there can be pressure to include a supervising professor or a senior figure who wasn’t actually involved. In open science projects, you might encounter a volunteer whose PI let them participate and now the volunteer feels the PI should be listed. Unless that PI actually came to meetings or provided specific guidance, they do not belong on the author list. Most professors will not expect to be authors on a paper they had no hand in, and it looks good for the professor to have their student earn a publication.
Volunteer incentives beyond authorship: Authorship is a key incentive, but it’s not the only one. Volunteers often join because they want to learn and gain experience. Make sure the environment supports that, e.g., they get to see how a project is run, they can try tasks slightly beyond their comfort zone, and they can interact with more experienced researchers. Many will value a recommendation letter or endorsement from the project lead or other researchers on the team if they contributed well. In our case, we also consider top contributors for paid positions at Sophont. If someone consistently impresses us in a volunteer project, that’s exactly the kind of person we’d love to hire. Even if hiring isn’t on the table, sometimes volunteers can use the project as part of their portfolio or even get academic credit (maybe as an independent study) with their local institutions. It’s good to be aware of these motivations and support them to create a win-win situation where contributors get something concrete out of the experience in return for their hard work.
Mitigate Risks like Scooping and Bad Actors
There is a potential risk in doing science in the open. Couldn’t someone just copy code from your public GitHub repo, make some revisions to it, and share it as their own independent work and publish before you? In general, I think this possibility is unlikely… Similar to how a preprint effectively prevents you from getting scooped because you have documented evidence of your research paper coming out before others, using a GitHub repository tracks the history of your work and can be used as evidence against someone who unfairly takes advantage of your labor. That said, I do understand the concern, and we are implementing a few barriers to prevent bad actors from malicious actions.
Private-until-requested: We plan to have a few of our codebases be private until requested, but everyone who requests access to our GitHub will be granted viewing permission. This allows us to at least vaguely track who has been looking at our codebase. After we release a deliverable (i.e., preprint), the codebase is made public.
Automated CLA: We automate all contributors signing a Contributor License Agreement (CLA). You can automate this easily with cla-bot in GitHub. This way every pull request prompts the user to sign the CLA if they haven’t already. Not using a CLA can potentially lead to problems where volunteers are contributing to a codebase but not aware of/in agreement of the LICENSE file for the repo or the intentions for the code to be public.
Legal contracts for shared compute: We require all volunteers whom we share free compute with to sign a Compute Resource Agreement. This protects us from bad actors doing things like using compute for their own non-MedARC projects, stealing code, scooping our research, etc.
Another potentially good idea that we’ve previously played around with is to make the public codebase temporarily private for the last month or two of work prior to preprint release. This makes it less likely someone can immediately clone the repo and claim it as their own without even needing to make any major revisions, and it also makes sense because you likely don’t want to be adding any more volunteers to the project that late into development anyway.
Streamline the Writing and Publication Process
I recommend waiting until the research is mostly complete before doing formal paper writing. If you start writing too early, you may waste time drafting sections that you later have to change because the project’s direction shifts. One exception is the background and related work section: it’s often useful to do a literature review at the project’s start to understand the current literature surrounding your research project. I’d encourage some sort of informal background section which can be a useful resource to look back upon and to share with newcomers to the project.
A good strategy is to have each contributor write about their own contributions. The project lead can stitch together all the written contributions into a coherent first draft. This involves a lot of editing for consistency in tone, avoiding redundancy, and ensuring the narrative flows logically. The lead can fill those in or ask for help in those areas. After a full draft exists, circulate it to all authors for feedback and revisions.
Finally, right before submission, I’d encourage everyone to get on a video call for a final read-through of the paper to catch any last-minute problems. Then, finally submit it to arxiv (or whatever venue you intended) altogether, and have a celebratory moment with the team.
Future Directions for Open Science Collaboration
We’ve seen that our approach and similar initiatives (e.g. EleutherAI, LAION, MLCollective) have started to redefine the traditional framework of scientific research by democratizing who can contribute and accelerating innovation through community effort. The hope with MedARC is to implement more structure into the typically very informal process of open science collaborations in order to achieve a higher success rate for all projects rather than seeing them fizzle out due to chaos or neglect.
I’m also curious about a possible bigger vision for MedARC in the future. Perhaps we can expand into an established non-profit and help to organize dozens of open science projects in the community. One interesting direction would be to formally collaborate with providers trying to fund open science projects but who lack the time and expertise to fully support them. Maybe we can partner with such organizations where we introduce better structure to ensure science collaborations are progressed in a timely manner. If you are interested in such ideas or future directions, please get in touch with me at paul [at] sophontai.com.
References
[1] Phang, J., Bradley, H., Gao, L., Castricato, L., & Biderman, S. (2022). EleutherAI: Going beyond “open science” to “science in the open”. arXiv preprint arXiv:2210.06413. https://arxiv.org/abs/2210.06413
[2] Scotti, P. S., Banerjee, A., Goode, J., Shabalin, S., Nguyen, A., Cohen, E., Dempster, A. J., Verlinde, N., Yundler, E., Weisberg, D., Norman, K. A., & Abraham, T. M. (2023). Reconstructing the mind’s eye: fMRI-to-image with contrastive learning and diffusion priors. Advances in Neural Information Processing Systems, 36. https://proceedings.neurips.cc/paper_files/paper/2023/hash/4ddab70bf41ffe5d423840644d3357f4-Abstract-Conference.html (see also arXiv:2305.18274, https://arxiv.org/abs/2305.18274)
[3] Scotti, P. S., Tripathy, M., Torrico, C., Kneeland, R., Chen, T., Narang, A., Santhirasegaran, C., Xu, J., Naselaris, T., Norman, K. A., & Abraham, T. M. (2024). MindEye2: Shared-subject models enable fMRI-to-image with 1 hour of data. In R. Salakhutdinov, Z. Kolter, K. Heller, A. Weller, N. Oliver, J. Scarlett, & F. Berkenkamp (Eds.), Proceedings of the 41st International Conference on Machine Learning (Proceedings of Machine Learning Research, Vol. 235, pp. 44038–44059). PMLR. https://proceedings.mlr.press/v235/scotti24a.html
[4] DeMond, E. (n.d.). Wide-and-flat software architecture. Retrieved August 12, 2025, from https://www.evandemond.com/programming/wide-and-flat
[5] von Platen, P. (2022, April 5). Transformers design philosophy: Don’t repeat yourself. Hugging Face Blog. https://huggingface.co/blog/transformers-design-philosophy
[6] Abramov, D. (2020, July 13). The WET codebase. Overreacted. https://overreacted.io/the-wet-codebase/
[7] CLA assistant. (n.d.). Contributor License Agreement assistant [Software]. GitHub Apps. Retrieved August 12, 2025, from https://github.com/apps/cla-assistant
Cite this post
Scotti, P. S. (2025, September 8). How to structure open science collaborations online. Retrieved from osf.io/preprints/psyarxiv/4u5ng_v1