Please add Hyperledger AnonCreds so that it shows up here: https://insights.lfx.linuxfoundation.org/projects/hyperledger-f/dashboard;quicktime=time_filter_3Y

Should have just the 3 repos initially.

Thanks!

Introduction/background material

In the first meeting of the 2023 TOC, one of the goals specified was to create documentation standards.

Task to be completed

The main goal of this task force is to document standards for new projects to use for creating their documentation.

List of deliverables or work products

• Common styling guide
• Recommended common publishing platform
• Document best practices for creating documentation, including information on tooling and the audiences
• Create a template repo that new projects can use for creating their documentation

Time to complete (no more than 6 months)

TBD

Leader

Bobbi Muscara

Initial participant list

• Venkatraman Ramakrishna (Rama)
• Tracy Kuhrt

Document the process for how someone would create a task force using information from the following decision log items:

• Task Force Launch
• Task Force Proposal
• Task Force Reporting
• Task Force Extension

Introduction/background material

At the January 19, 2023 TOC meeting, @lehors presented an overview of OpenSSF. One of the low hanging fruit that Hyperledger might implement to improve security is the use of SigStore for artifact signing.

Task to be completed

This task force will be focused on developing best practices and tooling for using SigStore for artifact signing.

List of deliverables or work products

• Best Practices for using SigStore for artifact signing consistently across Hyperledger projects

Time to complete (no more than 6 months)

TBD

Leader

Arun S M

Initial participant list

• Marcus Brandenburger
• Arnaud Le Hors
• Hart Montgomery
• Jim Zhang

With the new lifecycle simplification,

Projects that have been in the Dormant state for a period of 6 months will be automatically archived.

Transact was moved to a Dormant state on May 4, 2023 via #98

A task force has been formed to review and update the security process.

Eugene Yarmosh has requested the Avalon project be deprecated.

Approved by roll call vote 12 MAY 2022

The Cacti maintainers are proposing a state change from Incubation to Graduated.

There is a set of slides that @VRamakrishna is working on which will be part of our proposal for graduation.
Once the slides are available (and shared here) we'll request the TOC members to provide feedback on potentially missing/lacking aspects of the project so that we can address those prior to a vote which can hopefully happen during the TOC meeting of 2023 September 21, Thursday.
Any other feedback is also welcome in the meantime of course.

cc: @tkuhrt @arsulegai

Introduction/background material

In the first meeting of the 2023 TOC, @denyeart suggested we look at creating best practices for projects

Task to be completed

Document/Gather best practices for projects in a single location.

List of deliverables or work products

• gather list of current best practices
• determine gaps for other best practices that should be documented

Time to complete (no more than 6 months)

May 2023.

Leader

Dave Enyeart

Initial participant list

• Venkatraman Ramakrishna (Rama)
• Tracy Kuhrt
• Jim Zhang

Wiki page

Introduction/background material

The Security Task force provided recommendations to the 2022 TSC. One of those recommendations had to do with vulnerability disclosures.

