| 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 <2025> | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 <2025> |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: AreaDetector Monthly Collaboration Meetings and project owners |
| From: | Érico Nogueira Rolim via Tech-talk <tech-talk at aps.anl.gov> |
| To: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
| Date: | Mon, 5 May 2025 18:54:13 +0000 |
Hi folks,
Following up on this email about the AreaDetector Monthly Collaboration Meetings, I have sent the people on Bcc (using Bcc due to tech-talk rules) an invite, and a link to the Teams meeting is available below as well. I scheduled the meeting for next Thursday. I realize that doesn't give a lot of time for people to plan their schedule. If Thursday (April 17th) on the week after the EPICS Collab Meeting would be better for anyone, please let me know!
We have put together a list of meta-issues we would like to discuss in the meeting. For now, we won't be discussing specific issues or PRs in AD repositories.
Issues with current 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)
Issues with the 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
As part of solving these issues, these are some of our goals for the 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
For this, we have some concrete 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
In order to discuss this before the synchronous meeting, we have also created an AreaDetector channel in EPICS Chat: https://epics-controls.org/epics-chat/
Cheers,Érico
On 07/03/2025 11:45, Érico Nogueira Rolim wrote:
Hi folks!
Last year, Emilio, who used to work at Diamond, started organizing monthly meetings to collaborate on areaDetector repositories. Unfortunately, as mentioned, he's no longer at Diamond, and is no longer able to coordinate these meetings. Henrique Simões and I, Érico Nogueira, from SIRIUS/LNLS, would like to take over this coordination, while also suggesting a different format.
In order to make better use of our time during the 1h long meetings, and to continuously bring in new people, 1 week before the meeting we would send an email to tech-talk and to participants with a suggested agenda. This agenda would consist of automatically selected issues and PRs from GitHub, and any other relevant action points. This way, participants can take a look at the links, and possibly answer/review them before the meeting, and non-participants will be aware of what's happening in meetings, and can chime in for subjects within their expertise. Additions to the agenda can happen through tech-talk as well.
For the automatic selection of issues and PRs, we would keep using the existing script which selects the most recent ones, and would like to extend it to generate a list of the least recent ones; this would allow us to take a look at ancient issues and PRs each meeting, and act on those (easy merges, invalid issues, etc.).
We would also like to have a first (or one of the first) meetings dedicated to setting up guidelines for maintainership of AreaDetector. This would have to involve Mark Rivers directly, in order to define guidelines for merging PRs to drivers and core repositories (how much testing is necessary; what to do about detectors no participant has experience with; recurring contributors), documentation changes, releases, inclusion of new drivers and plugins, and more.
At the moment, we would consider keeping the previously selected date and time: first Thursday of each month, at 15:00 UTC.
We are open to suggestions, and look forward to hearing from you and reengaging this effort!
Cheers,Érico
Aviso Legal: Esta mensagem e seus anexos podem conter informações confidenciais e/ou de uso restrito. Observe atentamente seu conteúdo e considere eventual consulta ao remetente antes de copiá-la, divulgá-la ou distribuí-la. Se você recebeu esta mensagem por engano, por favor avise o remetente e apague-a imediatamente.
Disclaimer: This email and its attachments may contain confidential and/or privileged information. Observe its content carefully and consider possible querying to the sender before copying, disclosing or distributing it. If you have received this email by mistake, please notify the sender and delete it immediately.