Contributions to the ANTEDB are very welcome! For short contributions (such as correcting a typo, or adding a reference or citation), one can simply email the correction to one of the maintainers of the ANTEDB (Terence Tao, Timothy Trudgian, or Andrew Yang). Alternatively, if one has familiarity with Github, one can submit a Github Pull Request (PR) to the Github repository with the suggested changes, or raise a Github issue.
Some specific information about types of contributions:
The references are stored at references.bib in BibTeX format. If possible, please try to maintain the alphabetical ordering of the references by first order.
The chapters are stored in this directory. One can use standard LaTeX commands in these chapters. One can also use the \uses{} macro to indicate which results depend on which other ones, for the purpose of filling out the dependency graph, though at the current stage of the project we are not making heavy use of this feature.
It is fine to suggest incomplete contributions, for instance stating a result with only a very sketchy proof or reference. For an extremely incomplete contribution (e.g., a vague statement of a result without a reference, or proposing a new direction for the ANTEDB without contributing significant content), consider opening up a Github issue instead of a pull request.
If you propose to add a new chapter, or rearrange existing ones, one will also have to modify content.tex. It is also recommended that each chapter be labeled, in order for the blueprint to be able to assign a stable name to the web page for that chapter. It is recommended to see if print.tex compiles before submitting the pull request. [Note: some LaTeX compilers may have difficulty with some of the packages. xelatex generally works well though.]
Some examples of possible chapter topics to contribute can be found in the introduction to the ANTEDB blueprint. Please feel free to contact Terence Tao if you are interested in fleshing out one of these chapters, in order to coordinate with any other contributors.
For standalone chapter submissions that are not integrated with the rest of the blueprint, add the \unintegrated macro at the beginning of the chapter. We will eventually plan to integrate the content more fully in to the ANTEDB, but are happy to take unintegrated submissions as a first step towards that.
Python code is stored in this directory. References to python code within the blueprint can be made using the (somewhat crude) \code{}, \python{}, \literature{}, and \derived{} macros, defined in common.tex.
At present we do not have any Lean code in this database, although we have structured it to allow for future expansion in this direction. If you have some ideas for such an expansion, please do not hesitate to discuss them with the maintainers of the ANTEDB, or raise a suitable issue on the Github repository; if there is sufficient interest, we may start a broader discussion to take more steps in this direction.
The ANTEDB is intended to collect results on analytic number theory exponents in the literature in such a way that they can be combined as readily as possible, by either humans or computers. Because of this, we have made efforts to select standardized notations to apply globally across the ANTEDB, and to express results from the literature in these standardized notations, even if they are expressed in a somewhat different notation in the original source material.
For instance, we have chosen to use a "cheap nonstandard analysis" convention for asymptotic notation, as it efficiently hides the "epsilons and deltas" in the exponents, which has some technical advantages for the numerical side of the project as it often allows exponents to be represented by rational numbers which can be easily manipulated by exact arithmetic rather than floating point arithmetic.
The focus on the ANTEDB is on the exponent bounds in the literature, rather than the notational choices from that literature, and the addition of notational conventions to the ANTEDB that duplicate ones that are already present in the database is therefore discouraged in order to maximize interoperability of results. However, it is conceivable that there is a case for globally refactoring the ANTEDB to switch from a current notational convention to new one; if so, one should set up a Github issue to discuss the pros and cons of such a global switch.
If you wish to create a database similar to the ANTEDB, but with a different scope, you may wish to set up a Lean Project with a Blueprint by following these instructions. (The ANTEDB currently contains no actual Lean code; nevertheless, the Blueprint-based structure of a Lean project is quite convenient for such a database even without such code.)
If you do create a new mathematical database, consider registering it at Mathbases.