2022-08-12
Users Committee Meeting Minutes
UC Attendance: Michael Wood-Vasey, Matthew Holman, Igor Andreoni, Javier Sánchez, Matt Wiesner, Alejandra Muñoz Arancibia, Markus Rabus, Alessandra Corsi, Ashley Villar*, Qingling Ni*, Cia (?), Dominique Boutigny [* indicates virtual attendance]
Rubin Staff Attendance: Melissa Graham, Greg Madejski, Bob Blum
Shared notes taken during the meeting
Melissa started with the overview of the meeting goals and the charge of the Users Committee (UC). The UC is charged with soliciting feedback from the LSST scientific community or ‘users.’ The UC is one of the conduits for informing the Rubin Staff of the concerns of the general community.
Introductions of the members: Matt Holman, Dominique Boutigny, Alejandra Muñoz Arancibia, Matt Weisner, Igor Andreoni, Michael Wood-Vasey, Alessandra Corsi*, Ashley Villar*, Javier Sanchez, Qingling Ni*
Matt H.: We are grateful to the CET for their support in organizing this meeting and for the tutorial notebooks that have facilitated our getting involved with the Rubin Science Platform and data previews. Are there any questions from the audience?
Bob Blum: Could you review the charge of the UC?
Matt H: We are charged with soliciting feedback from the user community (anyone interacting with the data). We are also asked to get involved with the data themselves, to provide formal findings, and to prioritize the users’ needs, and to provide the channel of communication to the CET and Rubin in general. We comment on the users’ experience, seek feedback.
Bob Blum: You can think of the UC as high-level users who can communicate with the Rubin leadership what the highest level needs are.
Dominique: What is the scope of the UC?
Melissa and Bob: The scope is somewhat limited, e.g. not intended for providing the feedback on say survey strategy, commissioning activities, (but the Rubin Staff should be open to any comments!). The connection between the community engagement team and the users committee is to stand the committee, and provide the conduit from users upwards. This will be about the data products and Rubin Science Platform primarily. Also the UC will be more focused on making sure Data Preview 1 is really useful for the community.
Online: What connection between the UC and the Community Engagement Team (CET). CET facilitates the UC and is in charge of user acceptance of the data.
Matt W: Will we also coordinate with the general public?
Melissa: That is an outreach activity. However, possibly yes, to bring advanced amateurs into the fold of the scientific community. Data rights? Mainly for professional astronomers (associated with professional institutions), probably not necessarily the general public. The boundary is a bit fuzzy (e.g. small private observatories, …). Clarification of data rights might be needed. The Rubin data policy says employed at an institution (or enrolled student at an institution) in astronomy.
Mario Juric: How is a professional astronomer defined? There are also computer scientists that would be included in this group.
Phil Marshall: There is an example of an astronomy grad student, now working in the industry, who wants to continue being engaged. This is probably OK. Subtle thing is data rights, how to manage the proprietary data rights.
Michael Strauss: Is the only reason for the data policy the resources involved?
Bob Blum: That’s a big part, but also how to manage the proprietary nature of the data.
Will Clarkson: Definition might be clarified to include astronomy teachers at under-represented institutions, possibly professionals at some companies, serious contributors to citizen science …
Mario Juric: It would be useful to have all this information, regarding data rights, written down for reference and to communicate to the community.
Bob Blum: We will make sure we clarify it.
Melissa: (from bluejeans, SAC member comment) the definition of who is a user is also important to the SAC.
Alejandra: Would like to stress the importance of students in machine learning and computer science areas as Rubin users, their research with e.g. time domain data could help improve our algorithms and user experience.
Bob Blum: envisions a small subset of data specifically designed for citizen science efforts/programs. Data Rights Policy includes an avenue for data rights holders to work with a non-holders on a potential joint project.
One reason to be restrictive in the list of scientists with data rights, e.g., to astronomers and physicists at academic institutions, is to have a known community where and norms about restricting the data rights restrictions. This is not a driving factor, but it is a consideration.
After 2 years of an internal data release all data will be publicly available, but there is no final plan as to how to make such data available. The Canadian group might provide such means, not decided as yet. Question as to the interaction / relationship with Brokers - needs to be clarified, possibly via written agreements. Need to hear about any insufficient performance of Brokers: this is definitely within the scope of the Committee activities.
Alejandra: In the future it could be useful to have a starting point within the Science Platform to connect with the brokers in a more or less unified way (think of astroquery for catalogs), as they may serve as a guide to the users for what objects to inspect in the Platform.
Action on the CET: clarify the data right policies etc.
Gautham Narayan: Brokers are aware of community engagement. As part of the ELAsTiCC effort we’ll invite all of them to present to the Science Collaborations how to use each of the brokers. They can also learn how to use the ELAsTiCC data itself as a test sample. Brokers need to provide a means for the community to hear about the process (in the form of a meeting, survey, something along those lines).
Matt H: There was homework for the Users’ Committee: start with soliciting the comments from the Committee regarding the tutorials. Igor: grateful for the quality tutorials / notebooks. First: is the information easy to find? Generally yes. Asked for a link from the RSP to the tutorials. High marks on the quality of the experience of notebooks,would like to have the response faster. Data Previews don’t have a means to have the users develop experience with alerts - but not completely clear how to implement it. Means of exporting plots from the Portal to papers? Can those be directly exported? Gregory D.-F.: Feedback incredibly valuable, grateful for any suggestions.
Alessandra Corsi: notebooks very impactful especially for users at small institutions. Gregory: plan for adding functionality etc. Plan to make means to analyze data in bulk. The DM team uses the RSP internally, so its functionality is continually expanded.
Igor: Feedback on TAP services. Thank you for the high-quality work put on these services and the notebooks/tutorials. Minor improvements could be:
Add a link to the tutorial from the Rubin Science Platform page
Keep the expected query times up to date (now they typically take 1-2 minutes in most cases, but few seconds are indicated as expected time)
More in general, mock-up alerts should be included as part of DP0 for users’ to look at the content and prepare for custom filtering [see below as well]
Visualization is already excellent both in the notebooks and in the portal. Down the road, it is reasonable to think that some users will want to include plots generated via the portal in their papers. I would recommend writing explicitly in the portal if it is fine to put them in publications. If so, it would be useful to make sure that plots are paper-ready according to usual journal format requirements (possibly coordinating with the editors of popular journals directly?).
Alejandra: I would suggest adding a notebook/tutorial focused only on an alert, its content, and how different alerts connect to build the table data. Even when there are no alerts explicitly in the Platform, such a notebook will help users that have not had experience with other alert streams yet to have a sense of what information is contained.
Gregory: it might be possible to create a notebook with a mock-up alert (those do not exist in DP0.2 now).
Matt H.: other suggestions to include in the tutorials / notebooks?
Matt W.: Any limitations on space constraints for images? But it is important to appreciate the limits of very large downloads.
Bob Blum: We are very open to suggestions with regard to data visualizations. Gregory: it is possible to upload the external images to the Portal. For now, DP0 is a simulated data set so comparing against real data is not obvious.
Phil M.: Any emergent power users form the Delegates, getting to stress the system? Melissa: probably not yet.