.. _in_team_communication:

In-team communication
=====================

Tasks people need to do go in GitLab, but that is *not* how tasks should be communicated.  Whenever possible, anything important enough to be assigned is worth talking about in 'real-time' first, or concomitantly.  Everything needed to understand an issue should be captured in GitLab, but we want to avoid back-and-forth 'huh what?' and 'nuh-uh not me' (un-assign)

Discussion that takes place outside of GitLab needs to be summarized (or copy-pasted) into the relevant issue in the GitLab project.

IRC
---

#agaric

Agaric also maintains a channel for worker-owners only.

Edit or add.  That's the primary instruction.  You can edit directly on `gitlab.com/agaric/documentation <https://gitlab.com/agaric/documentation>` (for example, the edit link on this page takes you to `gitlab.com/agaric/documentation/blob/master/documentation.rst <https://gitlab.com/agaric/documentation/blob/master/documentation.rst>`).  If you aren't a member of Agaric, GitLab will helpfully offer to fork the documentation to your own namespace so that you can make a merge request with your documentation suggestion.

.. note::
    Agarics can get more detail ` <https://gitlab.com/agaric/internal/wikis/Communication-Channels>`.

anyone can come and clean up formatting later.

Principles
----------

* Document closest to where people work:
   * In README.md files or otherwise in the code repository for developers, .
* Abstract and link here

.. note::
    In documentation we are living our `values <>` of encouraging continuous learning, appreciating new ideas, giving back to the communities we are part of, and valuing long-term relationships.