Skip to content

2025-04-03.md

Latest commit

 

History

History
64 lines (51 loc) · 3.17 KB

2025-04-03.md

File metadata and controls

64 lines (51 loc) · 3.17 KB

areaDetector Collaboration Meeting (2025-04-03)

Attendance

  • Érico Nogueira Rolim (ENR)
  • Henrique Simoes (HS)
  • James Souter (JS)
  • Mark Rivers (MR)
  • Wang Xiaoqiang (WX)
  • James O'Hea (JO)
  • Gustavo Reis (GR)
  • Josh EC (JE)

Meta-issues

GitHub collaboration

  • Stagnating issue resolutions and PRs for drivers
  • Lack of community reviewing PRs, giving their opinions, willing to explore
  • Lack of multiple members who do general maintenance
  • Lack of standardization and specification of PV behavior and PV contracts (e.g. using Acquire_RBV or ADStatus to see if a detector is ready)

Collab Meeting setup

  • Work was only done synchronously (you can't get through a lot of items if people's first contact with them is during the meeting)
  • There was little assertive action after meeting discussions (e.g. merging or denying PRs, etc)
  • Few people had strong opinions about the discussed issues

Goals for Collab Meeting

  • Gather new people interested in helping keep the repository active
  • Find reviewers for stagnated PRs
  • Define standards for inclusion of new drivers
  • Define standards for review of current drivers
  • Define standards for review of Core code
  • Create community which monitors the repository, tries to help out where they can, and address long term issues

Suggestions

  • Always make PR for changes. They can even be merged by the author after 1w, for example, but it gives people the opportunity to interact with the development process, and this is a chance for them to become more involved.
  • Define Code Owners/Maintainers for drivers. This way, people know who to ping about issues/PRs. Also find a way to gather the user community of certain drivers: is that tech-talk, so every PR to a driver should have emails sent? Can we have some way to register users on github to send notifications to?
  • For those Maintainers, define a maximum response time (1 month?) for PRs/issues. If there aren't responses, maintainership of a driver should be rediscussed. Can a current maintainer take over? Can the new PR authors? What should be done?
  • Define when to make ADCore and areaDetector releases; is Mark interested in having other people do that?
  • Empower core developers to merge ADCore changes

Action points

  • Small documentation and typo changes don't need PRs, but code changes can have them
  • Open issues/PRs specifying PV behavior more explicitly
    • Acquire -> people should use the busy callback
    • "Detector is ready for triggers" -> ARMED PV? Acquire_RBV?
  • Send list of issues/PRs to tech-talk to bring interested people into meeting
  • Find owners (contact points) for drivers and define obsolete drivers
    • Diamond might take up ADAravis
    • Even so, merging PRs doesn't have to depend on the owner; code review can come from anyone, and the author has presumably tested it
  • Releases are made when someone needs a new feature or driver change, or when changes have accumulated
    • Update all drivers to master
    • Tag ADCore and top-level areaDetector simultaneously
  • Inclusion of new drivers
    • Include documentation
    • Code quality
    • Build out of the box if possible
    • Generality (can other people use it?)
  • Help required: fix ADCore CI