Gianluca Capuzzi

I'm an italian Software Enginner with 10+ years of Industry experience. Below my skills:

C++ on Linux Operating System
Python applied to Machine Learning
Responsive web: HTML, CSS, Javascript
Web framework: React.js, Node.js
Network Security background
project leading using agile methodologies (kanban, lean software development)

I have a PhD in Artificial Intelligence.

Blockchain courses:

MIT: Blockchain Course
Udemy: programming smart contract on Ethereum Blockchain

I also wrote a white paper on NFT case study:

https://github.com/gcapuzzi/open-whitepaper

Interests:

Chair Github or Template.

Availability:

Contribution to Hyperledger Standard Documentation and/or Chair of one of available bucket.

I have much time this summer (about 20h per week), and I'll try to apply also for Hyperledger CLP.

Attended calls:

13 June 2023

CA SIG: I'll contact later by email and they send me support requests in standard documentation.

Aries: they ask a list of contributors specifying skills and background.

Below an outline of the Standard Documentation Guidelines:

Preface

Introduction

Type of users
- List of types: standard user, administration user, smart contract developer, code contributor developer
- Standard user: uses hyperledger tools to mint tokens, to transfer funds, is able to use existing smart contracts
- Administration user: could be a blockchain architect or a blockchain administrator
- Architect: design and install the blockchain
- Administrator: add new users, add new features, change configuration
- Smart contract developer: smart contracts are the behavior of the blockchain
- Code contributor developer could be a mantainer or a core developer
- Mantainer develop fixes for bugs
- Core develop new features for the Ecosystem

Topics:
- best practices
- github
- templates
- on boarding
- user guides

24 July 2023:

Below a mantainers documentation's summary (see https://github.com/hyperledger/toc/blob/gh-pages/guidelines/MAINTAINERS-guidelines.md and https://github.com/hyperledger/toc/blob/gh-pages/guidelines/SAMPLE-MAINTAINERS.md):

All Hyperledger repositories MUST have a MANTAINER.md file.

Becoming a Maintainer for a repository implies being granted special privileges within that repository to do the additional scope(s) of work required of a Maintainer: The "Maintainer" scope is defined as the "Maintain" GitHub role.
In some repositories, the maintainers may decide to define additional scopes, specifying:
- if a mantainer has a different role for the repository (with more capable or less capable privileges)
- or mantainer scope in a repository which do not require elevated Github privileges (for community meetings, or Report contributing).
Different scopes of mantainer require a list of scopes with: name, definition, role, Github roles and team.

Lists of active and emeritus maintainers MUST be included in the MAINTAINERS.md file.
Changes to the maintainers lists MUST be made via Pull Requests (PR). Once a PR changes of the mantainer list is merged, MUST be made a corresponding update to the Github Teams.
This is a manual process ensured by the mantainers.
The mantainer lists MUST contain: a Github ID, the scope, a LFID (Linux Foundation ID) a Discord ID and an Email contact, a Company affiliation

The MAINTAINERS.md file SHOULD contain information about the different maintainer scopes, and for each, the maintainers duties (e.g., maintainers calls, quarterly reports, code reviews, issue cleansing).

The MAINTAINERS.md file SHOULD contain information about how to become a maintainer for the project:
- requirements before someone can be considered to became a mantainer (including emeritus mantainer changed to active)
- the different requirements for the different scopes
- whether sponsorship by an existing mantainer is required
- how mantainer are proposed to the community: tipically is done, by a PR against the MANTAINER.md file including how the proposed contributor meets the criteria
- how many mantainers must approve the proposed mantainer
- how long the existing mantainer have to respond to the proposal

The MAINTAINERS.md file SHOULD contain information about how a maintainer is removed from the list of active maintainers:
- the reasons a mantainer would be removed from the list of active mantainers
- how a removal is proposed: tipically, via a PR against the MANTAINER.md file

Below an example of the duties of a mantainer, how to become a mantainer and why a mantainer is removed from the active list:

Becoming a Maintainer
This community welcomes contributions. Interested contributors are encouraged to progress to become maintainers. To become a maintainer the following steps occur, roughly in order.

The proposed maintainer establishes their reputation in the community, including authoring five (5) significant merged pull requests, and expresses an interest in becoming a maintainer for the repository.
A PR is created to update this file to add the proposed maintainer to the list of active maintainers.
The PR is authored by an existing maintainer or has a comment on the PR from an existing maintainer supporting the proposal.
The PR is authored by the proposed maintainer or has a comment on the PR from the proposed maintainer confirming their interest in being a maintainer.
The PR or comment from the proposed maintainer must include their willingness to be a long-term (more than 6 month) maintainer.
Once the PR and necessary comments have been received, an approval timeframe begins.
The PR MUST be communicated on all appropriate communication channels, including relevant community calls, chat channels and mailing lists. Comments of support from the community are welcome.
The PR is merged and the proposed maintainer becomes a maintainer if either:
Two weeks have passed since at least three (3) Maintainer PR approvals have been recorded, OR
An absolute majority of maintainers have approved the PR.
If the PR does not get the requisite PR approvals, it may be closed.
Once the add maintainer PR has been merged, any necessary updates to the GitHub Teams are made.
Removing Maintainers
Being a maintainer is not a status symbol or a title to be carried indefinitely. It will occasionally be necessary and appropriate to move a maintainer to emeritus status. This can occur in the following situations:

Resignation of a maintainer.
Violation of the Code of Conduct warranting removal.
Inactivity.
A general measure of inactivity will be no commits or code review comments for one reporting quarter. This will not be strictly enforced if the maintainer expresses a reasonable intent to continue contributing.
Reasonable exceptions to inactivity will be granted for known long term leave such as parental leave and medical leave.
Other circumstances at the discretion of the other Maintainers.
The process to move a maintainer from active to emeritus status is comparable to the process for adding a maintainer, outlined above. In the case of voluntary resignation, the Pull Request can be merged following a maintainer PR approval. If the removal is for any other reason, the following steps SHOULD be followed:

A PR is created to update this file to move the maintainer to the list of emeritus maintainers.
The PR is authored by, or has a comment supporting the proposal from, an existing maintainer or Hyperledger GitHub organization administrator.
Once the PR and necessary comments have been received, the approval timeframe begins.
The PR MAY be communicated on appropriate communication channels, including relevant community calls, chat channels and mailing lists.
The PR is merged and the maintainer transitions to maintainer emeritus if:
The PR is approved by the maintainer to be transitioned, OR
Two weeks have passed since at least three (3) Maintainer PR approvals have been recorded, OR
An absolute majority of maintainers have approved the PR.
If the PR does not get the requisite PR approvals, it may be closed.
Returning to active status from emeritus status uses the same steps as adding a new maintainer. Note that the emeritus maintainer already has the 5 required significant changes as there is no contribution time horizon for those.

26 July:

presentation link: