Essential information and group infrastructure

Authors: Tiago P. Peixoto¹
Affiliations: ¹Inverse Complexity Lab
License: CC-BY

Flexible workplace and working hours¶

In our group we try to maximize flexibility regarding workplace and working hours, while also encouraging on-site presence for better group integration, spontaneous discussions, collaborations, etc.

In view of this, the following general rules are to be observed:

1. On-site presence is required for our weekly group meeting.^[1]
2. To facilitate coordination, weekly on-site presence, as well as absences like vacations, conferences, etc, should be indicated in the group’s Nextcloud shared calendar.
3. Be mindful of the overall group availability, in order to:
   • Utilize the overlap with other team members;
   • Avoid long periods of minimal or no overall on-site presence — both for individuals, as well as the whole group.

Group infrastructure¶

Git and gitlab¶

We use git to share code and work collaboratively. In particular we use the gitlab instance at https://git.skewed.de for our projects, both internal and external.

Members of the lab should join the invcomplexity group, so that shared access to internal projects can be managed more easily.

We should avoid github for our own work.

Collaborating using git¶

The idea of decentralized version control systems like git is that there’s no central repository to which collaborators are required to push. Although some people use git with a central shared repository, this actually beats the purpose of the invention of such systems, and emulates instead the old “pre-git” way of doing things, e.g. using CVS — a now defunct versioning control system.

Instead, the decentralized mode of operation should be:

1. The originator (or maintainer) of the project creates their repository (a.k.a. the ‘upstream’ repo).
2. Contributors fork the upstream repo, and make their modifications locally.
3. When ready, the local modifications can be pushed to the upstream repository by opening a merge request.
4. The maintainer may then accept (or not) the merge request to the upstream repo.

Naturally, merge requests can also be done between any two repos, so any structure of collaboration is allowed.

The identity of the “upstream” is just a convention shared by the collaborators, hence the lack of centralization. If the maintainer disappears, one of the forked repositories can become the “upstream” as long as there’s a consensus. This is also a much better way to handle conflicts.

Sharing files¶

We use nextcloud at cloud.skewed.de to share files. Please open an account there, and consider installing the desktop client, so that your folders get automatically synchronized.

We also have a team folder there called InvComplexity where we can share files simultaneously between all members of the group. We are also free to share folders with any subset of the group members, or even with external users.

Chat¶

We use the matrix open protocol for decentralized, encrypted, and real-time communication. We use the Element web client, and the Element x client for mobile, but any compliant client will work.

We have a members-only room, that lab members should join.

Video calls¶

Due to institutional constraints, the meeting rooms can only be booked via MS Teams, so we tend do default to that for video calls.

However, we also have a jisti server available at https://meet.skewed.de, which is a fully functional P2P encrypted video call system, does not require authentication, and is quite easy to use.

Shared bibliography¶

We share bibliography using Zotero, with our own group here.

Wiki¶

Everything that does not fit here, e.g. that are not intended for outside visibility, like informal things, links to bureaucratic forms, please refer to the wiki at https://wiki.skewed.de.