The current undertaker policy for activity/retirement is geared towards the undertakers and provides no specific tasks a developer can complete to ensure retirement isn't carried out (after the point of a notice email, all decisions are at the judgement of an undertaker). The rationale provided for such a short period of perceived inactivity (from discussions in 2012 and 2019) seem to be: * that a gentoo commit key may have been compromised * that packages may be going stale and are no longer looked after For the security rationale to hold up, there should be data to indicate the number of times a commit key has been lost/abused, and how many of those times were from developers deemed inactive versus active. I haven't been able to locate those statistics for this project, which means this is likely based upon an assumption and/or a knee-jerk reaction to an incident at the time it was established. As to packages going stale, this is a concern, but removing developers doesn't seem like a beneficial solution, it simply reduces the pool of people who've passed the bar to help fix the problem. Both these rationales can be dispelled by a developer proving their responsiveness such as by an email or response on their bug, which the undertakers themselves have suggested would be enough, but this is not enshrined in the policy and has not always proven to be the case. Activity is seemingly determined from number/frequency of commits, which is a poor metric for benefit added to the project. Even by number of commits, the time given for developers to indicate activity is still quite low ([1] indicates several developers who were inactive for a year or more who still contribute to the project). This metric incentivises making commits to the tree over caution with new commits, and it penalizes several classes of developer, those who look after: * a particularly rare architecture * a small number of packages * very old packages with few updates These will all decrease the diversity of the project, and in doing so, remove one of its key advantages as a project: that small, rare, difficult-to-package software may still be available. It also will not change whether the package is maintained or not, but worse, may disenfranchise the one person who would have been able to maintain if they'd found more time in the future. Currently this policy will likely result in: * unnecessarily reducing the developer population of Gentoo * discouraging new developers from joining Gentoo * increasing the maintenance costs on remaining developers * reducing the tree size to only the most common of packages I'd request that the the policy therefore: * should have the time period used to determine inactivity reviewed * the actions a developer can take to prove their activity should be clearly documented * should have a paragraph added highlighting the impact that the undertakers can have on the morale of the community, that the spirit of the policy should be considered during enforcement, and enforcement should only be carried out if it would enrich and benefit the community. [1] https://qa-reports.gentoo.org/output/dev-timeline.html
Can't seem to assign this to the undertakers project, so I'm assigning it to its parent project.
I'm sorry that I haven't found time to reply to this yet. I'll try to get to write a complete response sometime soon.
Before I start discussing this further, I would like to request some clarification on your points. (In reply to Mike Auty from comment #0) > Currently this policy will likely result in: > > * unnecessarily reducing the developer population of Gentoo Do you have any data to support the claim that reduced developer population is a bad thing? Given that you've just rejected arguments based on no apparent data, shouldn't you give an example and support your claims with proper data? > * discouraging new developers from joining Gentoo Do you have any proof that 'new developers' are 'discouraged' by retirement of inactive developers? I fail to see the connection here. > * increasing the maintenance costs on remaining developers Again, do you have any data to support that? If not, I'd argue that -- pretty much by definition -- inactive developers have negligible effect on maintenance costs. > * reducing the tree size to only the most common of packages How is that a problem? Do you have any data to support that retirement strictly causes 'less common' packages to be removed? And comparatively, data that proves that keeping inactive developers for a longer time improved persistence of packages in good quality? To be honest, my experience shows that retiring developers usually results in identifying *broken* packages that were under the radar before. While you could argue it means we have less packages, I doubt our users benefit from packages that don't work.
Taking another few minutes to answer other parts of your post. (In reply to Mike Auty from comment #0) > The current undertaker policy for activity/retirement is geared towards the > undertakers and provides no specific tasks a developer can complete to > ensure retirement isn't carried out (after the point of a notice email, all > decisions are at the judgement of an undertaker). I disagree. The policy is focused on being 'qualitative'. This means that Undertaker is supposed to make judgement whether a developer is active or not based on all data available to him. The policy merely provides some common examples where that data can be found. If developer is doing other meaningful activity that either is not covered in the policy, or was missed by the Undertaker, there is nothing stopping him from informing the Undertakers about it. Of course, the final judgement whether this activity really qualifies as 'developer work' is up to the Undertaker but then, the developer has the right to appeal. I don't see a better solution. In the best case, it's just going to shift 'being unfair' from one group of developers to another. > The rationale provided for such a short period of perceived inactivity [...] Why do you claim that over a year is 'short'? > (from discussions in 2012 and 2019) seem to be: > > * that a gentoo commit key may have been compromised > * that packages may be going stale and are no longer looked after You can also consider the social effects ('being fair') on old developers continuing to try to officially represent the project even if they do not actually have any real impact on the distribution. > For the security rationale to hold up, there should be data to indicate the > number of times a commit key has been lost/abused, and how many of those > times were from developers deemed inactive versus active. I haven't been > able to locate those statistics for this project, which means this is likely > based upon an assumption and/or a knee-jerk reaction to an incident at the > time it was established. Yes, it is a general assumption that each active developer account is a potential entry point, and therefore the more developers, the less secure the project is. Of course, the curve flattens with large number of developers but still. > As to packages going stale, this is a concern, but removing developers > doesn't seem like a beneficial solution, it simply reduces the pool of > people who've passed the bar to help fix the problem. Why are you assuming that people need to be Gentoo developers in order to fix the problem? Can't they submit a fix without developer privileges? Can't they proxy-maintain packages? > Both these rationales can be dispelled by a developer proving their > responsiveness such as by an email or response on their bug, which the > undertakers themselves have suggested would be enough, but this is not > enshrined in the policy and has not always proven to be the case. Do you have evidence to prove that developers will answer truthfully, if the alternative is being retired? My experience proves otherwise. Yes, we had developers claiming that they have their keys, and shortly afterwards requesting reset because they turned out to be lost after all. > Activity is seemingly determined from number/frequency of commits, which is > a poor metric for benefit added to the project. Even by number of commits, > the time given for developers to indicate activity is still quite low ([1] > indicates several developers who were inactive for a year or more who still > contribute to the project). No, that is not the only metric used. In fact, we have developers without commit access, so obviously they would all be retired by now if that was the only metric. > This metric incentivises making commits to the tree over caution with new > commits, and it penalizes several classes of developer, those who look after: > > * a particularly rare architecture > * a small number of packages > * very old packages with few updates Why do you believe that people contributing in this way need developer status, or even commit access?
Thanks for getting back to me. (In reply to Michał Górny from comment #3) > Do you have any data to support the claim that reduced developer population > is a bad thing? I don't have hard data (I wouldn't know where to go to collect it, or what data in particular would be accepted and what would be dismissed), so I'm working off of logical conclusions: * I previously used to enjoy Gentoo for its wealth of packages (quality or not) * There are no longer that many packages * There are *likely* fewer maintained packages due to fewer developers * Therefore fewer developers are bad for the project. To be fair, you haven't provided any data countering my claim, so we're still at the point of a hypothesis. > Do you have any proof that 'new developers' are 'discouraged' by retirement > of inactive developers? I fail to see the connection here. > I would say that, without conducting research and polls on the general populace to determine if they've been discouraged, that there will be little data available to discern this hypothesis. Lack of data doesn't mean it's not true, or that it's not worth considering properly. These points honestly feel beside the point, and simply to try to portray my later request for data concerning security breaches as ridiculous. > Again, do you have any data to support that? If not, I'd argue that -- > pretty much by definition -- inactive developers have negligible effect on > maintenance costs. Firstly, you just got through saying "Given that you've just rejected arguments based on no apparent data, shouldn't you give an example and support your claims with proper data?" and then done exactly that. Secondly maintaining a package (any package) has a higher chance with more developers (who can come back and manage packages) than not. Proxy-maintainers by definition are not developers and require a developer as well as a proxy-maintainer. You've also assumed a shared agreement on what "inactive" means, and that's what I've requested this policy review for. > > * reducing the tree size to only the most common of packages > > How is that a problem? Do you have any data to support that retirement > strictly causes 'less common' packages to be removed? And comparatively, > data that proves that keeping inactive developers for a longer time improved > persistence of packages in good quality? When I first joined, the main benefit of Gentoo for me was that I could easily put together ebuilds to try out new software, and that because it was so easy to do there was a thriving portage tree with lots of packages that I may not have been aware of, but could try. I didn't require the level of quality that you're asserting is necessary, but any work that others had done I could take further. This isn't everybody's use case, but neither is the view you're presenting that persistence of packages had to be "in good quality". You've skewing my request with your own perspective. > To be honest, my experience shows that retiring developers usually results > in identifying *broken* packages that were under the radar before. While > you could argue it means we have less packages, I doubt our users benefit > from packages that don't work. "My experience shows" and "I doubt"s again conflict with your earlier request for data, reinforcing my view that that was just rhetoric to make a point. If your point was that requesting data is unreasonable, please say that rather than resorting to childish tactics. > If developer is doing other meaningful activity that either is not covered > in the policy, or was missed by the Undertaker, there is nothing stopping > him from informing the Undertakers about it. Of course, the final judgement > whether this activity really qualifies as 'developer work' is up to the > Undertaker but then, the developer has the right to appeal. From personal experience the appeals process was difficult, unclear and still appeared dependent on the single team. I never had a response from the council, or from comrel, my retirement bug was not closed when I carried out activity, and now this bug is being handled by the group who I am directly concerned about. This is a conflict of interests (and one of the reasons I assigned the ticket to comrel rather than retirement, as the parent group responsible). > I don't see a better solution. In the best case, it's just going to shift > 'being unfair' from one group of developers to another. I'm not sure how giving more time is less fair to another group of developers. > Why do you claim that over a year is 'short'? Why do you not? That's exactly the point of this discussion. To figure out what's a reasonable length of time. > You can also consider the social effects ('being fair') on old developers > continuing to try to officially represent the project even if they do not > actually have any real impact on the distribution. Either someone is not participating, or they are participating (and providing their knowledge and experience). I don't see a social effect of someone still participating from still participating? You're applying a judgement value to what you class as "real impact". > Yes, it is a general assumption that each active developer account is a > potential entry point, and therefore the more developers, the less secure > the project is. Of course, the curve flattens with large number of > developers but still. Ok, I'm glad we're agreed this is an assumption. Again, this is now a judgement call over whether the (perceived, because we don't have the data) rare value is high enough against the more common cost of discarding developers who we've spent time training up and who have the experience of looking after packages, who may decide to do that again in the future, and how long that period of time before the risk is too high should be (and the social impact of unhappy developers as they see their ranks being retired). > Why are you assuming that people need to be Gentoo developers in order to > fix the problem? Can't they submit a fix without developer privileges? > Can't they proxy-maintain packages? Proxy-maintaing packages still requires a developer. They can't do it without them, so whilst it's not strictly necessary, it is easier. To see if this case holds up under extrapolation, by the simple idea provided could we get by with a single Gentoo Developer and all the other current developers becoming proxy maintainers? I suspect that would pose a problem. > Do you have evidence to prove that developers will answer truthfully, if the > alternative is being retired? My experience proves otherwise. Yes, we had > developers claiming that they have their keys, and shortly afterwards > requesting reset because they turned out to be lost after all. Again, you're assuming that we can't cope with things like lost keys. The views being expressed here are changing the environment to be one of paranoia. Why should we trust undertakers to listen and stop proceedings against developers who say they're still active? It's the point of appeals policies and of review of policies. It's because you *can't* trust that people will behave correctly, but you *can* cope when it does happen. A degree of trust is required, as is the ability to survive that trust being broken. > > Activity is seemingly determined from number/frequency of commits, which is > > a poor metric for benefit added to the project. Even by number of commits, > > the time given for developers to indicate activity is still quite low ([1] > > indicates several developers who were inactive for a year or more who still > > contribute to the project). > > No, that is not the only metric used. In fact, we have developers without > commit access, so obviously they would all be retired by now if that was the > only metric. Great, but the process isn't transparent, so that doesn't help. I'm trying to get the metric well defined, visible and acceptable by all. I've even provided data here, but the data hasn't been challenged, so the core point I've been making (that developers can come back and be useful/productive after being retired) seems to have been accepted. I want to ensure that doesn't get lost in the conversation. > Why do you believe that people contributing in this way need developer > status, or even commit access? Why do you not? You can question each point I make, but I have reason to make it. It may well not fit with the current view, but that's because I'm explicitly asking for a change. Honestly, I don't have the data, but I believe we have far fewer packages than in the past. You're going to say "why does that matter if they weren't well maintained?" and I'm going to say "because I didn't need them well maintained, I needed to know they existed, that someone had done the bulk of the work to get them going at some point and they were right there in the tree rather than scrabbling through a billion overlays with other things I didn't want". I've already said it's not everyone's use case, but I doubt I was the only one with that use case. Given that both of us are directly involved (since you tried to retire me which is what sparked me to request this review), I'm afraid I don't trust your impartiality and I'd appreciate it if you could recuse yourself from commenting on this further (bar answering questions I've posed if you feel the need), and hand it to another member of the retirement team or wider comrel please.
Some of the topics started repeating, so I'm only going to answer to first occurrence of each of them. (In reply to Mike Auty from comment #5) > (In reply to Michał Górny from comment #3) > > Do you have any data to support the claim that reduced developer population > > is a bad thing? > > I don't have hard data (I wouldn't know where to go to collect it, or what > data in particular would be accepted and what would be dismissed), so I'm > working off of logical conclusions: > > * I previously used to enjoy Gentoo for its wealth of packages (quality or > not) > * There are no longer that many packages Can you name a few examples of packages that a) you used to enjoy, b) were removed due to lack of downstream maintainer? I'm specifically asking for cases where downstream maintenance effort would prevent them from being removed, not e.g. packages that were discontinued upstream and would have been removed anyway. > * There are *likely* fewer maintained packages due to fewer developers There is no technical connection between the previous points and this point. Also, you were referring to overall count of packages before, and you've switched to *maintained* packages here. I could bring a counter-hypothesis that more developers can find a larger number of broken packages, and therefore could result in more packages being removed. By reductio ad absurdum, if we had no developers, nobody would be removing packages ;-). > > Do you have any proof that 'new developers' are 'discouraged' by retirement > > of inactive developers? I fail to see the connection here. > > > > I would say that, without conducting research and polls on the general > populace to determine if they've been discouraged, that there will be little > data available to discern this hypothesis. Given that the majority of retirements affect inactive developers, and are not publicly announced (besides the 'up for grabs' mails), I honestly doubt most of the candidates are *even aware* of people being retired. As a recruit once, I don't really recall even considering to look for such data, and I don't think there is a reason why it would occur to recruits to check that. > These points > honestly feel beside the point, and simply to try to portray my later > request for data concerning security breaches as ridiculous. I was merely trying to point out that if you (pre-)reject some arguments based on lack of empirical data, you shouldn't at the same time push your arguments without such data. > > Again, do you have any data to support that? If not, I'd argue that -- > > pretty much by definition -- inactive developers have negligible effect on > > maintenance costs. > > Secondly maintaining a package (any package) has a higher chance with more > developers (who can come back and manage packages) than not. The very low adoption rate of maintainer-needed packages among existing developers (including developers who maintain very few packages) proves otherwise. > Proxy-maintainers by definition are not developers and require a developer > as well as a proxy-maintainer. This is a very narrow view of proxied maintenance. The important question is about long-term effort due to a developer committing stand-alone vs via proxy. If the developer commits good quality packages, the overhead of proxy is minimal. On the other hand, if developer is not up-to-date with standards or doesn't have much recent experience (I think it is reasonable to claim that developers who do little ebuild work forget some of it), then direct commit access can actually cause more work for others than proxying. Ensuring that problems are fixed before committing is better both for users and for the necessity of cleaning up afterwards. > > If developer is doing other meaningful activity that either is not covered > > in the policy, or was missed by the Undertaker, there is nothing stopping > > him from informing the Undertakers about it. Of course, the final judgement > > whether this activity really qualifies as 'developer work' is up to the > > Undertaker but then, the developer has the right to appeal. > > From personal experience the appeals process was difficult, unclear and > still appeared dependent on the single team. I never had a response from > the council, or from comrel, my retirement bug was not closed when I carried > out activity, I'm sorry but I'm not aware of any appeal being done by you. Please do not supply false information when you actually haven't gone through the process (or were eligible for it in the first place). > and now this bug is being handled by the group who I am > directly concerned about. This is a conflict of interests (and one of the > reasons I assigned the ticket to comrel rather than retirement, as the > parent group responsible). I'm sorry but AFAIU you have requested discussion on the policy, not an appeal. I don't understand why you'd discuss it with a body *other than* the one actually maintaining the policy in question. Furthermore, you said: > Can't seem to assign this to the undertakers project, so I'm assigning it to its parent project. ...so the bug was reassigned following your request. > > Why do you claim that over a year is 'short'? > > Why do you not? That's exactly the point of this discussion. To figure out > what's a reasonable length of time. I'm sorry but wasn't this bug filed just after the time has been *doubled*? I don't it's valid to claim that the time is too short if the time even couldn't physically pass for anyone yet. > > > Activity is seemingly determined from number/frequency of commits, which is > > > a poor metric for benefit added to the project. Even by number of commits, > > > the time given for developers to indicate activity is still quite low ([1] > > > indicates several developers who were inactive for a year or more who still > > > contribute to the project). > > > > No, that is not the only metric used. In fact, we have developers without > > commit access, so obviously they would all be retired by now if that was the > > only metric. > > Great, but the process isn't transparent, so that doesn't help. I'm trying > to get the metric well defined, visible and acceptable by all. My last attempt to make the process more transparent has met much opposition. This is very close to being judged in public, and developers do not want that. > Given that both of us are directly involved (since you tried to retire me > which is what sparked me to request this review), This is an unfair accusation. I have merely questioned you since you seemed inactive. There is a far way from status ping to retirement. Attempting to conflate the two seems entirely unjustified, and like an attempt to make this debate emotional rather than technical. > I'm afraid I don't trust > your impartiality and I'd appreciate it if you could recuse yourself from > commenting on this further (bar answering questions I've posed if you feel > the need), and hand it to another member of the retirement team or wider > comrel please. I don't believe this to be a professional response to the problem. When you disagree with someone, you don't get to request other people till you find someone who happens to agree with you. The bug is open for all Undertaker team members, and they can enter the discussion as they see fit / their time permits. If you believe that there is a need to appeal the policy, feel free to file an appeal to the parent project. However, in this case please indicate specifically what needs to be changed and to what instead of requesting general discussion.
(In reply to Michał Górny from comment #6) > Can you name a few examples of packages that a) you used to enjoy, b) were > removed due to lack of downstream maintainer? I'm specifically asking for > cases where downstream maintenance effort would prevent them from being > removed, not e.g. packages that were discontinued upstream and would have > been removed anyway. app-emulation/vmware-workstation, as an example. > > * There are *likely* fewer maintained packages due to fewer developers > > There is no technical connection between the previous points and this point. > Also, you were referring to overall count of packages before, and you've > switched to *maintained* packages here. Ok, but the treecleaners try to keep these things in sync, so regardless of whether we're talking maintained packages or unmaintained packages, fewer developers means fewer packages. > I could bring a counter-hypothesis that more developers can find a larger > number of broken packages, and therefore could result in more packages being > removed. By reductio ad absurdum, if we had no developers, nobody would be > removing packages ;-). Yep, awesome. So glad to be spending my time trying to discuss this with you. > Given that the majority of retirements affect inactive developers, and are > not publicly announced (besides the 'up for grabs' mails), I honestly doubt > most of the candidates are *even aware* of people being retired. As a > recruit once, I don't really recall even considering to look for such data, > and I don't think there is a reason why it would occur to recruits to check > that. I think the overall morale of the project deteriorates when they're dictated to by a very small group of people who have prioritized quality as the goal of the project. I think prospective new developers pick up on that from the chats that are public, the enthusiasm of the other developers, and you can see the results in the lack of new developers and the length of time developers stay (from the link I posted in the original message). > I was merely trying to point out that if you (pre-)reject some arguments > based on lack of empirical data, you shouldn't at the same time push your > arguments without such data. I asked for the data I needed (see email of 14/09/2019, 02:45 BST titled Tenative Retirement list for August), and have yet to be able to be told how many compromises have resulted from lost developers keys. I'm trying to get the empirical data, what you seemed to be trying to do was distract from the point I was making. > > Secondly maintaining a package (any package) has a higher chance with more > > developers (who can come back and manage packages) than not. > > The very low adoption rate of maintainer-needed packages among existing > developers (including developers who maintain very few packages) proves > otherwise. This ignores all other factors, such as how nice an environment it is, how much time is spent dealing with policies rather than achieving goals and whether people still have faith in the leadership to continue going in the same direction as them. > > Proxy-maintainers by definition are not developers and require a developer > > as well as a proxy-maintainer. > > This is a very narrow view of proxied maintenance. The important question > is about long-term effort due to a developer committing stand-alone vs via > proxy. If the developer commits good quality packages, the overhead of > proxy is minimal. So, what's the argument for a good (proxy-)developer to proxy maintain rather than actually becoming a fully fledged developer. Again, I refer to the argument that was dismissed with reductio ad absurdum; that replacing developers with proxy-maintainers should have a reason and that that reason hasn't been made clear yet. Why are proxy-maintainers who are the level of a dev not made devs, and if they're not the level of a dev, then there needs to be a dev to get their code to the quality it needs to be, meaning there's still a need for devs. > On the other hand, if developer is not up-to-date with standards or doesn't > have much recent experience (I think it is reasonable to claim that > developers who do little ebuild work forget some of it), then direct commit > access can actually cause more work for others than proxying. Ensuring that > problems are fixed before committing is better both for users and for the > necessity of cleaning up afterwards. This implies that making mistakes in ebuilds maintained by a maintainer are not that maintainer's problem? They are. They do not need someone else stepping in, there is no pre-requisite on perfectionism to be a dev. If they're poorly maintaining a package, but they're maintaining it, that's on them. If they're doing so bad a job, then the council or proctors or whoever's appropriate can step in. If someone feels like fixing it for them, that's for them to do, but they're volunteering to do that. > I'm sorry but I'm not aware of any appeal being done by you. Please do not > supply false information when you actually haven't gone through the process > (or were eligible for it in the first place). You're correct, my mistake, it was not an appeal. You're right, I would have had to wait until 1 month before I was due to be retired, if I disagreed with a decision to start my retirement 3 months earlier. I again, ask that the policy be reviewed. > I'm sorry but AFAIU you have requested discussion on the policy, not an > appeal. I don't understand why you'd discuss it with a body *other than* > the one actually maintaining the policy in question. Furthermore, you said: That really depends on the trust in the team, and I'm sorry to tarnish the whole team based on my interactions with a very few individuals from within it, but essentially I've had bad interactions with at least one member of that team previously so I felt going to their parent group would be more productive. > > Can't seem to assign this to the undertakers project, so I'm assigning it to its parent project. > > ...so the bug was reassigned following your request. That's the second time you've constructed a request out of a statement. The first time was during the retirement bug. Seemingly, rather than trying to be diplomatic and tactful, I should avoid providing reasons that would allow both sides to save face, and instead directly state that I distrust the bulk of the team to respond, and I distrust the views of the small part of the team that I've interacted with so far, and that this is the exact reason I'm trying to get the policy reviewed. > I'm sorry but wasn't this bug filed just after the time has been *doubled*? > I don't it's valid to claim that the time is too short if the time even > couldn't physically pass for anyone yet. I don't know what happened to the policy when this was filed, but surely if the time had just been doubled then, I'd have already had the retirement process started against me (since I'd nearly be coming up to twice the previous limit on lack of commits)? > My last attempt to make the process more transparent has met much > opposition. This is very close to being judged in public, and developers do > not want that. It sounds as though your attempt confused the process (what *should* happen in general) to actual instances (what happens involving specific people). My point may have been unwarranted though, the guidance is very clearly laid out, apart from the points I detailed at the start of this bug, where the developer in question has no form of recourse (until 1 month before the date of actual retirement). > > Given that both of us are directly involved (since you tried to retire me > > which is what sparked me to request this review), > > This is an unfair accusation. I have merely questioned you since you seemed > inactive. There is a far way from status ping to retirement. Attempting to > conflate the two seems entirely unjustified, and like an attempt to make > this debate emotional rather than technical. There is no accusation, you did begin proceedings to retire me, it did cause me to request this review, and both of us are directly involved. Also, your questioning was aggressive (as I found your reply to this bug), my response was not enough to halt the process as had been mentioned earlier (check the retirement bug for mention of the email where you yourself told me that was what you expected to happen), and it presumes that all developers have the same cultural sentiments and will not be upset or distressed at being warned that they're going to be retired, despite having replied, unless they make commits. It creates a very hostile and negative environment, which is why I'm taking the time to try and improve it by asking for a review of this policy. > > I'm afraid I don't trust > > your impartiality and I'd appreciate it if you could recuse yourself from > > commenting on this further (bar answering questions I've posed if you feel > > the need), and hand it to another member of the retirement team or wider > > comrel please. > > I don't believe this to be a professional response to the problem. When you > disagree with someone, you don't get to request other people till you find > someone who happens to agree with you. The bug is open for all Undertaker > team members, and they can enter the discussion as they see fit / their time > permits. I didn't request other people, I requested any one other person. When you find yourself in a conflict of interest and unable to resolve your differences it is entirely professional to request an arbitrator. This bug is open for other undertakers and I was appealing for one of them to enter the discussion to gauge whether your response is merely your opinion or the opinion of the whole team. Spending my time replying to semantic points is not what I would class as useful for this project, but I believe the health of the project is dependent upon how its members are treated and whether they are happy. I was not happy, I'm trying to resolve that and since we clearly disagree but dance around pedantry rather than genuinely discussing the points raised, this seems futile and I'm trying to push the process forward. If you want, you can leave this ticket sit open. If you'd like you can mark it as WONTFIX, but instead you're arguing with me, for what purpose? Are you actually after clarification of the minutiae you've been asking about? Have any of the points I've been making caused you to even just reconsider your position? > If you believe that there is a need to appeal the policy, feel free to file > an appeal to the parent project. However, in this case please indicate > specifically what needs to be changed and to what instead of requesting > general discussion. This was the appeal, it was filed with the parent project and it does indicate specifically what needs changing (see the bullet points of https://bugs.gentoo.org/699344#c0). I'm not sure that doing the same thing again will lead to different results...
Ok, I do understand what you're requesting now though I don't really understand why you didn't say it straight but instead chosen to discuss something else entirely. So I understand that you're concerned that Undertakers are pinging people early, and you conflate early status pings with retirement. I'm sorry but your proposed change isn't beneficial. I don't think most of the developers would prefer learning that you're going to be retired last minute. Sure, it would save a few mails in some cases, while in others it would result in developers being retired since they weren't given sufficient time to reply to retirement mails.
