I've been thinking about the amount of wasted time spent on the non-responsive maintainer policy. If we think about it, it is actively discouraging active maintenance for an extended period of time.
I'd like to propose that in the cases where the process is being initiated by someone who is a) a current packager and b) willing to take over the package in question, we modify step 3 and 5 of the policy to include:
"After seven days, if the reporter is a current Fedora packager in good standing, they will open a FESCo ticket asking to be added as a comaintainer on the package. This ticket must also @-mention each of the existing maintainers on the package. Barring an immediate outcry by existing maintainers, FESCo will add the reporter as a comaintainer."
My thought process is this: anyone who is a current member of the packager group is already a "trusted" member of the Fedora community. We trust them not to make poor decisions in the packages that they already maintain. If they are actively seeking to take up the maintenance of another package that is going untended, I think our policy should be to give them access as soon as possible. We can still process the remainder of the non-responsive policy to remove the missing packager, but we don't need to drag things out for a month to get changes landed.
How should I understand "Fedora packager in good standing"?
Member of the packager group who is not currently on moderation on any of the mailing lists.
I like the general idea. I'm afraid that nobody would follow the regular thing to the end and we'll end up with a lot of packages with "dead" main admin, being actually more maintained by the co-maintainers. While this already happens a lot and it is not necessarily hurting anything, eventually it can lead to a state where the "main POC" is not a reliable information.
I'm not sure if we should care about that issue or not.
I think the idea of "Main POC" is a flawed one already and I'd prefer for all comaintainers to equally be the "main". (In other words, we should ensure that any communication to the packager, be it email, bug notifications, etc. go to all comaintainers). Right now, there are hundreds if not thousands of packages in Fedora whose "main contact" is AWOL... it's a meaningless distinction.
I agree totally, however (at least currently) the UX of Pagure and Bugzilla somewhat requires that.
Count me as +1 on the general idea, and consider the above offtopic.
I like the general idea, though I'd prefer that we generally follow the procedure to the end, i.e. actually change the main admin of the package. The most annoying part of the procedure is the need to do weekly reminders. So my proposal would be to make it part of FESCo's responsibility (yes, FESCo, this is not a typo) to do the pings. My proposal:
""" Week 0: 1.Check if the non-responsive maintainer is on vacation. To see if the maintainer has been recently active on Fedora, fedora-active-user can be employed. 2. File a bug against the package in Bugzilla asking for the maintainer to respond. This bug should list the outstanding issues they need to address. This is a must. 3. Post to the Fedora devel list with a link to the bug report and asks if anyone knows how to contact the maintainer. Week 1: 4. After 7 days, submit a FESCo issue with the bug link and mailing list post link, stating that you want to take over the package. The non-responsive maintainer and all existing maintainers must be @-mentioned in the ticket. 5. FESCo will vote, following its normal procedure. 6. If approved, and the reporter is a current Fedora packager in good standing, barring an immediate outcry by existing maintainers, FESCo will add the reporter as a comaintainer. At this time, the reported can perform any required package maintenance. Week 2: 7. A week later FESCo will post a reminder in the ticket. Week 3: 8. With no further reply for the original owner, FESCo closes its ticket and the bugzilla ticket and asks releng to assign the reporter as the main maintainer of the package.
Once the final reassignment happens, the new owner must also reassign all open bugs for this package to themselves. """
Rationale: the chair has to look at all open tickets once every week anyway, so a simple "ping!" is essentially no additional work. Notifications about FESCo tickets are sent to the packager's address, so it doesn't matter much if it's bugzilla or pagure, they are equally likely to see the message. This should be more or less equally fast as @sgallagh's proposal, but should result in packages still being reassigned fully in the end. The total timeline is the same as now.
@zbyszek: I like it. +1
This process has to take into account lots of things, but I like the idea of trying to make the more common cases better.
Some questions:
When a maintainers package is reassigned this way, does that mean we keep all the rest of their packages owned by them until this process is run on them one by one? Or should we orphan the rest of their packages?
For the non packager case, could we not just use this same process, but not add them/make them main admin and instead orphan? Or is it better in that case to just leave the package owned by a non responsive maintainer. Perhaps the stewardship sig could take these and try and find them homes?
There are sometimes folks who are away for a while due to non vacation reasons... (in hospital, internet down due to weather/etc), but I think adding another maintainer should only be welcomed by them to help share the load.
This process has to take into account lots of things, but I like the idea of trying to make the more common cases better. Some questions: When a maintainers package is reassigned this way, does that mean we keep all the rest of their packages owned by them until this process is run on them one by one? Or should we orphan the rest of their packages?
This process has to take into account lots of things, but I like the idea of trying to make the more common cases better. Some questions:
When the process concludes and the maintainer is declared non-responsive, we orphan all of their packages. At the point where we grant comaintainership to the new maintainer, we may want to preemptively send out a request for comaintainers of other packages as well (rather than waiting for the process to conclude).
I think we should just let the existing process continue, or else ask the reporter to locate a potential new owner.
Basically, I'm proposing that we assume good intentions by default. So if someone comes to us and wants to take over a stagnant package, we should pretty much automatically let them (modulo some "good standing" rules, which I shorthanded above as meaning "not moderated on any of the lists", but which we could tweak later).
I'm +1 to @zbyszek's proposal.
On Mon, 2019-06-17 at 20:57 +0000, Kevin Fenzi wrote:
I think we should orphan the rest of their packages.
I think orphaning these is good here too. The stewardship SIG can adopt orphans like anyone else, if they like.
There are sometimes folks who are away for a while due to non vacation reasons... (in hospital, internet down due to weather/etc), but I think adding another maintainer should only be welcomed by them to help share the load.=20
+1
I can +1 @zbyszek's proposal.
since we are changing this, could we plese also:
My updated proposal:
Completely drop the para with "The policy is targeted at maintainers that can still be reached ... short-circuit the normal 3 week interval required in the Outline steps 1 to 3, and make the formal request to orphan mentioned in step 4.".
Replace all of Outline with: """ Week 0: 1.Check if the non-responsive maintainer is on vacation. To see if the maintainer has been recently active on Fedora, fedora-active-user can be employed. 2. File a new bug against the package in Bugzilla asking for the maintainer to respond. This bug should list the outstanding issues they need to address. This is a must. The bug should be titled "Nonreponsive maintainer check for <fas-id>". 3. Post to the Fedora devel list with a link to the bug report and asks if anyone knows how to contact the maintainer. Week 1: 4. After 7 days, submit a FESCo issue with the bug link and mailing list post link. State if you are a packager and want to take over the package. The non-responsive maintainer and all existing maintainers must be @-mentioned in the ticket. 5. FESCo will vote, following its normal procedure. 6. If approved, and the reporter is a current Fedora packager in good standing, barring an immediate outcry by existing maintainers, FESCo will add the reporter as a comaintainer. At this time, the reported can perform any required package maintenance. Week 2: 7. A week later FESCo will post a reminder in the ticket. Week 3: 8. With no further reply for the original owner, FESCo closes its ticket and the bugzilla ticket. If maintainership was requested in 4., the reporter will be assigned as the main maintainer of the package. All other packages are orphaned too, and may be picked up by co-maintainers or other packagers.
Once the final reassignment happens, the new owner must also reassign all open bugs for this package to themselves.
If you are a not an existing Fedora contributor, you can follow this procedure too. If you want to take over maintainership, you must find a sponsor following the rules specified in https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group. """
This is in line with comments since the previous proposal. So please don't vote again, unless you want to change your +1.
two small things:
1) can we make the bugzilla bug and the fesco ticket use templates so they are in a standard format and have all the info we need? (ie, have the policy say 'use the provided template and fill out all asked for info')
2) In week 1 with the fesco ticket filing, can we request/add a list of other packages they maintain, in the event they are all orphaned we can line up folks for critical packages with some time instead of a scramble at the end of the process when all of them are orphaned.
Otherwise looks great to me.
try to walk trough the steps as if you actually don't want the package:
After 7 days, submit a FESCo issue with the bug link and mailing list post link. State if you are a packager and want to take over the package.
Assume I don't want to take over the package. Than this doesn't really work:
If approved, and the reporter is a current Fedora packager in good standing, barring an immediate outcry by existing maintainers, FESCo will add the reporter as a comaintainer.
I think we need to reword 6 slightly. What about:
If approved, and the reporter is a current Fedora packager in good standing, interested in comaintaining the package, barring an immediate outcry by existing maintainers, FESCo will add the reporter as the package admin.
Note that I've also changed FESCo will add the reporter as a comaintainer to FESCo will add the reporter as the package admin because we have multiple levels of maintainers.
either way, consider me +1
barring an immediate outcry by existing maintainers
At the risk of word-lawyering, I suggest this needs a more defined period. Either the existing maintainers should speak up before FESCo approves the request — in which case the wording should be dropped entirely — or something like three days (or some other period that seems reasonable).
I assumed the immediate outcry needs to happen before fesco approves this.
Sure, FESCo can approve this in 2 minutes, and the maintainers will not have time to cry, but how likely is that? (I'm not opposed to add a minimal period to wait for the maintainers response, 3 days seem reasonable.)
I actually think that's the better approach, in which case the policy should say that more clearly. But if the intent is to have a period of some non-zero length, it should be more explicit.
Metadata Update from @jforbes: - Issue tagged with: meeting
Metadata Update from @psabata: - Issue untagged with: meeting
Anyone brave enough to finish this?
I assume that we want to:
can we make the bugzilla bug and the fesco ticket use templates so they are in a standard format and have all the info we need? (ie, have the policy say 'use the provided template and fill out all asked for info')
bugzilla — yes, just somebody with the right privs needs to create the template. pagure — <strike>I don't think so, I don't see any mechanism for that. We can instead include the template in the description.</strike> Will create template later.
Normally a FESCo vote takes at least a few days, and co-maintainers have been @-mentioned, so they are notified about the vote taking place. I think this is good enough and we don't need to explicitly state that we'll wait for them.
3rd version of the proposal:
Replace all of Outline with: """ Week 0: 1.Check if the non-responsive maintainer is on vacation. To see if the maintainer has been recently active on Fedora, fedora-active-user can be employed. 2. File a new bug against the package in Bugzilla asking for the maintainer to respond using https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&format=fedora-nonresponsive-maintainer and fill in all the fields. This is a must. 3. Post to the Fedora devel list with a link to the bug report and asks if anyone knows how to contact the maintainer. CC the maintainer.
Week 1: 4. After 7 days, submit a FESCo issue with the bug link and mailing list post link. State if you are a packager and want to take over the package. The non-responsive maintainer and all existing maintainers must be @-mentioned in the ticket. 5. FESCo will vote, following its normal procedure. 6. If approved, and the reporter is a current Fedora packager in good standing, interested in comaintaining the package, FESCo will default to adding the reporter as the package admin. If the existing co-maintainers of the package do not want the package to be reassigned to the reported, they should state so in the ticket. If assigned ownership, the reporter can now perform any required package maintenance.
Week 2: 7. A week later FESCo will post a reminder in the ticket. Week 3: 8. With no further reply for the original owner, FESCo closes its ticket and the bugzilla ticket. If maintainership was requested in 4., the reporter will be assigned as the main maintainer of the package, and the package will be orphaned otherwise. All other packages are orphaned too, and may be picked up by co-maintainers or other packagers.
fedora-nonreponsive-maintainer template: Title: Nonreponsive maintainer check for <fas-id> Body: This bug is part of the non-responsive maintainer procedure for <fas-id>, following https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/. Please respond if you are still active in Fedora and want to maintain <package>.
pagure ticket template: Title: Nonreponsive maintainer: <fas-id> Body: <name> <fas-id>
package: <package>, <link-to-open-bug> nonresponsive maintainer bug: <link-to-nonresponsive-maintainer-bug> fedora-devel mail: <link> comainainers: @<person1> @<person2> additional notes: ...
EDITed by @churchyard to fix a typo (s/bus/bug/) EDITed by me to include "CC the maintainer".
In week 1 with the fesco ticket filing, can we request/add a list of other packages they maintain, in the event they are all orphaned we can line up folks for critical packages with some time instead of a scramble at the end of the process when all of them are orphaned.
This should be automated. I see that in src.fp.o I can filter my own packages by admin: https://src.fedoraproject.org/dashboard/projects?acl=admin. But when I look up a person, I don't see any filter: https://src.fedoraproject.org/user/gil/projects.
pagure — I don't think so, I don't see any mechanism for that. We can instead include the template in the description.
That is possible. see https://docs.pagure.org/pagure/usage/ticket_templates.html
Suggestion:
Post to the Fedora devel list with a link to the bug report and asks if anyone knows how to contact the maintainer.
Post to the Fedora devel list with a link to the bug report and asks if anyone knows how to contact the maintainer. CC the maintainer.
EDIT: The proposal was adapted.
Note, that this was added because when we know the maintainers email address is no longer valid, for example they used to be employed by Red Hat and have a @redhat.com address, but we have been notified that they no longer work for Red Hat, we had a way to try and contact them, but didn't have to do the entire process since we know bugs and @-mentions won't work to contact them. I'd really like some process around that in the new policy.
Proposal: For ex Red Hatters that still use a redhat.com e-mail address, you can skip week 0 and proceed directly to week 1.
(I don't think that was actually need to skip week 3 or 4, as it will just eventually happen anyway.)
@churchyard as it may not be easy for people to know if someone is a current or former RHer and because RH has a process to manage email to former employee email accounts for just this kind of a situation, I suggest we keep week 0 in all cases.
Proposal: For ex Red Hatters that still use a redhat.com e-mail address, you can skip week 0 and proceed directly to week 1. (I don't think that was actually need to skip week 3 or 4, as it will just eventually happen anyway.)
I'm not able to parse that... ex Red Hatters that still use their redhat.com address? How?
Let me describe the current workflow for this:
I'd love to have a better workflow here, as it's pretty much only me that does this and sometimes I don't have time to keep up on it so there are delays.
This is cool - I didn't know we got a notification :D
@kevin I think it would be reasonable for you to move directly to FESCo ticket ..
For ex Red Hatters that still use a redhat.com e-mail address,
they still have redhat.com e-mail address associated to their FAS account
But apparently nobody's listening at the other end ;).
What about adding this note to the text in https://pagure.io/fesco/issue/2149#comment-579981:
""" If the email addresses specified in FAS and bugzilla are dead (emails bounce or the person left a company and the company does not allow access to email by former employees), the steps which depend on e-mail communication (bugzilla bug, CC-ing the maintainer) should be skipped. In the FESCo template, put "(dead email)" instead of the bugzilla link. """
I think we still want the fedora-devel announcement to happen. Also, I assume that when changing jobs people can be slow to respond, so I don't think we should cut short the remaning waits.
Sounds reasonable to me.
I'm good with that too.
+1 to the proposal in https://pagure.io/fesco/issue/2149#comment-579981 + https://pagure.io/fesco/issue/2149#comment-580610
I am good with that.
I'm +1 to the latest proposed changes
Metadata Update from @churchyard: - Issue tagged with: meeting
It's unclear to me if steps 6 means that the reporter is only added after the FESCo vote (which at times may take two weeks). My initial goal in filing this ticket was to try to significantly reduce the time necessary to get a package into the hands of an active maintainer.
My stance is that if a person opens a non-responsive maintainer ticket, is in good standing and expresses a desire to maintain the package, they should immediately be added as a comaintainer (not necessarily a primary maintainer) and let go about their maintenance while the rest of the process is settled. A pre-existing comaintainer may ask that the reporter be denied this access (such as if they misbehave) in the ticket and it will be revoked until the rest of the process is concluded.
I think we should default to assuming that our packagers will act in good faith and that we want packages to be under active maintenance at all times. Having a multiple-week process to get the package into the hands of someone interested in working on it is actively harmful to Fedora (both because the package is rotting and because we're introducing unnecessary hurdles in front of the people who want to actually do the work).
According to our procedure, the ticket is approved after exactly one week if there's only positive votes. I dig what you are saying, but: - a week is not that long - we ask existing co-maintainers to voice their opinion if they disagree, and we have to give them some time. I think we need some fixed period. It could be three days or such, but probably not shorter. I think it's reasonable to make it one week, the same as the vote, for simplicity and consistency. The ticket if filed, the clock starts ticking, 7 days later the issue is formally decided and the reporter can get co-maintainer rights.
I just hate introducing delays when the overwhelmingly common case will actually be "this person wants to step in and do the work". I think it's probably okay if (in the rare cases where the existing comaintainers disagree), we roll back any changes this person makes, rather than forcing them to wait an arbitrary period.
Note that I'd +1 if we make it 3 days instead of 7.
I don't think doing it immediately is reasonable, however if that would be the consensus here, I won't block it.
OK, +1 to making it 3 days in the new policy. (That's what we have now, btw.)
We have discussed this today on FESCo meeting:
AGREED: APPROVED (+9, 0, -0) (ignatenkobrain, 15:49:18) ACTION: zbyszek to prepare a PR (zbyszek, 15:49:27)
@zbyszek I'm leaving this open for now until you get PR.
Metadata Update from @ignatenkobrain: - Issue untagged with: meeting - Issue assigned to zbyszek
https://pagure.io/fesco/fesco-docs/pull-request/15
This is mostly done. I'll try to merge the doc PRs tomorrow. I put it on the agenda so we can discuss if there is anything further that needs to be done.
Metadata Update from @zbyszek: - Issue tagged with: meeting
We discussed this doing todays' FESCo meeting (2019-08-19). ACTION: zbyszek to send an announcement to devel-announce
Metadata Update from @zbyszek: - Issue untagged with: meeting
Metadata Update from @psabata: - Issue tagged with: meeting
@zbyszek Reminding you of the action above.
Thanks for the reminder. I didn't send it immediately because of https://pagure.io/fesco/fesco-docs/issue/17 (missing bugzilla templates).
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/KWJBPRU4ZTYEAYL4RDCTBVWOLU7PXOQR/ (the main to devel-announce is still awaiting approval...)
Metadata Update from @zbyszek: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.