2022-05-24

  • Criteria for project families discussion:
    • Reviewed the criteria in Hyperledger Project Families
      • 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".

2022-03-31

Agenda

  • Agree on tasks to be completed
  • Agree on deliverables list
  • Begin reviewing proposed mockups

Notes

  • No changes to the tasks to be completed
  • No changes to the deliverables list
  • Strawman Proposal
    • 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.
  • Next steps:
    • Update the Project Families Document - All
    • Develop a list of personas and their wants - All
    • Create a list of functional groups that multiple projects fit into for use with the #tag_name functionality in the mockup Jim Zhang
  • No labels

1 Comment

  1. The following tags / functional group names can be used to label each of the projects in the high level list to allow fast browsing and quick understanding of what each project does.

    Idea is taken from the Cloud Native Computation Foundation website:


    Proposed:

    Functional Group / TagProjects
    General-Purpose DLTBesu, Fabric, Iroha, Sawtooth
    Verifiable Data Registry DLTIndy
    Verifiable Credentials, Decentralized IDAries, Indy
    Deployment AutomationBevel
    Cross-chain InterOpCactus, FireFly
    Performance BenchmarkingCaliper
    Deployment AutomationCello
    DLT DashboardExplorer
    Connectivity GatewayFireFly
    Industry-Specific (supply chain)Grid
    DLT Building Blocks (transaction lifecycle)Transact
    Common Crypto LibraryUrsa