Changes to the affiliation policy

projects/affiliated.md

@@ -12,7 +12,9 @@ Here we describe how we can help projects gain greater visibility and enhance th
 
 *HSF Affiliated Projects and Software* are community-driven and community-oriented "endeavours" or "products" of wide and recognised interest and applicability beyond a single collaboration or experiment.
 
-*HSF Affiliated Projects and Software* are community projects or software packages with person-power, and possibly dedicated funding, which connect strongly to the HSF and align with [its goals]({{ site.baseurl }}/organization/goals.html). They benefit from their inclusion in, or association with, the HSF through access to the community for wide visibility and easier promotion through the network. Affiliation makes it clear that the HSF has no direct control over the endeavours/products, hence no responsibility for evolution or maintenance.
+*HSF Affiliated Projects and Software* are community projects or software packages with person-power, and possibly dedicated funding, which connect strongly to the HSF and align with [its goals]({{ site.baseurl }}/organization/goals.html). They benefit from their inclusion in, or association with, the HSF through access to the community for wide visibility and easier promotion through the network. 
+Affiliation makes it clear that the HSF has no direct control over the endeavours/products, hence no responsibility for evolution or maintenance. 
+Affiliated projects also align with several of the software-related recommendations from the [ICFA](https://icfa.hep.net/) (International Committee for Future Accelerators) data lifecycle panel (link to [mission](https://icfa.hep.net/icfa-panel-on-the-data-lifecycle/), [mandate](https://icfa.hep.net/wp-content/uploads/Mandate.DataLifecyclePanelFinal.pdf), [recommendations](https://arxiv.org/abs/2508.18892) and [app](https://icfa-data-best-practices-demo.app.cern.ch/). For a short summary of the ICFA data lifecycle panel, its goals and its connection with HSF, follow [this link]({{ site.baseurl }}/projects/hsf_everse_icfa.html).   
 
 Projects are hosted on their own public platform of choice (such as GitHub);
 they may use the [HSF GitHub repository](https://github.com/HSF) if desired and mutually agreed with the HSF Steering Group.

projects/guidelines.md

@@ -1,6 +1,6 @@
 ---
 title: "Affiliated Projects and Software Guidelines"
-author: Eduardo Rodrigues, Pere Mato, Graeme Stewart
+author: Eduardo Rodrigues, Pere Mato, Graeme Stewart, Caterina Doglioni, Stefan Roiser
 layout: plain
 ---
 
@@ -17,15 +17,14 @@ The guidelines have been created to:
 * Help new projects discover what those practices are; and
 * Help users know which projects are following best practices, meant as a guarantee of quality.
 
-The guidelines can be updated in light of updates or release of community practices, such as those emerging from e.g. the [EVERSE project](https://everse.software).
+The guidelines can be updated in light of updates or release of community practices, such as those emerging from e.g. the [EVERSE project](https://everse.software). For a short summary of the EVERSE project and its goals, follow [this link]({{ site.baseurl }}/projects/everse.html).   
 
 The guidelines take inspiration from an [older HSF project page]( {{
 site.baseurl}}/project_guidelines.html) and from the [Open Source Security
 Foundation (OpenSSF)’s page](https://www.bestpractices.dev/en/criteria).
 
-There are minimum standards that are required to be an affiliate, but beyond
-that we encourage all projects to look at the criteria set out below and work
-towards improvements.
+Affiliated projects must satisfy minimum standards. 
+We also set out further recommendations for community software that projects can work towards. 
 
 ## Best-practice Guidelines
 
@@ -78,25 +77,30 @@ Compliance with respect to the guidelines is provided via a "repo review” fram
 ([GitHub repository](https://github.com/scientific-python/repo-review)).
 The review can even be done [directly in a browser](https://learn.scientific-python.org/development/guides/repo-review/) for repositories hosted on GitHub!
 
-## Differentiated Software Best Practices
+## Software Tiers and Differentiated Recommendations
 
-Recognising that not all software is the same is very important to ensure that
-appropriate guidelines are applied. Here we adopt roughly the [*three levels of
+Not all software is the same, in terms of purposes and audience. 
+To classify software, we adopt a scheme inspired by the [*three levels of
 software*](https://everse.software/RSQKit/three_tier_view), originally developed by the
 [Australian Research Data Commons](https://ardc.edu.au/) (ARDC)
-and subsequently adopted by the [EVERSE Project](https://everse.software).
+and subsequently adopted by the [EVERSE Project](https://everse.software). 
+The starting point for the following definitions is the [RSQKit *three levels of software* page](https://everse.software/RSQKit/three_tier_view). 
 
-From these levels we have developed guidelines that projects can examine to
-understand typical levels of maturity, developer support, community support and
-engagement.
+**Research software infrastructure** include software that captures broadly accepted ideas, methods and models for use in research, often warranting close involvement of researchers in its development. This kind of software is broadly applicable, but it does not necessarily mean that its codebase will be large. A research software classed as infrastructure could be a comprehensive toolkit meeting a research need, but it could also be a smaller focused software package that is essential for several research communities. In the case of research software infrastructure, the maturity of the codebase, developer support, community support and engagement warrant specific recommendations.
+
+**Research software tools** (also called _prototype tools_) are research software that demonstrates a new idea, method or model for use beyond the project in which it originated, often as a substantive intellectual contribution or a proof of concept. These software tools are designed to answer multiple research questions and are typically developed and used by more than one person. They often began as a collection of analysis scripts before evolving into more comprehensive tools.
+
+**Analysis software** is research software that captures computational research processes and methodology, often used in simulation, data generation, preparation, analysis and visualisation. It typically represents software created for personal use with a small scope, such as scripts quickly put together to analyse data.
+
+We expect software developers seeking affiliation to identify the category their software fits in, which will be listed at the beginning of the review document, and consider the differential guidelines below as best-practice basis for supporting users effectively.
 
 These guidelines lie in three major categories:
 
 * Software engineering practices followed by the project (as described in the Best-practice Guideline section and with specifics for the programming language ecosystem).
-* Sustainability and support structures of the project (e.g. number of active developers, discussion fora, documentation, training events, time to respond to issues, etc.)
+* Sustainability and support structures of the project (e.g. discussion fora, documentation, training events, time to respond to issues, etc.)
 * Level of adoption of the software by experiments and other projects, hence the impact of the project.
 
-### Tier 3 Software
+### Analysis software
 
 A.k.a. *analysis code* in the 3-tier model.
 
@@ -134,8 +138,7 @@ obtain, provide feedback (as bug reports or enhancements), and contribute to the
 
 #### Sustainability
 
-* The project should be maintained.
-* The project should have at least one long-term maintainer with a future commitment to the software of at least 1 year.
+* The project should be maintained by at least one long-term maintainer, preferably with a future commitment to the software of at least 1 year (subject to funding).
 * The project should provide a process for users to submit bug reports (e.g., using an issue tracker or a mailing list).
 * The project should use an issue tracker for tracking individual issues.
 * The project should acknowledge a majority of bug reports submitted in the last 2-12 months (inclusive); the response need not include a fix.
@@ -147,7 +150,7 @@ obtain, provide feedback (as bug reports or enhancements), and contribute to the
 * The software produced by the project should be of interest for the HEP experiments.
 * The software should be adopted by at least one experiment/collaboration/project.
 
-### Tier 2
+### Research software tools
 
 A.k.a. *prototype tools* in the 3-tier model.
 
@@ -172,8 +175,8 @@ for Tier 3 should be fulfilled, with the addition of the following criteria.
 
 #### Sustainability
 
-* The project should be maintained and produce at least one new release a year if there are changes and fixes that have been accumulated.
-* The project should have at least one long-term maintainer with a future commitment to the software of at least 2 years.
+* The project should be maintained by at least one long-term maintainer, preferably with a future commitment to the software of at least 1 year (subject to funding).
+* The project should produce at least one new release a year if there are changes and fixes that have been accumulated.
 * The project should use an issue tracker for tracking individual issues.
 * The project should acknowledge a majority of bug reports submitted in the last 1-3 months (inclusive); the response need not include a fix.
 * The project should respond to a majority (>50%) of enhancement requests in the last 1-3 months (inclusive).
@@ -182,7 +185,7 @@ for Tier 3 should be fulfilled, with the addition of the following criteria.
 
 * The software should be adopted by at least 2 experiments/collaborations/projects.
 
-### Tier 1
+### Research Software Infrastructure
 
 A.k.a. *research software infrastructure* in the 3-tier model.
 
@@ -199,7 +202,7 @@ criteria.
 #### Sustainability
 
 * The project should be actively maintained and produce at least one new release a year if there are changes, and produce patch releases as relevant to include fixes that have been accumulated.
-* The project should have at least 3 long-term maintainers with a future commitment to the software of at least 2 years.
+* The project should be maintained by more than one long-term maintainer, preferably with a future commitment to the software of at least 1 year (subject to funding).
 * The project should acknowledge a majority of bug reports submitted in the last 1-4 weeks (inclusive); the response need not include a fix.
 * The project should respond to a majority (>50%) of enhancement requests in the last 1-4 weeks (inclusive).
 

projects/hsf_everse_icfa.md

@@ -0,0 +1,36 @@
+---
+title: "HSF, EVERSE and the ICFA lifecycle panel"
+author: Caterina Doglioni, Stefan Roiser, Michael Sparks
+layout: plain
+---
+
+## The EVERSE project
+
+[EVERSE](https://everse.software) is a EU-funded project (GA 101129744, HORIZON-INFRA-2023-EOSC-01-02) aiming to create a framework for research software and code excellence, collaboratively designed and championed by the research communities, in pursuit of building a European network of Research Software Quality and setting the foundations of a future Virtual Institute for Research Software Excellence.
+
+EVERSE has the following objectives:
+   * Build a collaborative, community-led structure for evaluating, verifying, and improving the quality of research software and code, by actively involving researchers, software developers, and other stakeholders in the research community.
+   * Leverage existing tools and resources to support the evaluation, verification and improvement of research software and code quality, based on existing practices and standards across research communities represented by the five [EOSC](https://eosc.eu/eosc-about) (European Open Science Cloud) Science Clusters. [ESCAPE](https://projectescape.eu/) is the cluster for Physics & Astronomy, including the HL-LHC ESFRI among others.
+   * Establish a sustainable and collaborative ecosystem of stakeholders across the research communities associated with the five EOSC Science Clusters to ensure research software and code quality assurance and support the advancement of reliable and reproducible research.
+   * Provide a framework that will ensure appropriate recognition, reward, and career development for researchers and Research Software Engineers (RSEs) who implement research software and code quality assurance practices and policies.
+
+In order to validate the structure for the evaluation, verification and improvement of European research software, EVERSE collects and aggregates well established practices on software engineering processes and training from the various science domains as a starting point, through interacting with selected, established software packages that are widely used within the European EOSC-Future Science Clusters. Based on these experiences, a software assessment process based on metrics and tools is established and then also adapted to the needs of the science clusters. The HSF is proving to be one of the driving entities in this feedback loop. 
+
+## The ICFA Data lifecycle panel
+
+The [ICFA](https://icfa.hep.net/) Panel on the Data Lifecycle is an international group of researchers under the International Committee for Future Accelerators with a mandate to review recommendations around everything concerning data in particle physics, ranging from raw acquisition and reconstruction, through analysis and simulation, and all the way to long-term data and analysis preservation. 
+Its mission covers software, workflows, computing, and networking alongside the more traditional data management concerns, with a focus on open science and FAIR (Findability, Accessibility, Interoperability, Reusability) practices (defined in [this publication](https://www.nature.com/articles/sdata201618)). 
+
+In practical terms, the panel aims to produce practical recommendations and serve as a point of contact for practical issues in addition to helping ICFA formulate policies. The panel also explicitly works to improve recognition of the nature and value of work on the data lifecycle in researchers' CVs and support career development, acknowledging that software and computing contributions have historically been undervalued in the field.
+
+## Connection with the HSF 
+
+The common thread of ICFA, EVERSE and the HSF is that software quality is a crucial aspect for data-intensive research. 
+
+Software quality is necessary for _community-driven and community-oriented software endeavours or products of wide and recognised interest and applicability beyond a single collaboration or experiment_ that are promoted by the HSF affiliated project guidelines. 
+
+The HSF, EVERSE and the Data Lifecycle Panel compile best practices, guidelines and recommendations concerning software quality with different goals: 
+
+   * The HEP Software Foundation supports and promotes community software that fulfills software quality guidelines through badges that can be added to GitHub pages;
+   * EVERSE provides the scientific communities of the European Science Clusters with good practice tasks through the RSQKit, and is working towards metrics and tools;
+   * The Data Lifecycle Panel includes sections on License, community-wide software development and Collaboration-specific software development in its Recommendations for best practices for open science.