LFDT updates for maintainers inactivity #292
Conversation
arsulegai
requested review from
tkuhrt,
VRamakrishna,
denyeart,
jimthematrix,
mbrandenburger,
non-fungible-nelson,
petermetz,
swcurran,
yacovm and
a team
as code owners
github-actions
bot
added
quarterly-report
arsulegai
force-pushed
the
inactivity-lfdt
branch
from
40ad6a3
to
505abcf
Compare
| @@ -9,24 +9,24 @@ nav_order: 8 | |||
|
|
|||
| # Inactivity Policies | |||
|
|
|||
| As part of the normal lifecycle of a project codebases and maintainers come and go. This document formalizes a Hyperledger wide policy for moving maintainers to emeritus status when a project does not have an explicit policy of their own, and the responsibilities of the Technical Advisory Council (TAC), Hyperledger Foundation staff, and maintainers in this process. | |||
| As part of the normal lifecycle of a project, codebases and maintainers come and go. This document outlines a LF Decentralized Trust-wide policy for moving maintainers to emeritus status when a project's TSC does not have an explicit policy of its own, as well as the responsibilities of the Technical Advisory Council (TAC), LF Decentralized Trust staff, and maintainers in this process. | |||
There was a problem hiding this comment.
Should the organizational policy be parallel with the project’s TSC policy, or only in effect when the TSC doesn’t have a policy? I think the latter might be too limiting.
There was a problem hiding this comment.
I'd vote for it providing the defaults in case the TSC doesn't feel the need to define their own.
On Cacti we always try to go with the defaults so it would be great for us to preserve maintainer (TSC member) resources/time.
For those who would like to have more custom policies, this would still give them the option to define things for themselves.
It should be mentioned that some things from the organizational policy should be non-overridable, DCO being the example coming to mind.
There was a problem hiding this comment.
@swcurran are you considering a case where the project may have lenient policy as opposed to being stricter?
There was a problem hiding this comment.
I'm thinking of the case where the project is not enforcing their policy. I think even if they have a policy, this policy must be used. For example, when the inactivity in the Project's TSC itself.
|
|
||
| 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 TAC Chair or who the TAC Chair designates. | ||
| 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 (e.g., email, GitHub mentions) will be at the discretion of the TAC Chair or their designee. |
There was a problem hiding this comment.
This should happen even if the TSC has a policy about removing maintainers. Further, the project (the TSC? the list of all maintainers?) should also receive the notifications about the lack of activity of maintainers.
There was a problem hiding this comment.
(the TSC? the list of all maintainers?)
I'd say both.
This should happen even if the TSC has a policy about removing maintainers.
Plus one!
This should be one of those things that cannot be overridden from the organizational policy.
|
|
||
| When a maintainer has not had any activity in a particular project for six months a proposal will be opened up to move the maintainer from active status to emeritus status. A member of the TAC or a Hyperledger staff member will open this proposal. Any permissions to approve pull requests or commit code and any other such privileges associated with maintainer status will be removed. | ||
| When a maintainer has not had any activity in a particular project for six months, a proposal will be opened to move the maintainer from active status to emeritus status. This proposal will be initiated by a member of the TAC or LF Decentralized Trust staff. All permissions to approve pull requests, commit code, and other related privileges will be removed. |
There was a problem hiding this comment.
I recommend that we add "a member of the project's TSC". It is probably more important that the project is responsible for this.
|
|
||
| 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 TAC Chair or who the TAC Chair designates. | ||
| 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 (e.g., email, GitHub mentions) will be at the discretion of the TAC Chair or their designee. |
There was a problem hiding this comment.
I recommend that the "TAC chair" in this statement be changed to the "project's TSC chair"
|
|
||
| A Hyperledger Foundation staff member will provide a report (or maintain an automated means to generate a report) of the most recent GitHub tracked actions for contributors at regular intervals to the TAC. It will be the TAC's responsibility to act on the data. | ||
| A LF Decentralized Trust staff member will provide a report (or maintain an automated means to generate a report) of the most recent GitHub tracked actions for contributors at regular intervals to the TAC. It will be the TAC's responsibility to act on the data. |
There was a problem hiding this comment.
Recommend changing "TAC" to "project's TSC"
Signed-off-by: S m, Aruna <arun.s.m.cse@gmail.com>
arsulegai
force-pushed
the
inactivity-lfdt
branch
from
505abcf
to
c646ced
Compare
|
@VRamakrishna . I cleaned up the working branch and removed stale and unrelated commits. The PR now has files related to maintainers inactivity policy. |
No description provided.