|Catalan Castellers are |
Availability of distributed code tracking tools and associated collaborative tools make life much easier in building collaborative scientific tools and products. This is now especially much more important in data science as it is applied in many different industries as a de-facto standard. Essentially a computational science field in academics now become industry-wide practice.
Peer-review is a pull request
Peer-reviews usually appears as pull requests, this usually entails a change to base work that achieves the certain goal by changes. A nice coincidence that acronym PR here corresponds to both peer review and pull request.
Technical excellence does come with decent behaviour
Aiming at technical excellence is all we need to practice. Requesting technical excellence in PRs is our duty as peers. However, it does come with a decent behaviour. PRs are tools for collaborative work, even if it isn’t your project or you are in a different cross-function. Here we summarise some of the high-level points for PRs. This can manifest as software code, algorithmic method or a scientific or technical article:
- Don’t be a jerk We should not request things that we do not practice ourselves or invent new standards on the fly. If we do, then give a hand in implementing it.
- Focus on the scope and be considerate We should not request things that extend the scope of the task much further than the originally stated scope.
- Nitpicking is not attention to details Attention to details is quite valuable but excessive nitpicking is not.
- Be objective and don’t seek revenge If someone of your recommendations on PRs is not accepted by other colleague don’t seek revenge on his suggestions on your PRs by declining her/his suggestions as an act of revenge or create hostility towards that person.
We provided some basic suggestion on high-level guidance on peer review processes. Life is funny, there is a saying in Cyprus and probably in Texas too, –what you seed you will harvest-..