Fetching the latest programs, projects, and workspace data.
<p>The Hiero ecosystem includes a growing number of diverse contributors, repositories, junior committers/committers/maintainers, pull requests, issues, discussions, and quality requirements.</p><p><br></p><p>To build a diverse ecosystem which generates high-quality code, maintainers need to spend a significant amount of time on repetitive coordination tasks such as checking contributor qualifications, validating pull request quality, un-assigning inactive contributors, closing stale issues, creating issues at different difficulties, and ensuring that repository processes are followed consistently.</p><p><br></p><p>We have demonstrated in some SDK repositories many of these maintainer tasks can be automated using custom GitHub action workflows and templates. However, the current setup is fragmented, difficult to customize and scale, and inconsistent across repositories. Different repositories may require different rules, but maintainers still need support to ensure they are working on the most important tasks, and developers need support to help them progress quickly and qualify to gain more responsibilities.</p><p><br></p><p>This mentorship project aims to design and build an automation framework and application for Hiero end-to-end maintainer workflows. The system should support configurable repository automation features that maintainers can turn on or off, depending on the repository context.</p><p><br></p><p>Example user on-boarding workflows:</p><ul><li>Checking contributors are humans</li><li>Checking whether contributors meet contribution requirements before assigning issues</li><li>Offering automatic issue assignment</li><li>Automatically assigning mentors for new contributors</li><li>Issue templates and documentations</li></ul><p>Example pull request review and quality workflows:</p><ul><li>AI issue planning</li><li>AI initial reviewing</li><li>Automated code quality, DCO, GPG, etc checks based on configurable quality requirements</li><li>Automatic review based on configurable quality requirements</li></ul><p>Example developer progression workflows:</p><ul><li>Automatic issue recommendations after a merged pull request to next available issues</li><li>Checking whether advanced contributors meet requirements to progress to JC/committer/maintainer</li></ul><p>Example issue management workflows:</p><ul><li>Managing stale issues or pull requests</li><li>Requesting help or feedback from specified teams based on labels</li></ul><p><br></p><p>A core requirement of the project is to ensure that this automation is reliable, consistent, secure, and scalable enough to be used across a variety of repositories inside Hiero (and one day optionally across LFDT).</p><p><br></p><p>The project should also define clear boundaries for what the automation is allowed to do, how maintainers configure it, and how users can understand or override automated actions when necessary.</p><p>The result should not just be a prototype for a single repository, but a hardened and reusable solution that can serve multiple Hiero repositories with different policies and maintenance needs. </p><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/73" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/73</a></p>
Showing 1 of 1 projects. Click any project card for scope, mentors, and proposal studio.
<p>The Hiero ecosystem includes a growing number of diverse contributors, repositories, junior committers/committers/maintainers, pull requests, issues, discussions, and quality requirements.</p><p><br></p><p>To build a diverse ecosystem which generates high-quality code, maintainers need to spend a significant amount of time on repetitive coordination tasks such as checking contributor qualifications, validating pull request quality, un-assigning inactive contributors, closing stale issues, creating issues at different difficulties, and ensuring that repository processes are followed consistently.</p><p><br></p><p>We have demonstrated in some SDK repositories many of these maintainer tasks can be automated using custom GitHub action workflows and templates. However, the current setup is fragmented, difficult to customize and scale, and inconsistent across repositories. Different repositories may require different rules, but maintainers still need support to ensure they are working on the most important tasks, and developers need support to help them progress quickly and qualify to gain more responsibilities.</p><p><br></p><p>This mentorship project aims to design and build an automation framework and application for Hiero end-to-end maintainer workflows. The system should support configurable repository automation features that maintainers can turn on or off, depending on the repository context.</p><p><br></p><p>Example user on-boarding workflows:</p><ul><li>Checking contributors are humans</li><li>Checking whether contributors meet contribution requirements before assigning issues</li><li>Offering automatic issue assignment</li><li>Automatically assigning mentors for new contributors</li><li>Issue templates and documentations</li></ul><p>Example pull request review and quality workflows:</p><ul><li>AI issue planning</li><li>AI initial reviewing</li><li>Automated code quality, DCO, GPG, etc checks based on configurable quality requirements</li><li>Automatic review based on configurable quality requirements</li></ul><p>Example developer progression workflows:</p><ul><li>Automatic issue recommendations after a merged pull request to next available issues</li><li>Checking whether advanced contributors meet requirements to progress to JC/committer/maintainer</li></ul><p>Example issue management workflows:</p><ul><li>Managing stale issues or pull requests</li><li>Requesting help or feedback from specified teams based on labels</li></ul><p><br></p><p>A core requirement of the project is to ensure that this automation is reliable, consistent, secure, and scalable enough to be used across a variety of repositories inside Hiero (and one day optionally across LFDT).</p><p><br></p><p>The project should also define clear boundaries for what the automation is allowed to do, how maintainers configure it, and how users can understand or override automated actions when necessary.</p><p>The result should not just be a prototype for a single repository, but a hardened and reusable solution that can serve multiple Hiero repositories with different policies and maintenance needs. </p><p><br></p><p>Lean more at <a href="https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/73" rel="noopener noreferrer" target="_blank">https://github.com/LF-Decentralized-Trust-Mentorships/mentorship-program/issues/73</a></p>