LiquidPub Development Guidelines

Conventions used in this documents

Monospaced text (like this one) denotes code excerpts or command line instructions.

Yellow-highlighted text (like this one) indicates unpolished parts of document, still lacking clearness, completeness, or both.

Intended audience for this document

This document's primary goal is to inform people wishing to actively collaborate to the project development process; therefore, it is addressed to software developers with experience in coding complex, modular, and innovative projects. LiquidPub Platform is an open source project, and, as with other open source projects, the ability to interact responsibly and productively with other developers and project leaders is essential.

Table of Contents

1. LiquidPub Development Guidelines
1. Conventions used in this documents
2. Abstract
1. Intended audience for this document
3. Table of Contents
4. Introduction
5. Social infrastructure
1. Ways to collaborate
2. Communication
6. Technical infrastructure
1. Code repository
2. Builds
7. Testing
1. Continuous integration
2. Sandbox instance
8. Bug tracking
9. Versioning
10. Code style and code documentation conventions
11. Internationalization and localization (i18n and l10n)
12. Licensing
13. References and credits
14. Database Guidelines

Introduction

  We aim to develop a web application platform which will support this goal. This platform will:

• allow scientists to freely share scientific content without having to first publish it through traditional peer-review system.

• allow other colleagues, or even general public, to see shared content, annotate it, comment it and even edit it.
• distinguish among various contributions, by associating author and timestamp information to each modification, thus mitigating the problems of attributions and/or "cloning" that trouble scientific community today.
• allow scientist to interact with each other in a "social network"-like environment, thus enabling informal communication among scientists by means of commonly used "social" tools like forums, IMS, blogs. We plan also that our system should be able to integrate with existing networks to take advantage of their features and also their large user base, instead of trying to substitute them.
  
• make complex research project management easier, by providing tools for p.m. common tasks (scheduling, resources allocation, ...) and also for science-related ones (deliverables, reviews, ...).
• make chairing conferences easier, by automating most of related tasks and integrating well with science documents handling.
• make publishing scientific journals process easier, by automating publishing workflow (collecting papers, having them reviewed for the time due, publish the journal) as much as possible.

Social infrastructure

The LiquidPub Project development leadership is owned by LiquidPub consortium partners: the last word about changes on the nature and scope of the project code base as a whole belongs ultimately to them.  For ease of development and management, code has been split among many project modules, each one having one module manager, who's appointed with the task of leading software development for her/his modules as well as coordinating with other modules managers during the integration process.

Ways to collaborate

As stated http://project.liquidpub.org/developers-1, there are (at least) three means for the willing ones to help improving our project:

• Signal a bug or submit a new feature request: this has to be done through our public issue tracker. Please note that registration is not necessary to add new tickets or see existing ones, albeit registered developers are given more access rights than anonymous users (they can take charge of a bug correction/new feature implementation request, edit it, delete it, mark it as "done", and also update issue tracker's internal wiki with project development-related information).

• Taking charge of fixing a certain bug and/or of adding a new features, thereby developing a code patch: you can subsequently send your patch to our patch manager who will choose whether to include it to our codebase. Patch managers take decisions basing on basically two factors, that the code must meet project quality standards by respecting project guidelines (that is, the document you are reading) and if the new features or the changes introduced are oriented, to a significant extend, toward fulfilling main project goals (essentially, if they are of some interest for us).
• Write fixes / new code directly into the project code base by accessing its repository; however, in order to do that you need to get commit access authorization.

Communication

 Hostname: dev.liquidpub.org
 Issuer: 07969287, http://certificates.godaddy.com/repository, GoDaddy.com, Inc., Scottsdale, Arizona, US
 Fingerprint: 8a:8c:65:a0:0c:1e:c2:71:d2:e8:39:c5:0b:59:f0:51:0d:e8:47:15

Code ownership will be retained by  the LiquidPub project consortium, even after project official end.

References and credits

This document owes much to Subversion development guideline and Apache Software Foundation documentation, which are also referenced through it, either directly or indirectly.

Database Guidelines