DiracX hackathon

21 Jan 2026, 09:00 → 22 Jan 2026, 17:30 Europe/Zurich

2/R-014 (CERN)

Alexandre Franck Boyer (CERN), Andrei Tsaregorodtsev (Aix Marseille Univ, CNRS/IN2P3, CPPM, Marseille, France), Chris Burr (CERN), Christophe Haen (CERN), Federico Stagni (CERN)

Ddev meeting notes: https://codimd.web.cern.ch/QMVdoWxiShS9Iv9Mp9ifKw

24-06-19_DUW_Diracx.pdf

DiracOrganization.pdf

# DIRAC Development Meeting (Ddev)

- **At CERN:** Federico, Christophe, Chris, Ryun, Alexandre, Luisa, Natthan, Stella, Loris, Bertrand, Heloise, Daniela, Andrei, Volodymyr, Cedric, Ruslan, Jorge
- **On Zoom:**

## Product Goals & Roadmaps

- Transition to DiracX:

```mermaid
flowchart LR
    subgraph CWL["CWL"]
        CWL1("CWL submission endpoint")
        CWL2("CWL production system")
        CWL3("Transformation system machinery"):::blocked
        CWL4("Use CWL natively in new matcher"):::blocked
    end

    subgraph Core["Core"]
        CoreTasks("Tasks")
        Core2("RSS")
        Core3("DMS")
    end

    subgraph WMS["WMS"]
        WMS1("Matcher"):::blocked
        WMS2("Pilot authentication")
        WMS3("Pilot submission"):::blocked
    end

    CWL3 --> CWL4
    CoreTasks --> Core2 --> Core3
    CoreTasks --> WMS1
    CoreTasks --> CWL3
    WMS1 --> CWL4
    CoreTasks --> WMS3

    click CoreTasks "https://www.github.com" "This is a tooltip for a link"

    classDef done fill:#B2DFDB,stroke:#00897B,color:black,stroke-width:2px;
    classDef blocked fill:#BBBBBB,stroke:#222222,color:black,stroke-width:2px;

    subgraph Legend
        L2("Completed"):::done
        L1("Ready for work")
        L3("Blocked"):::blocked
    end
```

- CWL integration:

- Product Goals:
  - should we work on the different goals in parallel? (Matcher,  CWL)
  - shoud we focus on transition to DiracX?

- Chris: we can't transition everything 1-1 to DiracX (e.g. current Matcher does not work well, not adapted to HPCs...)
- CTAO: wants to move to DiracX soon to manage everything from K8s, but we manage to run DIRAC on it, so we can live with DIRAC living around for years.
- Bertrand: the quicker we move to DiracX-only, the better
- Andrei: new communities are going to be lost if we don't speed up transition.
- Christophe: not everyone will focus on the same pieces. Needs (e.g. CWL) give contributors.

 

## Refinements 

https://github.com/orgs/DIRACGrid/projects/30/views/7

Goal: build a shared understanding of the project.

Based on `good first issue`

