add: tac/project-updates/2025/2025-annual-Cacti.md

[petermetz]

Signed-off-by: Peter Somogyvari [email protected]

[arsulegai]

Draft Review Comments/To Be Discussed:

Observations:

1. Efforts to onboard new maintainers have decreased due to the mentorship program.
2. A couple of organizations appear in the top contributions list but there appears to be no maintainers from those organizations - for example, Blockdaemon.

Scorecard Concerns:

1. Binaries are placed alongside the GitHub source code; is it possible to store them in their own registries and then download during builds?
2. Separate concerns for dealing with infrastructure can be addressed by using granular Role-Based Access Control (RBAC) instead of uploading artifacts to the repository.
3. To protect GitHub tokens, evaluate each used token once for the principle of least privilege.
4. There are a couple of low-hanging fruits; one is to have a Linux Foundation trademark and another is to adopt license scanning tools. If required, please raise an assistance request to the LF Decentralized Trust staff members.

Questions:

1. Has the project team actively sought collaboration with other blockchain communities? Did there occur any pushback for contributions for any reason?
2. What factors contribute to maintaining a large repository? Can it be broken down into smaller, independent repositories so that each can be maintained independently?
3. What pain points have you faced during migrating to a new organization?

Suggestions for project's goals:

1. The goal for production implementation is not entirely in control of the project team; would it be feasible to set an alternative goal such as - open to support the implementation, open a project intake process? Otherwise, the project may set a goal such that about X% of all requests will be handled within Y days.
2. Has the project team approached the community outside of LF Decentralized Trust?
3. How about Cacti's involvement with verifiable credentials projects? Were there any talks or collaborations regarding this during maintainer days?

[EnriqueL8]

Rafael mentioned above seems to be from Blockdaemon should this be in the list?

[petermetz]

@EnriqueL8 My information might be outdated by Rafael told me to put him down as a representative of the university. I think we had that discussion a while back so it's possible he'd prefer Blockdaemon at this point. @RafaelAPB, any preference?

[tkuhrt]

@arsulegai @EnriqueL8 : Please let me know which TAC meeting you will want to review this.

[VRamakrishna]

