At hiero ledger we are supporting the roles of: Junior Committer, Committer, Maintainer in some repositorites as the pipeline to reach maintainer status.
So far the documentation in the governance repo abstracts all of the qualifications to each individual repository.
This issue proposes creating a set of skill-pillars that contributors should reach, at the minimum level, to qualify for Junior Committer, Committer or Maintainer roles in Hiero Ledger in order to increase transparency and provide clearer paths towards code stewardship.
The skill-pillars should continue to abstract specific thresholds to the repositories themselves, so new repositories may be able to have lower requirements, and more mature codebases involving more difficult issues, can also adjust requirements.
The document should also emphasise that individual repositories can apply additional pillar-requirements not covered in this governance document, for example, if it is a security sensitive repository.
The document should recognise that community members can be in diverse timezones and have different levels of availability, but their contributions can still be valued.
At hiero ledger we are supporting the roles of: Junior Committer, Committer, Maintainer in some repositorites as the pipeline to reach maintainer status.
So far the documentation in the governance repo abstracts all of the qualifications to each individual repository.
This issue proposes creating a set of skill-pillars that contributors should reach, at the minimum level, to qualify for Junior Committer, Committer or Maintainer roles in Hiero Ledger in order to increase transparency and provide clearer paths towards code stewardship.
The skill-pillars should continue to abstract specific thresholds to the repositories themselves, so new repositories may be able to have lower requirements, and more mature codebases involving more difficult issues, can also adjust requirements.
The document should also emphasise that individual repositories can apply additional pillar-requirements not covered in this governance document, for example, if it is a security sensitive repository.
The document should recognise that community members can be in diverse timezones and have different levels of availability, but their contributions can still be valued.