I opened a PR to insert a new field for maintainers - namely, inactivityReason:
I need opinions about it.
Here is a description:
Description - not up-to-date
Default null; should be a free-form string explaining why the maintainer became
inactive.
The most immediate use of this attribute is to mark maintainers that are not
contributing to Nixpkgs from a long amount of time. Nonetheless it can be used
to mark any long term inactivity, including but not limited to:
Sabbatical leave
Retirement
Intimate issues
Force majeure
In principle, a third person can set this attribute. For the sake of a good
etiquette, in such case at least one contact attempt should be issued and
carried out before effectively committing it to the codebase.
This attribute can be employed to many useful activities, including but not
limited to:
i read through the discussion and understand what youāre trying to achieveā¦ and maybe itās just meā¦ but it feels a bit strange to record this information here
At a guess this might be a mild mistranslation? I think āpersonal issuesā might be more idiomatic for ānon-project related, doesnāt want to disclose furtherā? (E.g. health, relationship, family problems, etc)
It might be worth thinking about how and in what circumstances the information is useful. Ultimately I guess it comes down to āis the maintainer likely to become active againā and āif so, in what sort of time-frameā? In which case perhaps it might be better as a non-free form field that covers those two things. The third bit of useful info might be āhow sure are we of the accuracy of this informationā, which might encompass whether it was set by the maintainer themselves or a third party, etc.
At a guess this might be a mild mistranslation? I think āpersonal issuesā might be more idiomatic for ānon-project related, doesnāt want to disclosure furtherā? (E.g. health, relationship, family problems, etc)
Yes, that was the idea initially.
I have updated on the original PR.
Ultimately I guess it comes down to āis the maintainer likely to become active againā and āif so, in what sort of time-frameā?
Yes. The most typical usage would be in cases of āthe maintainer is not respondingā. But nothing hinders the maintainer theemself of filling this field.
privacy concerns probably make this information less valuable than you think it will be - i stand against recording family issues that our maintainers have in pkgs/ā¦ which leads into my next point: this sounds like a highly speculative game that results in rules that sound awkward when spoken out loud
why donāt we just make it simple and say something super generic like āno activity after x units of time results in removal of maintainer statusā with the well understood fact that it isnāt āpersonalā and weāre happy to have you back?
if any of this is to avoid making someone feel bad for removing their maintainer status i feel like the alternative overall causes was less undesirable feeling as long as it is a well documented policy
This can work, as long as we have tooling to support it (which we currently donāt). and there is some benefit ti having maintainers explicitly say they are busy (the reason is still too-much-info IMO)
I think āpersonal issuesā might be more idiomatic for ānon-project related, doesnāt want to disclose furtherā? (E.g. health, relationship, family problems, etc)