Web-based collaborative mathematics research in algebraic geometry ------------------------------------------------------------------ Proposed details for how a project will be run on the algebraic_geometry web-site. Discussion, suggestions or changes should be mailed to the mailing list. Info on the mailing list at http://www.math.columbia.edu/mailman/listinfo/algebraic_geometry Initial actions: (a) Some person or group of people has to come up with the initial mathematical text(s). The initial submission can be a single file or a more complicated filesystem. (b) Only submissions that come with a copyleft license such as the GFDL will be considered. (c) Somebody is assigned as the "maintainer" of the project, this could be (one of) the author(s) and in my opinion this should be somebody who really knows what is going on (mathematically speaking I mean). (d) The submission gets published on the web-site. Both (La)TeX sources as well as dvi/pdf/ps versions are published. (e) There is a mailing list assigned to the submission. This mailing list will be public (publicly accessible archives posted on the web, anybody can subscribe), but it is moderated by the maintainer. The maintainer can assign others to help moderate the list; weeding out spam is not a mathematical job. Revisions, additions, patches As you know when you have a file and newer version of a file, then you can take the difference. The result is what is called a "patch". You can apply the patch to the original to obtain the newer file. Even though mathematically speaking there is no difference between submitting a patch or the newer version, it is convenient to think of newer versions in terms of patches. Patches make it all worthwhile! (a) Patches should be submitted by e-mail to the mailing list for the project. Of course if somebody sends a whole file(system) then it is easy enough to create the patch so this is fine as well. Note that patches should be against the source files not the dvi/pdf/ps files. The e-mail should have brief comments explaining what changes were made and why. (b) It is understood that patches are submitted under the same license that the initial submission is under. This allows for further edits of patches. (c) The maintainer decides whether a patch is applied to the public version, perhaps after some edits. If so then the new version is published on the web. Remarks (a) Obviously some submissions are not changes of already existing files but require adding new files such as "appendix", "explanation", "example" etc. Another idea is to have people submit new "chapters". It is up to the maintainer to decide whether these get added. (b) Cloning. If a critical mass of active memebers of the mailing list decide there is a need to start a new version of the project, where the philosophy is different and perhaps the proofs and mathematical methods are substantially different, then the project can be cloned. Think of the difference in approach and goals between writing a Hartshorne style text about algebraic geometry and an EGA style text. Cloning is discouraged for obvious reasons. (c) A good thing about submitting the patches to the email list is that it is public so everybody can compare and comment and find mistakes in patches as well as in the published text. (d) Small patches should be encouraged. Larger changes should be divided up into more smaller changes. Rewriting the book entirely is not advised. (e) Credit issues. The credit model is different in such an open environment. We do not see the point even of having lists of contributors. However, by looking throught the mailing lists it will be clear who contributed to the project. It probably makes sense to mention the originators of each project somewhere in the text. (f) Currently the concensus seems to be that projects where the goal is to write lecture notes, graduate texts, or introductory books will work better than directly doing research projects in this way. However, we would love to be proved wrong. Freeness is commodity pricing. Technical notes (FIXME) Each project will gets its own base-directory which is somewhere below the document root for the webserver. In this directory there should be put a directory called src and in src there should be Makefile (a file) .tex files .bib files miscellaneous files such as README, COPYING, INSTALL, MANIFEST In addition to the directory src the following directories are optional: tmp (a directory for temporary files produced during compilation), scripts (a directory with scripts), patches (a directory with patches applied sofar), documentation (a directory with howtos related to project), and museum (a directory with tar-balls of previous versions). This should be setup so that the following actions suffice to get the web-site for the project up and running (on a system with a reasonable TeX and LaTeX setup + web-server): (0) cd to src directory, (1) do ``make all'' (this will generate all the pdf, dvi, ps and html files, with the exception of index.html that will be generated by running ``make install''), (2) optionally do "make -n install" for a dry run, and finally (3) ``make install''. The result of doing this should be that .dvi, .ps and .pdf files, as well as the html files (including index.html) get published inside the INSTALLDIR=base-directory. The reason is that it should be easy to setup mirrors of the project web-site.