Responsible vulnerability disclosure process does not exist. (Reference: https://github.com/ossf/wg-vulnerability-disclosures)

• Have project designated contact points as security mavens, helps in auditing.
• Audits serves as a way to prove that the project took right measures against a potential risk.
• CVEs will be published in open at the end of 90 days, unless requested for an extension explicitly.

During the discussions with the 2022 TSC, there was concern about mandating vulnerability
disclosure within 90 days.

Of note, Hyperledger documents a responsible disclosure policy in Security Team Policies as:

Responsible Disclosure

• 48 hours to respond to reporter acknowledging the report.
• 1 week to triage, report, and coordinate with the affected project maintainers to plan the fix of the bug.
• 90 days to fix and release a fix or disclose the security bug.
• Any "critical" errors shall be assigned a CVE number and disclosed through the formal CVE system.

Given this discrepancy in what is documented and what is understood, it seems that we need to revisit this to ensure that all Hyperledger projects understand their responsibilities when it comes to vulnerability disclosure and that we follow consistent practices across the different Hyperledger projects.

Other resources:

• Hyperledger's Security Defect Response Best Practice
• OpenSSF Vulnerability Guide
• OpenSSF Guidance for Security Researchers to Coordinate Vulnerability Disclosures with Open Source Software Projects

Task to be completed

Revisit the responsible disclosure documented policy and update the default template for vulnerability disclosure processes for Hyperledger projects to ensure visibility and consistency across Hyperledger projects.

List of deliverables or work products

• Default template for vulnerability disclosure processes for Hyperledger projects

Time to complete (no more than 6 months)

TBD

Leader

Arun S M

Initial participant list

• Venkatraman Ramakrishna (Rama)
• Arnaud Le Hors
• Hart Montgomery. I'd like to make this one a priority and can talk about it more. There are good opportunities for collaboration with the OpenSSF.

Introduction/background material:
Various government and public agencies have experimented with using Blockchain as part of their technology stack while conducting elections from a fair and transparent perspective. The idea behind this task force would be

• to collect the information already available in the public domain,
• reach out to various entities who have developed solutions or experimented with blockchain in this domain,
• share lessons learnt, benefits, issues, concerns and disadvantages,
• understand from others viewpoints (optionally mention them), share our point of view highlighting which parts of the process are Blockchain more suitable to;
• share which technologies can work together to help enhance the transparency and trust in the system.
• conclude.
• Optionally, as part of this we will also target to come up with a reference architecture for the same.

Task to be completed:

• Create a Whitepaper that highlights the current landscape of Blockchain in Elections and also discuss what the future holds for the technology in this domain.

List of deliverables or work products:
Whitepaper

Time to complete (no more than 6 months): 6 Months

Leader: Vikram Sharma

Initial participant list
Amol Kulkarni
Kamlesh Nagware
Aruna S M
Madhu Bhatia,
Rajesh Krishnan, Sr Architect, Dell
Sunil Kapadia
Samrat Kishor
Anant Avinashi
Ishan Roy, Head Tamil Nadu eGovernance
Sowjanya Segu,
Anil Dongre, Sr Architect, Persistent
Aniket Dhar,
Dhyan Appachu Bollachettira, Founder, Shambala
Pritam Singh
Ranjeet Singh
Shivendra Yadav
Ravi Shankar Gupta
Sandeep Srivastava

TSC Quarterly Project Updates are a way for the TSC to understand the state and community health of Hyperledger projects. The TSC Vice Chair reaches out to projects when they miss submitting their TSC Quarterly Project Update to remind the projects that they have a report due. The following are the reach out mechanisms that are used:

1. Directly reaching out to the last submitter of the project's quarterly update
2. Reaching out via the project's mailing list
3. Reaching out via the project's official chat channel

If the TSC Vice Chair is unable to reach someone in the project and an entire quarter has gone by since the report was due, then the TSC will discuss and determine if there should be a vote on moving that project to a Dormant state.

please see this

please see this

Introduction/background material

Today's Hyperledger Project Lifecycle, represents a lifecycle in which projects only move forward through the different stages. In past TOCs, we have talked about whether this should change and whether we should instead represent the state of a project with some form of badging to allow people to be able to quickly determine the health and status of a project. In addition, the Governing Board has requested that we take another look at how best to represent the current status of project's within Hyperledger. There are a couple of different options that this task force might consider:

1. Modify the current project lifecycle to have an annual review process to verify that a project's current status meets the criteria for its current state. This change may require renaming the "Graduated" state to reflect that this stage is not an achieved and done stage. This change may also require updating the lifecycle to ensure that each of the states and the criteria for each state is documented to ensure the annual review process can objectively determine the correct state based on the project status.
2. Look to implement objective badges for Hyperledger projects that can replace the current lifecycle that can be updated in during the quarterly reporting step so that people will understand the current project status.

Background Material:

• Hyperledger Project Lifecycle
• Previous Badging Proposal and Discussion
• Previously Proposed Badges
• LF Networking Project Lifecycle (contains an incubation reversal review)

Task to be completed

Determine how to update the project lifecycle and whether that will involve the introduction of badging.

List of deliverables or work products

• Updated project lifecycle
• Badges and badging process (optional)

Time to complete (no more than 6 months)

TBD

Leader

Rama

Initial participant list

Venkatraman Ramakrishna (Rama)
Bobbi Muscara

• See conversation with @vaporos on Discord
• Last commit September 12, 2022 by @ryjones
• Last commit by maintainers August 26, 2022 by @agunde406

cc: @hyperledger/grid-contributors

See hyperledger-archives/ursa#233

No major updates have occurred in almost 2 years. There are two major security vulnerabilities against ursa that the maintainers do not have to time to fix and the code is very outdated which is part of the time to fix.

The current maintainers recommend EOL for Ursa.

Approved by voice vote 02 JUN 2022

Approved by PR

Overview

This issue tracks the discussions and the work for project health indicator data.

As part of the TSC meeting on 1/6/2022, the policy around project quarterly reports was brought up. As part of the discussions, collecting data to accurately reflect a project's health came up.

A proposal to pre-populate the project quarterly report template with project health data was made. This will help project teams to not be stressed about filling out the reports because each report already comes with useful data. Equally important, this gives the TSC members a standard set of data dimensions to review in order to properly evaluate the health of each project.

Sources of Health Data

Currently, for Hyperledger project, the following sources of data are available:

• Linux Foundation Insights: a custom developed application maintained by LF. The app currently covers github based activities (commits, PRs, issues) and social engagements (rocket chat).
• Project github contributor reports: data pulled using github APIs assembled in report PDFs. Currently focused on contributor count and status: total, new, core/regular/casual, active/inactive, etc.

Future Requirements

What can be done to allow project health data to be accurately identified and properly captured?

Stable APIs

Insights currently doesn't offer stable APIs that can be used outside of the Insights' own dashboard UI. Having stable APIs would allow the information to be embedded in other places such as TSC wiki during review meetings.

It's important to capture point-in-time snapshots for the quarterly reports, or other places where such information is used, such as the Learning Materials Development Working Group.

This requirements for snapshots can be accomplished via one of the following ways:

• APIs to allow a date range to be specified and reliably produce the same results for the same range
• APIs to allow the data to rendered inside a report or image for the charts, and be downloaded as a pdf or image file

More data sources for Insights

Are there other data sources that can be useful to load into Insights?

Updated List (ver. 03/02/2022)

The following bullets capture the summary from the ongoing discussions.

• community
  • growth: both in terms of new interested individuals and conversion to contributor. data that reflects this dimension:
    • the number of contributors to the code base (github PRs)
    • the number of contributors to design discussions (discord)
    • the number of contributors to requirements (github issues)
  • diversity: no single organization keeps the project live. data that reflects this dimension:
    • the number of organizations contributing to the code base (github PRs)
  • retention: interesting/useful projects attract contributors, healthy projects retain them. data that reflects this dimension:
    • active contributor longevity (github PRs, discord)
  • maturity: I'm not able to properly articulate this one, maybe someone can help here?
  • responsiveness: how long until proposed changes (code, design, bug reports, etc.) are given attention? data that reflects this dimension:
    • time to resolve PRs and issues (github)
    • time to respond to questions (discord)
• code
  • usefulness: is the project being adopted by customers and tire kickers? data that reflects this dimension:
    • usage information provided by customers and developers
    • number of questions from clients trying to use the code
    • docker pulls
    • release binary downloads
    • tagged online resources: case studies, presentations, mentorship programs
  • production-readiness: is the current code base coherent enough to be usable in a real-world scenario? data that reflects this dimension:
    • release number (latest is 1.0.0 or later?)
    • test coverage
    • performance and reliability testing data
    • user documentation

@compleatang has stated Monax can provide no further development effort for Burrow

Background:
One thing that could possibly benefit the TSC (and Hyperledger as a whole) is more awareness of and interaction with different projects. This could spur more cross-project collaboration, less fragmentation between projects, and, in general, more project happiness with the TSC.

Proposal:
The TSC collectively requests that each TSC member attend one project meeting a month for a project with which they are unaffiliated and have not been a contributor (and, ideally, one that they have not attended before). Whether people want to introduce themselves and participate or just listen wouldn't matter too much: just attendance would be great.

On the TSC wiki, a page will be created to keep track of meeting attendance in some kind of spreadsheet (either public, if people are OK with it, or private to the TSC) with the main purpose being that TSC members know which meetings other members have attended so that TSC members can stagger their attendance across many project meetings. This is because this initiative will be much more effective if TSC members attend many different meetings rather than all attending, say, a meeting of what is perceived to be a currently popular project.

We also propose to include SIGs and working groups as possible options for TSC members to attend. Finally, if non-TSC maintainers wish to be included, we propose to include them as well.

The time commitment--one meeting a month--should be pretty small, and the hope is that going to these meetings would be very informative for TSC members, and an opportunity for projects who aren't strongly connected to the TSC to ask questions about HL as a whole if they want.

We also propose that TSC members be invited (but not required) to report back during TSC meetings about anything they found interesting, noteworthy, or that needs addressing in some sort of brief discussion. We also suggest that TSC members that adhere to this schedule be rewarded with food and/or drink by the HL staff at the next in-person event.

See https://wiki.hyperledger.org/display/TF/Hyperledger%27s+Transition+to+Discord+Proposal

The FireFly Community would like to propose moving from Incubating Project status to Graduated Project status. I will open a PR against https://github.com/hyperledger/hyperledger-hip with the details of our proposal, and I will link it back to this issue. I am happy to discuss any questions or feedback that the TOC has on that PR, or to chat about it on a call if desired.

If possible, we would love to discuss this topic and hold a vote at the next TOC meeting on 2023-09-21. We are working toward having maintainers from each of the different companies represented in the project present for discussion that day.

Thanks!

Nicko

Introduction/background material

In the first meeting of the 2023 TOC, @swcurran suggested we look at creating best practices for automated pipelines

Task to be completed

Document the best practices for how to produce and publish artifacts

List of deliverables or work products

• Best practices for automated pipeline

Time to complete (no more than 6 months)

TBD

Leader

@petermetz

Initial participant list

• Marcus Brandenburger
• Dave Enyeart
• Timo Glastra

Detailed proposal can be found here https://wiki.hyperledger.org/display/TSC/DCI+Working+Group%3A+Inclusive+Naming+Proposal

The scope of this discussion is captured at cncf/foundation#617.

The issue at hand pertains to discussing whether there is an impact on the Hyperledger Foundation. Many of the projects under the Hyperledger Foundation have the aforementioned dependencies. These projects will be affected by this license change, with the impact extending to the production of build artifacts. Determining whether these builds would be utilized for production deployments poses a challenge. It is not in the best interest of the TOC/Hyperledger Foundation to require users to purchase a commercial license for the utilization of these build artifacts.

Introduction/background material

With the most recent update to the Hyperledger Charter, "Supported Projects" were introduced.

The scope of the Hyperledger Foundation includes supporting various open technical projects (including open source software, open standards / specifications, open data and other open projects, collectively, “Technical Projects”).Technical Projects can either be overseen by (i) the Technical Oversight Committee of the Hyperledger Foundation (such Technical Projects, “TOC Projects”), or (ii) separate technical oversight pursuant to a technical charter specific to such Technical Project (such Technical Projects, “Supported Projects”).

As such, the TOC needs to better understand the impact to the TOC Governing Documents, specifically, the project proposal process, project lifecycle, and any other places where "Supported Projects" might need to be reflected.

Task to be completed

Update Hyperledger governing documents and other places that need to handle "Supported Projects".

List of deliverables or work products

• Determine list of places that need to be updated to handle "Supported Projects"
• Update each place identified above

Time to complete (no more than 6 months)

TBD

Leader

TBD

Initial participant list

• Tracy Kuhrt

Move project reports to GitHub

Why?

Transparency

1. It is trivial for someone to mark a report as reviewed by a member of the TOC. Using GitHub, only someone that controls a specific account can vote as that account.
2. The history of a project can be reviewed using standard tools like git-blame

Durability

1. If someone edits a report in the wiki after approval, it is difficult to notice.
2. Important artifacts for the history of Hyperledger have been lost, due to being kept in Google Docs or similar. The original proposal documents for Hyperledger Sawtooth, for instance, are lost.

Process Proposed

1. A template will be created for filing a PR
2. Once a quarter, projects will use this template to file a PR
3. Once approved by TOC, PR will be merged
4. Once merged, website will be updated (much like merging a PR in Labs updates the Hyperledger Labs website)

Introduction/background material

When new people join the Hyperledger community, it can sometimes be hard to know where and how to participate and become active. Hyperledger has a few resources to attempt to help people know where they might provide their energies, including:

• https://www.hyperledger.org/participate
• https://www.hyperledger.org/use
• https://start-here.hyperledger.org/
• Each project's CONTRIBUTING.md

However, we still hear from people that they do not know how to get involved.

Task to be completed

This task force will focus on a set of specific audiences and develop onboarding content for each of them.

List of deliverables or work products

Create onboarding content for

• SIG Chairs
• SIG Members
• TOC members
• Maintainers
• Developers/Users
• Contributors
• Citizens (community members)

Time to complete (no more than 6 months)

TBD

Leader

Bobbi Muscara

Initial participant list

• Tracy Kuhrt
• Bobbi Muscara
• Niku Singh

Why

As we are moving project reports and other items from the Wiki, we should consider whether it makes sense to have all TOC operations in the same location. This will ensure that the meeting minutes are not lost if we migrate from Confluence in the future.

Proposed Process

1. Hyperledger TOC chair (or vice-chair) will create a pull request to https://github.com/hyperledger/toc to create a file with the meeting agenda in a meetings/YYYY folder. (NOTE: a template will be created to make this easier).
2. During the TOC meeting, the PR will be modified to include the attendees.
3. After the TOC meeting, the PR will be modified to add the recording.
4. The PR will then go through the process of getting two approvals and being merged.

There is a broken link in this mentorship page :

Broken Link

Discussions:

• Discussion on 16 JUN with notes
  • Presentation
• Discussed on 23 JUN as well
  • Proposal for comment

If a project does not have a retirement policy, a default policy of from three to six months of inactivity will result in moving a maintainer to emeritus status

The Hyperledger Transact codebase is now maintained as part of Hyperledger Sawtooth's lib repository which you can find here: https://github.com/hyperledger/sawtooth-lib. As such, the maintainer's have requested that the project be moved to a Dormant state while the transition occurs and eventually be moved to EOL state.