While we may write code faster when working alone, we are more innovative, collaborative and engaged when working together. Sharing information and ideas is the cornerstone of our work, and our culture values effective and efficient collaboration within and between teams, and beyond. In order to do that we must communicate effectively with each other.
We aim to reach consensus in our discussions, with consensus defined as, “I can live with this and find a way to support it.” Consensus does not mean uniform and undying love for an idea, which is an unreasonable standard for a group as large and diverse as ours. This definition of consensus means that we should all expect to make compromises to arrive at practices and processes that can work for all of us; consensus can work for us if all are willing to give a little and work to balance our personal sensibilities with the team's.
We work in teams whenever possible to share experience and knowledge. Teams are at least two people, and preferably more than two. Teams have standups to discuss ongoing work and ensure that progress is being made. We are available in person and online for team discussion during regular working hours.
We encourage others in the team to report bugs in our code, and do so for others with respect and justification. When doing so, we try to present solutions, especially in the form of pull requests, rather than just noting a deficiency.
We communicate early and often with other teams that will be affected by our work, and/or teams from which we need input.
In particular,
- We talk with Operations, particularly concerning deployment, scalability (storage, VMs) and security.
- We talk with Design, particularly concerning UI components and accessibility.
- We talk with Developers, particularly concerning shared code (e.g. dlss gems in common), common tools (e.g. Rails, Fedora, webauth, blacklight), and new tools to be adopted.
- We talk with Managers, particularly concerning scheduling and scope (creep).
We communicate with our users and stakeholders regarding deployment of our products.
We report bugs in code from outside of DLSS, and if possible provide solutions when doing so, or when the issue has been acknowledged. We do so politely, concisely, and with coherent use cases and justification. We use github issues in our repos that link to upstream bugs that are outside of our control in order to follow up on that communication.