> diracx
- [Drop boto](https://github.com/DIRACGrid/diracx/issues/712)
- [Rename LollygagAccessPolicy](https://github.com/DIRACGrid/diracx/issues/449)
- [sqlalchemy DeclarativeBase](https://github.com/DIRACGrid/diracx/issues/612)
- [StrEnum](https://github.com/DIRACGrid/diracx/issues/622)
- [Release-Please Changelog](https://github.com/DIRACGrid/diracx/issues/685)

> diracx-charts
- [CS pre-upgrade job](https://github.com/DIRACGrid/diracx-charts/issues/215)
- [EdDSA](https://github.com/DIRACGrid/diracx-charts/issues/110)
- [StoreClassName](https://github.com/DIRACGrid/diracx-charts/issues/127)
- [CI diagram](https://github.com/DIRACGrid/diracx-charts/issues/183)
- [Get a certificate from LetsEncrypt](https://github.com/DIRACGrid/diracx-charts/issues/95)
- [Specific namespae](https://github.com/DIRACGrid/diracx-charts/issues/82)
- [Image Proxy](https://github.com/DIRACGrid/diracx-charts/issues/69)

> [Planning Poker](https://en.wikipedia.org/wiki/Planning_poker)
> Story points values (based on Fibo)
> 1 pt: Trivial, very clear (small bug fix, config change)
> 2 pts: Small, well understood (small feature, clear requirements)
> 3 pts: Medium, some unknowns (moderate feature)
> 5 pts: Large, significant complexity (major feature, integration)
> 8 pts: Very large, many unknowns (should probably be split)
> 13+ pts: TOO BIG - must split!

## Sprints

### Planning (Velocity and Planning Poker)


**Average Velocity: 3.07 x FTEs**

#### :warning: Velocity is a planning tool, not a performance target

- Velocity going down is NOT bad
- Velocity going up is NOT always good (might mean over-estimation)
- Velocity varies sprint-to-sprint
- We track it to improve estimation, not to judge people

**What affects velocity:**
- Estimation accuracy (we're still learning)
- Complexity of work

**Our focus:** Delivering value and hitting commitments, not maximizing velocity numbers.

### February 5th (IN PROGRESS):

#### Target
- Prototype is functional enough to start involving real workload
- CTAO can submit CWL workflows with input/output data using the RUCIO FC as jobs

#### Availability

- [name=alexandre] 20%
- [name=natthan] 20%
- [name=luisa] 20%
- [name=loris] 80%
- [name=stella] 20%
- [name=jorge] 10%
- [name=ryan] 10%
- [name=federico] 10%
- [name=volodymyr] 10%
- [name=heloise] 80%
- [name=bertrand] 10%
- [name=daniela] 20%

3.1 FTEs
Add heloise to the project

Expected Velocity: 34 (3 x 3 = 9)

#### Sprint Planning: 

- Backlog: https://github.com/orgs/DIRACGrid/projects/30/views/3
- Sprint: https://github.com/orgs/DIRACGrid/projects/30/views/1

### January 21st (DONE):

Expected Story Points: 37
Persons: 2.5
Expected Velocity: 14.8 :warning: 

*6 Story Points / 2.5 people = 2.4 velocity*

Comments:
- LHCb-CERN had a team retreat, LHCb-Spain had a conference.

#### Sprint review: https://github.com/orgs/DIRACGrid/projects/30/views/11

#### Sprint retrospective

*The sprint is a boat :boat: ; we are trying to reach an island (target); identify anchors (what slowed you down), wind (what helped), and rocks ahead (risks for next sprint)*

:warning: **Focus on the process, not people. We're here to improve together! 🚀**

**:anchor: Anchors (what slowed you down)**
- *Example: Unclear requirements on X; Waiting for Y delayed Z; ...*
- Holidays
- Not clear we should test the JobWrapper with the SingularityCE
- One item was worked on by 2 people at the same time: better define scope, better communicate.
- Rabbit hole, things went to big: need to split if it's the case.

**:cloud: Wind (what helped)**
- *Example: Good communication in weekly meetings; Quick code reviews; Clear acceptance criteria on user stories; ...*
- Code reviews help to get reminders: push things

**🪨 Rocks (risks for next sprint)**
- *Example: Team member K on vacation; Dependency on external API L; Technical debt in M; ...*

- LHCb computing workshop

---

### Previous Sprints
#### Summary

- January 7th:
  - *15 Story Points / 3.9 people = 3.8 velocity*
  - Comments:
    - No specific comment, the sprint was split by the holidays.

- December 10th (DONE):
  - *6 Story Points / 3 people = 2 velocity*
  - Comments:
    - About the same as the previous sprint: still a gap between expected/actual availability

- November 26th (DONE):
  - *6 Story Points / 3 people = 2 velocity*
  - Comments:
    - Much lower than the previous sprint because it included tasks started before the sprint.
    - Lots of "almost done" PRs: we are improving the description of the tasks and their size but still not enough (each task should bring value though).

- November 10th (DONE):
  - *22 Story Points / 4.3 people = 5.1 velocity*

#### Actionable Results from the Retrospective

- Better communicate when a PR is going to be big, as soon as possible. Split the work in this case.
    - Owner: developers
    - When: Sprint6
    - Status: 21/01/26 in progress
- Action: Better use of the mattermost channel to get reviews on a given PR
  - Owner: everyone
  - By when: Sprint3
  - Status: 21/01/26 in progress
- Action: Define estimates and velocity based on Sprint2's results, taking into account external contributions (bonus Story Points) and availability
  - Owner: alexandre
  - By when: Sprint3
  - Status: DONE
- Action: Better define the scrum roles
  - Owner: alexandre
  - By when: Sprint5
  - Status: DONE
- Action: Better define `DONE` criteria (what should be included into the PR, and how to make sure we are not introducing too much technical debt)
  - Owner: everyone
  - By when: Sprint2
  - Status: 21/01/26 in progress
- Action: Avoid planning dependent tasks in a same sprint
  - Owner: everyone
  - By when: Sprint2
  - Status: DONE

## AOB