Thanks for your interest in contributing to academic research in computer science! These guidelines explain how scientific knowledge is developed and how to submit your contribution. These guidelines are not rules: the actual rules of academia are only known by word-of-mouth, not explained anywhere, but take precedence over anything written here.
The goal of submitting and merging contributions to the academic research project is mostly to get them seen and acknowledged by other developers. As for users, we are not sure if there are any.
Often, your main goal in contributing will be to put the merge request on your CV. In this case, know that the impact of your merge will be measured by its number of citations, i.e., how many discussions and bug reports are mentioning the code.
All contributions must use academia's official TeX/LaTeX development toolchain, which was initially coded by Don Knuth as a Pascal program in the late 70s, and only superficially modernized since then.
Your merge request must be submitted in PDF format (in your IDE, select File > Print to PDF), following a specific stylesheet and a strict page limit.
Depending on the theme of your contribution, merge requests can only be submitted at a few yearly deadlines corresponding to physical project meetings (aka "conferences").
If your merge request is accepted, you are required to present it in person at the meeting, by travelling at your expense to wherever in the world it is taking place; and additionally paying a multi-hundred-dollar registration fee not usually disclosed in advance.
All contributions, including large contributions, should be developed entirely privately, lest someone else steals your precious ideas and does the work in your stead. Finished contributions should be uploaded in bulk only when they are entirely finished. Once merged, they will be immediately abandoned by their authors to work on other contributions. As for datasets, test cases, examples, proofs, they will not be released at all.
When submitting a merge request to an existing project, a crucial factor in accepting the merge will be to discuss authorship, i.e., do the contributions justify the addition of new names in the "About" box of the program, and in which order.
All merge requests submitted to this repository will be subjected to peer review to ensure their quality. Namely, you will receive an email after several months containing multiple independent and contradictory reviews featuring dismissive criticism about your work. You are then to modify your merge request based on this feedback, submit it again, wait for a few months, and repeat until the contribution is accepted or rejected.
Most likely, your contribution will get rejected. In this case, you can reformat your code and try to merge it with some other, less prestigious codebase. (The prestige of codebases is estimated based on their age and how selective they are in accepting merge requests.) Your contribution doesn't count as "published" until it has been merged in some codebase, no matter how irrelevant.
All merge requests must include a thorough discussion of related work, i.e., a survey of all existing software implementations developed at any point over the last decades, in any programming framework or architecture, which do anything that remotely resembles the proposed contribution. For each related work item, you should include a misleading explanation of why they are worse than you.
Make sure to cite these related work items with consistently-formatted bibliographic citations that include page numbers, but no hyperlinks.
The academic research codebase is not open-source. If your contribution is accepted, you are required to sign a copyright transfer form giving away your rights on the contribution to some publisher company. This company will not compensate you for this, and in fact do not pay any project developer or maintainer. Their job is to run the hosting platform, and package the software to sell it for an overpriced subscription fee. You will never see any of this money; to the contrary, you or your employer will need to subscribe so that you can know about other contributions to the project.
We believe that this arrangement is in the community's best interest to make our software widely available. If you cannot afford the fee, no problem: you may be able to find the software for free on some illegal foreign websites that everyone uses, and you may also be able to download specific patches by going to the homepages of individual developers.
If you have read this far, you may be interested in a permanent job in contributing to academic research in computer science!
To get such a job, you should first spend several years doing a PhD, and then some indeterminate number of years working as a postdoc or research assistant. During that time, you should work as hard as you can to get any sort of code merged, often while being paid a below-market wage, and on short-term contracts giving you little flexibility in the choice of city or country of residence.
If you are lucky, you may land one of a very small number of permanent positions. You will spend most of your time teaching and taking care of administrative tasks, but it may leave you some free time during holidays and weekends where you can contribute to research!
Interested? Just get in touch with one of our tenured maintainers. If they bother replying, they might have some work to give you so you can get started on your journey to the top of the pyramid.