LogoLogo
  • Technical Direction
  • Technical overview
    • Technical Implementation
    • API Design Guide
      • Data Definitions and Standards
      • Data Transfer Objects
      • Documentation
      • Environments
      • Error Handling
      • Example API Service
      • GraphQL Naming Conventions
      • Methods
      • Naming Conventions
      • Once Only Principle
      • Pagination
      • Resource Oriented Design
      • REST Request
      • REST Response
      • Security
      • Versioning
    • Ísland.is Public Web Data Flow
    • Code Reviews
    • Code Standards
    • Monorepo
    • Project Management
    • Teamwork
    • Architectural Decision Records
      • Use Markdown Architectural Decision Records
      • Use NX
      • Continuous Integration
      • CSS
      • Branching and Release Strategy
      • Error Tracking and Monitoring
      • What API Management Tool to Consider
      • Viskuausan Static Site Generator
      • Use OAuth 2.0 and OpenID Connect As Protocols for Authentication and Authorization
      • Unified Naming Strategy for Files and Directories
      • CMS
      • Open Source License
      • What Chart Library Should We Use Across Island.is?
      • What Feature Flag Service/application Should We Use at Island.is?
      • Logging, Monitoring and APM Platform
      • ADR Template
    • Log Management Policy
  • Products
    • Island.is Authentication Service
      • Terminology
      • Integration Options
      • Authentication Flows
      • Authorising API Endpoints
      • Session Lifecycle
      • Scopes and Tokens
      • Delegations
      • Configuration
      • Tools and Examples
      • Environments
      • Test IAS with Postman
      • Using the IAS admin portal
    • Notifications / Hnipp
      • New Notification Setup Guide
      • Notifications service workflow overview
      • Email notifications
    • Pósthólfið
      • Security Checklist
      • Introduction
      • Skjalatilkynning API
      • Skjalaveita API
      • Sequence Diagram
      • Interfaces
    • Straumurinn (X-Road)
      • Architecture Guidelines for Service Providers and Consumers
      • Setting up an X-Road Security Server
        • Network Configuration
      • X-Road - Uppfærsla á öryggisþjónum
      • Straumurinn - Notkun og umsýsla
      • X-Road Central - current version
  • Development
    • Getting Started
    • Generating a New Project
    • Definition of done
    • Devops
      • Continuous Delivery
      • Database
      • Dockerizing
      • Environment Setup
      • Logging
      • Metrics
      • NextJS Custom Server
      • Observability
      • Operations Base Principles
      • Security
      • Service Configuration
      • Support
    • AWS Secrets
    • Feature Flags
    • Documentation Contributions
    • Defining Monorepo Boundaries With Tags
    • OpenAPI
    • Code Generation
    • Workspace Settings (Deprecated)
    • External Contributions
  • REFERENCE
    • Problems
      • 400 Validation Failed
      • 400 Attempt Failed
      • 403 Bad Subject
      • 400 500 Template API Error
    • Glossary
  • Misc
    • Guide: Adding a Payment Step to an Application
    • Guide: Enable Organisations to Make Requests to an Application
    • README Template
Powered by GitBook
On this page
  • Disciplines
  • Dev
  • Devops
  • Design
  • Architecture decision record

Was this helpful?

  1. Technical overview

Teamwork

Projects are developed in teams that win tender contracts with Digital Iceland. These teams come from different companies, but work in the same codebase and projects. So it is important to foster good communications and collaboration as well as to formalise responsibilities and decision-making.

The first step is to get everyone in the same room, be it online or offline. We use Slack to host discussions in multiple focused channels. This gives everyone the chance to ask questions and get feedback on what they're working on.

Disciplines

Disciplines connect teams to discuss issues, share knowledge and make decisions.

Each discipline has a discipline manager that organises regular discipline meetings, manages agendas and publishes meeting minutes and decisions. During a discipline meeting, it's the manager's role to keep discussions productive and decide if something needs further research or a vote.

Meetings are open to interested parties but should be attended by at least one person from each active team that are part of the discipline. Discipline members can submit items to the agenda. Each item on the agenda should have an owner that presents the item and any proposals for discussion.

Discipline meetings should be used to get decisions on smaller issues and communicate best practices across teams. Larger issues and discussions should be moved to RFCs. The goal is to discuss, decide and move along.

Currently there are 3 disciplines, but this may change as needed at any time.

Dev

Responsible for the monorepo, dependencies, tooling and shared code.

Devops

Responsible for CI, CD, operations and monitoring.

Design

Responsible for the brand, design system, UX and consistent design across projects.

Architecture decision record

It is important to document all important decisions made in this project. This might, for instance, be a technology choice (e.g., PostgreSQL vs. MongoDB), a choice between a library (e.g., moment vs date-fns), or a decision on features (e.g., pagination vs infinite scroll). Design documentation is important to enable people understanding the decisions later on.

PreviousProject ManagementNextArchitectural Decision Records

Last updated 10 months ago

Was this helpful?

Decisions should be documented using formatting inside the adr folder. Just copy 0000-template.md to for example 0001-date-library.md and fill in the details. Many sections can be skipped for smaller decisions.

MADR