Berlin Document

  1. This paper in the Berlin document. It it a set of action statements for the development of ACIS
  2. Thomas Krichel started work on this paper in Novosibirsk, Russia on 2005-07-11.
  3. Contrary to other working documents by Thomas Krichel, this one has versions kept at in a directory. The Berlin Directory holds different version of this same document on files named after the modification date.
  4. The slow progress on developing the ACIS software has been a chronic problem. Ivan V. Kurmanov (henceforth Ivan) and Thomas Krichel (henceforth Thomas) have simply to date been unable to complete the project speedily.
  5. Stage 1 of ACIS has been successfully completed and the RAS web site is working well.
  6. Ivan convinced Thomas to work on stage 3 prior to working on stage 2. Thomas now thinks that this decision was wrong because of the complication in stage three which requires modifications to an external software Eprints not under control of ACIS.
  7. A major problem has been the decision of Thomas to out-source the development of the eprints software development. Thomas instructed Ivan to study eprints and prepare an interoperability document that will set out in detail changes that will have to be made. Instead, Ivan wrote software that implements some of the changes. Thomas has so far refused to pay for that software.
  8. In July 2005, Ivan and Thomas agreed to have a developer Roman D. Shapiro (henceforth: Roman) join the project. Roman comes with a track record as a fast developer and even faster learner, but lousy documenter. Thomas hopes that with Roman developing and Ivan monitoring and documenting, the development process can be speeded up.
  9. There is no alternative to speeding up the process because OSI are likely to ask the money back if the project is not finished soon. Thomas has signalled his willingness to comply since he too rather would like to see the money go rather than not deliver what he and Ivan promised to.
  10. Nevertheless, Thomas and Ivan have decided to to make a final push to get ACIS development done. Special projects for ACIS implementation can be done later.
  11. The official start of the ACIS Development Acceleration Program, ADAP is 2005-07-13.
  12. The team (Ivan, Roman, Thomas) wutilize a new acis-development list. Members are supposed report each day on what they have done or have not done for the project. Failure to report (because off-line etc) are to be reported in advance. Failure to report in advance can be reported afterwards, but there need to be good reasons. Failure to write leads to a loss of income of $10 a day.
  13. The start is planned as follows. Ivan will write a document detailing what he has done for eprints and what further needs to be done. Thomas will pay Ivan $500 when a first version is read. He notes that this is more like an emergency money help, to keep Ivan afloat rather than an acknowledgement that the document cast $500 to write. He will decide how much money to spend for the contracted out effort.
  14. On 2005-08-16, one month after the start of the effort, the documentation is still not finished. Thomas sets a date of 2005-08-30 date after which Ivan looses $100 for not delivering within reasonable time.
  15. Roman will get $500 from the special project part of the budget to set up an installation of ACIS with rclis AMF data. This installation will be planned by Thomas. The installation is supposed to work within 2 weeks. Roman is supposed to start working on this starting 1 August.
  16. On 2005-08-16, two weeks after starting, the implementation is not ready and Roman looses $50. He will now get $430 for the work, given that he has also lost money for non-writing on the list.
  17. Ivan Kurmanov did not finish the documentation within 4 weeks after the start. In fact by 2005-08-19 the documentation is not finished. Ivan has been given two extra weeks, until 2005-08-30 to finish the documentation. However in exchange Thomas has required and extra piece to be added, a helper function that will fetch a metadata recond from an OAI-PMH compliant archive using the OAI-PMH "getrecord" verb.
  18. On 2005-08-19, Ivan and Thomas agree that that the technical spec is not a single solid document, but is a set of documents. Most of those become part on ACIS documentation and must describe ACIS as if stage 3 is completed (with optional easy-to-remove notes on what is actually implemented already, and what is not yet). The spec is based on Saskatoon. The first document describes general document archive/ACIS interactions and general tools for it (cooperate.html). The second document describes EPrints-ACIS interactions, EPrints modifications, add-ons, interface changes (eprints.html). The third document describes related ACIS db structures and access to it (db.html).
    Additionally, the set of documents includes a current-development document with a structured list of concrete steps that need to be taken to implement the above described spec.

Valid XHTML 1.0!