A diverse set of contributors and maintainers, ideally codified in some formula, but also up to the discretion of the governing board (or maybe TSC, but please don’t make us decide this). → For this item, we had the following discussion: diversity can be increased by decreasing contributions from a single organization or by people leaving an organization and going to work for another. Active maintainers (considered someone who has reviewed or contributed code or answered PRs or issued releases consistently for 6 months) must exist from a minimum of 3 organizations consistent with the default maintainer policy. Does a single organization have control over a project that would stop things from happening (e.g., adding a feature that is desired by the community or doing a release). Magic number of organizations is 3, as it still allows for changes to be put in.
Sufficient and sufficiently stable releases, and long-term support. → For this item, we wanted to define what "Sufficient" means and to be able to ensure that we do not stop Hyperledger Besu that cannot commit to LTS releases due to changes on the Ethereum mainnet that would prevent this. We ended up with "Regular releases and long-term support excluding security changes that break backward compatibility." Then we started to ask some questions: How do we check this on an ongoing basis? Do we update the website if some project stops having LTS? This discussion went to project badging and project health task force and whether these should be the criteria for determining which projects get priority on the website. Hart did comment via the document after the meeting that "We could check on this potentially with the quarterly reports, or badging as you suggest.", which Peter had also suggested. In addition, Hart commented via the document "I think we do update the website if a project stops having LTS."
Documentation and learning materials that meet some minimum standard. → Did not discuss
Participation in Hyperledger events and marketing campaigns. A lack of participation or an inability of the LF staff to get enough contributions to marketing campaigns could be cause for loss of project families status. → Did not discuss
As a next step, the task force believes that task surrounding "Determine criteria for projects to meet to obtain priority for Hyperledger Foundation marketing" might be better brought into the discussion of project health task force and/or revisiting the badging criteria. Specifically, we believe that the website and marketing decisions should be an ongoing and will be dynamic in nature based on the projects that are being incubated and the health of the projects. As such, we think that it might be beneficial to see if future discussions can close on the website revamp for grouping of projects (i.e., the first task defined "Determine how we will group projects on the Hyperledger website".
Besides the Project Overview page, there will be a Getting Started page. This page could be structured differently than what we have seen in the past. "I want to ..."
The Hyperledger Foundation marketing group is working on integrating the Drift app to allow for people to have a conversation about what they are looking for in order to focus their attention on certain web pages.
Like the graduated projects, the incubated projects should also have text and not just icons. This will ensure that we can help all projects become successful.
Personas of people coming to Hyperledger are changing, and we need to look at higher level questions, like "How do I build a token?", "How do I create a CBDC?", "How do I create an NFT marketplace?", "What would I use to develop my supply chain application?", "How do I build an identity application?"
A user coming into the site is only going to be interested in projects that they can build their product on. They will not be interested in labs.