Maintainer and Repository Inactivity Policy #33
Conversation
inactivity.md
Outdated
|
|
||
| Hyperledger very much appreciates the contributions of all maintainers but removing write privledges is in the interest of an orderly and secure project. | ||
|
|
||
| Maintainers who have not contributed to a Hyperledger project for (`exact timeframe to be decided`) 3 / 4 / 6 months will be removed from the relevant Github Organizations. |
There was a problem hiding this comment.
A few questions that may arise, just thinking out loud here
- Repository never needed a maintainer activity.
- The maintainer is responsible for multiple projects, the maintainer did not have a commit or an activity in one of those projects in the last [3/4/6] months.
- Should the access be removed from the organization or only from the repository that the user is a maintainer of. If a maintainer is not part of any project then eventually be removed from the org.
There was a problem hiding this comment.
- ?? I'm not sure what is being asked ??
- The tooling appears to allow us to track per-repo, so we can enforce this on a per-project basis. i.e. if I am part of project Foo and project Bar and stop contributing to Bar for 6 months, my maintainer status on Bar is removed and my commit access for Bar is removed. My status in Foo is unaffected
- as discussed further down the list, it will be per team. If they are removed from all teams then org removal would be the next step.
There was a problem hiding this comment.
For item (1) I was referring to a highly possible case, let's consider a project, where one of the maintainer is responsible only to maintain a specific repository. But it happened so that the repository is pretty much stable and did not require any update for months.
inactivity.md
Outdated
|
|
||
| These policies apply to projects that do not have an expicity maintainer inactivity policy. Where a project has an established and functioning policy the projects policies shall prevail. | ||
|
|
||
| ## Repository Inactivity |
There was a problem hiding this comment.
There is a separate process for project's lifecycle. We can focus on the maintainers in this section, if we need a revision on project's lifecycle let's do it there.
There was a problem hiding this comment.
I would prefer to keep all inactivity policies in one place. Splitting it into two policies splits the focus, which is dealing with inactivity holistically and not piecemeal.
There was a problem hiding this comment.
It is possible that repositories for an otherwise active project have become inactive. It is important to have some mechanism to "archive" those inactive repositories. I agree that any project lifecycle changes should be in the project lifecycle document.
inactivity.md
Outdated
|
|
||
| ## Repository Inactivity | ||
|
|
||
| Any repository that has not had a release for (`exact timeframe to be decided`) 12 months or that has had no commits for 6 months may be archived by the TSC or Hyperledger staff. |
There was a problem hiding this comment.
I think we need to reflect somehow that commits to being counted has to be of significant importance and not small updates and changes. Another point is that there are repos where maintainers extracted self-contained functionality and there is not actually too much to update there besides probably some dependencies or release notes. IMO we also need to be careful with this here, I would consider per project health status rather than the single repo.
There was a problem hiding this comment.
For a HLF wide policy we need a very objective policy, and judging the worth of a commit is about as subjective as it gets. Individual projects can make their own policy if they want to judge the significance of a contribution.
Regarding the static "framework" repositories, the clause about requests not to close has no limit (unlike the contributor policy) so a true framework can be kept unarchived indefinitely, until the security notifications start piling up.
One reason to focus this per-repository instead of per-project is that some project repos have been forgotten by their projects when maintainers leave. If the repo is valuable the team can request it not be archived.
inactivity.md
Outdated
|
|
||
| Hyperledger very much appreciates the contributions of all maintainers but removing write privileges is in the interest of an orderly and secure project. | ||
|
|
||
| Maintainers who have not contributed to a Hyperledger project for (`exact timeframe to be decided`) 3 / 4 / 6 months will be retired from active maintainer status and moved to an emeritus status. Any permissions to approve pull requests or commit code and any other such privileges associated with maintainer status will be removed. |
There was a problem hiding this comment.
3 months sounds too short.
6 months + 3 month extension sounds too long (9 months total).
My suggestion would be to split the difference: a 4 month inactivity timeframe, with option for 2 month extension, resulting in a total period of 6 months.
|
I vote for 3 months of inactivity with one 3 month extension granted upon request. |
|
@hyperledger/tsc : Just a reminder to approve or comment on this PR. We do not currently have enough votes here in GitHub to approve. If we do not get that, we will bring this up for a vote in Thursday's meeting. |
|
I vote YES. I cannot approve my own PR so this will be my vote. Posting a PR may be taken as an implicit YES vote, but I can see situations where making a proposal to vote negatively on would be useful to crystalize committee policy and positions. |
|
yes |
|
|
||
| Activity can be code contributions, code reviews, issue reporting, or any other such activity trackable by GitHub attributed to a Hyperledger repository. | ||
|
|
||
| When a maintainer has not had any activity in a particular project for three months they will receive a notification informing them of the inactivity policies. The means and manner of notification (email, github mentions, etc.) will be at the discretion of the TSC Chair or who the TSC Chair designates. |
There was a problem hiding this comment.
Does this mean that TSC chair can choose their preferred media of communication to different projects and repositories?
I wouldn't think that's necessary, moving to emeritus status is anyway publicly visible. There can be a standard process setup where notifications are sent to a group of maintainers. For example, a discord channel for maintainers of that project, on mailing list etc. The secondary means of communication can then become optional.
There was a problem hiding this comment.
I don't want to write the means of warning in to the policy. This makes it flexible if a project changes chat servers again, or if one project uses email more than chat, or any other such eventualities.
Since this is a courtesy notice it may not come in the form of a PR.
ryjones
added
decision-log
|
Approved by voice vote 12 MAY 2022 |
Establish policies for when a maintainer stops contributing and when repositories stop receiving contributions. Signed-off-by: Danno Ferrin <danno.ferrin@gmail.com>
Establish policies for when a maintainer stops contributing and when
repositories stop receiving contributions.
Fixes #32
Signed-off-by: Danno Ferrin danno.ferrin@gmail.com