Pilot 2.0 Project Guidelines

Introduction

This document outlines the guidelines for the Pilot 2.0 project, to be followed by all contributors.

Guidelines

How will the coordination and cooperation be achieved?

• Have frequent meetings (preferably face-to-face, otherwise vidyo conference) both in smaller groups and larger Pilot Dev meetings
• Use the Pilot Developer e-group mailing list (atlas-ads-pilot) for (internal) technical discussions. Caution: to avoid mail overflow, try to be concise but do not cut away previous replies in the thread.
• Use activity and milestone plans and reports

How to write documentation?

• Keep documentation on a professional level, i.e. use formal, well written English
• Use UML when appropriate (major algorithms, workflows, models, class diagrams)

Which versioning scheme should we use?

• 2.major revision.minor revision (optional label)
• E.g. 2.0.0 [initial release], 2.1.1beta

What to work on?

• Consult the Milestone Plan – to be located within the project wiki
• Subprojects should be coordinated so ask before starting something new

Which coding convention to follow? (As implemented in the testing framework)

• PEP8: https://www.python.org/dev/peps/pep-0008/
• In addition to PEP8, we enforce a complexity not higher than 10 for any function, and we restrict broad exceptions, lambda assignments, broad importing and other ambiguous coding practices

Which naming convention to follow?

• Follow the naming convention of PEP8 (see above)
• Keep it in line with Rucio conventions for simplicity (there are two Rucio developers in the Pilot team as of August 2016)
• Lower spinal case (snake case with underscore(s)) for function/method/variable names, e.g. my_method(), variable_name = ..
• Try to stick to single word in module names (short lower case – only use underscore if absolutely necessary), e.g. module.py, rucio_sitemover.py

How to do indentation?

• Preferably use 4 explicit spaces per indentation level
• Tip: use python option –tt to disallow mixed cases

Maximum line length?

• Stick to 120 characters

How to add new code?

• As of August 2016, use private forks until final Pilot 2 repository is in place - at that point:
• Create pull request into dev branch, triggering test suite, manager approves, new dev pilot will run rc test jobs

The Pilot 2.0 repository will be public but any external contributions must be properly motivated and clearly explained

• An external pull request with the motivation ‘this might be useful’ (and similar) is not acceptable and will be rejected/ignored unless it is further explained

Avoid condensed perl like python programming

• Yes, you have proven that you are smart but it makes it difficult for other people that might need to update your code at a later time unless there is a proper explanation of the code
• Code will not be accepted if it trades clarity for space

Any significant Pilot 1.0 request that arrives during the Pilot 2.0 project should be added to the todo/wishlist wiki page until it has been implemented in Pilot 2.0 (if required)

• https://twiki.cern.ch/twiki/bin/view/PanDA/Pilot2WishList

-- PaulNilsson - 2016-08-29