In-kind software development endorsement requirement

Hi @drphilmarshall just a quick question about endorsements. In conversations with the SSSC, it was stated that directable contributions do not need endorsement from a science collaboration. I and others have understood otherwise from the PCW presentations.

Can you clarify: do directable contributions need, or not need science collaboration endorsements?


Hi Wes,

SSSC have it right: directable software development contributions do NOT need endorsement from the recipients, in the way the Handbook requires it for non-directable contributions. However, proposal teams DO need to be working with their contributions’ intended recipients to make sure that the recipients can actually receive the contribution (ie a suitable working group exists and can support and “direct” the in-kind effort). You should seek assurance from the SSSC about this.

Excerpts from the Handbook and PCW slides below, for reference! To make this post more generally useful, I have also pasted in some illustrative examples of the different types of software development in-kind contribution that are proving helpful when supporting the in-kind proposal teams.

Best wishes,


PCW slide 16: “Directable” means the developer makes a work plan with the recipients, and works on what the group needs. “Non-directable” effort is potentially less valuable - so recipients need to endorse the work up front."

Handbook for Proposal Teams, Section 2.2.1: “Directable software development effort … assigned to some recipient [Science Collaboration or Rubin subsystem is intended to] be prioritized and planned via mutual agreement based on the needs of the recipients at the time the effort is being contributed and the effort and skill level offered by the contributors. … Non-directable software development effort … is specifically dedicated to some task(s) selected by the proposers, from amongst those software development tasks listed in the previous paragraph. … The basis for prioritization of these contributions is that the intended software or value-added catalog should be evaluated as high-priority infrastructure by the recipient. … Due to the need to assess value for specific deliverables anticipated by groups with non-directable effort, … proposing teams offering non-directable effort should request endorsement for their proposals before submitting them.”

Non-directable, directable, and general pooled software development examples:
To generalize, replace “galaxy cluster finder”, “DESC” etc with equivalent science infrastructure, science collaboration name, etc.

  1. Proposal Team X wants to develop their own galaxy cluster-finder and proposes to then share it with the DESC when they think it’s done, after carrying out the work within their own team. This is not a valid in-kind contribution, because the work is not embedded within a Science Collaboration or Rubin subsystem. All efforts must be embedded, i.e., the team providing the effort must be responsive to input from the recipient group on an ongoing basis.

  2. Proposal Team X wants to develop a galaxy cluster-finder according to their favorite algorithm, engaging at all stages with the DESC galaxy clusters working group – developing requirements, getting feedback on the code at regular intervals, etc. This would be a valid in-kind contribution, because the work is to be embedded within a recipient group. It’s non-directable because the group has chosen a specific activity that they want to carry out (the Handbook says that non-directable effort “is specifically dedicated to some task(s) selected by the proposers”). DESC would then have to decide whether or not to endorse it, based on the criteria outlined in the Handbook.

  3. Proposal Team X proposes to offer directable software development effort in the DESC galaxy clusters working group, based on their expertise in cluster-finding. This is a valid in-kind contribution. Suppose the DESC galaxy clusters WG does not think that producing a new cluster-finder is among the top development priorities to enable cluster cosmology at the time the contribution is to be provided. In that case, since the staff provided by Team X are directable, DESC can identify higher priorities for infrastructure development that are broadly beneficial and that draw on the group’s expertise in the field of cluster cosmology. This would result in development of a work plan as described in the Handbook (“efforts will be prioritized and planned via mutual agreement based on the needs of the recipients at the time the effort is being contributed and the effort and skill level offered by the contributors”). And the resulting product should, if all goes as planned, be of high value to the community.

  4. Proposal Team X proposes to offer general pooled software development effort, citing the general purpose coding skills and experience of their staff, and their broad ability to support scientific code production across a range of astronomical applications. This is a valid in-kind contribution, that is particularly highly valued. The Rubin International Program Coordinators, taking input from the CEC, would match each staff member from Team X with a suitable Rubin team or LSST Science Collaboration, according to needs. The Team X staff would then work with their recipient group to prioritize and plan their efforts via mutual agreement, just as for any directable software development contribution.

Fantastic. Muchas gracias.