@arsulegai On the topic of collaboration with verifiable credentials projects, we opened an issue in Indy (hyperledger/indy-node#1841) and presented our requirement/proposal to the Indy team in one of their maintainers' calls. Unfortunately, the mentee that was working on the issue was unable to complete the task, so it's still pending. Broader context: one of the features in Cacti involves identity sync across networks, for which we investigated using Indy and Aries protocols.

[petermetz]

@arsulegai My responses inline:

Draft Review Comments/To Be Discussed:

Observations:

1. Efforts to onboard new maintainers have decreased due to the mentorship program.

Fair. We shall work on improving this.

2. A couple of organizations appear in the top contributions list but there appears to be no maintainers from those organizations - for example, Blockdaemon.

Rafael works for Blockdaemon and he's pretty active, but a while back he said that I should put him down as associated with his university (Tecnico Lisboa). I'm not sure if this has changed in the meantime, but we'll get to the bottom of it.

Scorecard Concerns:

1. Binaries are placed alongside the GitHub source code; is it possible to store them in their own registries and then download during builds?

Fair. We shall work on improving this.
I know of a few Java binaries which are required by the Weaver components that are in this category so I'll pass this on to @VRamakrishna
The other two items can and will be removed, no issues (in packages that I'm the principal maintainer of)

2. Separate concerns for dealing with infrastructure can be addressed by using granular Role-Based Access Control (RBAC) instead of uploading artifacts to the repository.

Agreed, I think this is feasible and we shall work on it.

3. To protect GitHub tokens, evaluate each used token once for the principle of least privilege.

Fair. We shall work on improving this.

4. There are a couple of low-hanging fruits; one is to have a Linux Foundation trademark and another is to adopt license scanning tools. If required, please raise an assistance request to the LF Decentralized Trust staff members.

Agreed.

Questions:

1. Has the project team actively sought collaboration with other blockchain communities? Did there occur any pushback for contributions for any reason?

Yes, always and continuously. We have an "our door is always open" policy on collaborations. Some people come on-board others choose to go a different way.

2. What factors contribute to maintaining a large repository? Can it be broken down into smaller, independent repositories so that each can be maintained independently?

The main factor is ease of administration. The maintainers are low on bandwidth for repository related administrative chores and so it is more efficient to have a mono-repo where we can configure things once and have the configured for the entire project implicitly.
The current belief is that breaking it down to more projects would introduce additional overhead and slow progress.

3. What pain points have you faced during migrating to a new organization?

Nothing was particularly painful about it. We've had a steady stream of small issues along the way that were each relatively easy to fix. They kept popping up for a period spanning many months so maybe the length of that period could've been shorter, but that is probably just due to the fact that we were an early adopter in this process so there was no up to date checklist on how to get it all done in one push.

Suggestions for project's goals:

1. The goal for production implementation is not entirely in control of the project team; would it be feasible to set an alternative goal such as - open to support the implementation, open a project intake process? Otherwise, the project may set a goal such that about X% of all requests will be handled within Y days.

I've added the goal About 80% of all requests will be handled within 3 days. I'm not sure if this is too ambitious or not ambitious enough but open to feedback on that front. :-)

2. Has the project team approached the community outside of LF Decentralized Trust?

Yes, we've been in communication with various organizations, universities, for-profit companies and the like.

3. How about Cacti's involvement with verifiable credentials projects? Were there any talks or collaborations regarding this during maintainer days?

Not yet but this is an avenue we should also explore so I'll add it to the project goals as well. Thank you Arun!

[arsulegai]

@arsulegai On the topic of collaboration with verifiable credentials projects, we opened an issue in Indy (hyperledger/indy-node#1841) and presented our requirement/proposal to the Indy team in one of their maintainers' calls. Unfortunately, the mentee that was working on the issue was unable to complete the task, so it's still pending. Broader context: one of the features in Cacti involves identity sync across networks, for which we investigated using Indy and Aries protocols.

Thank you

[arsulegai]

@arsulegai My responses inline:

Draft Review Comments/To Be Discussed:
Observations:

1. Efforts to onboard new maintainers have decreased due to the mentorship program.

Fair. We shall work on improving this.

2. A couple of organizations appear in the top contributions list but there appears to be no maintainers from those organizations - for example, Blockdaemon.

Rafael works for Blockdaemon and he's pretty active, but a while back he said that I should put him down as associated with his university (Tecnico Lisboa). I'm not sure if this has changed in the meantime, but we'll get to the bottom of it.

Scorecard Concerns:

1. Binaries are placed alongside the GitHub source code; is it possible to store them in their own registries and then download during builds?

Fair. We shall work on improving this. I know of a few Java binaries which are required by the Weaver components that are in this category so I'll pass this on to @VRamakrishna The other two items can and will be removed, no issues (in packages that I'm the principal maintainer of)

2. Separate concerns for dealing with infrastructure can be addressed by using granular Role-Based Access Control (RBAC) instead of uploading artifacts to the repository.

Agreed, I think this is feasible and we shall work on it.

3. To protect GitHub tokens, evaluate each used token once for the principle of least privilege.

Fair. We shall work on improving this.

4. There are a couple of low-hanging fruits; one is to have a Linux Foundation trademark and another is to adopt license scanning tools. If required, please raise an assistance request to the LF Decentralized Trust staff members.

Agreed.

Questions:

1. Has the project team actively sought collaboration with other blockchain communities? Did there occur any pushback for contributions for any reason?

Yes, always and continuously. We have an "our door is always open" policy on collaborations. Some people come on-board others choose to go a different way.

2. What factors contribute to maintaining a large repository? Can it be broken down into smaller, independent repositories so that each can be maintained independently?

The main factor is ease of administration. The maintainers are low on bandwidth for repository related administrative chores and so it is more efficient to have a mono-repo where we can configure things once and have the configured for the entire project implicitly. The current belief is that breaking it down to more projects would introduce additional overhead and slow progress.

3. What pain points have you faced during migrating to a new organization?

Nothing was particularly painful about it. We've had a steady stream of small issues along the way that were each relatively easy to fix. They kept popping up for a period spanning many months so maybe the length of that period could've been shorter, but that is probably just due to the fact that we were an early adopter in this process so there was no up to date checklist on how to get it all done in one push.

Suggestions for project's goals:

1. The goal for production implementation is not entirely in control of the project team; would it be feasible to set an alternative goal such as - open to support the implementation, open a project intake process? Otherwise, the project may set a goal such that about X% of all requests will be handled within Y days.

I've added the goal About 80% of all requests will be handled within 3 days. I'm not sure if this is too ambitious or not ambitious enough but open to feedback on that front. :-)

2. Has the project team approached the community outside of LF Decentralized Trust?

Yes, we've been in communication with various organizations, universities, for-profit companies and the like.

3. How about Cacti's involvement with verifiable credentials projects? Were there any talks or collaborations regarding this during maintainer days?

Not yet but this is an avenue we should also explore so I'll add it to the project goals as well. Thank you Arun!

Thank you