Tell an old maintainer that somebody else is changing maintainership

[yajo]

Is your feature request related to a problem?
Some people remove other people's maintainership of modules. When that happens, the old maintainer is not even notified about that change.

Describe the solution you'd like
If some maintainer becomes unresponsive, it would be normal that another member can overtake maintainership of the module. However, at least, the old maintainer should be pinged, to let them know that their maintainership is being changed.

The bot should ping the old maintainer too.

Describe alternatives you've considered
Kindly asking the new maintainer to ping me when doing such changes. However, if the new maintainer rejects that request, there's nothing left to do. 🤷🏼‍♂️

Additional context
Quoting from OCA/calendar#73 (comment):

I don't feel in the obligation of warning you

As you can see, this problem is already happening. So I fear that anybody could remove me as a maintainer anytime without my knowledge or permission. 😨

Maybe another alternative would be to be able to define a github organization or team as maintainer. This way, when a worker leaves a company, the company still retains the maintainership automatically. That would fix one problem, but still somebody could steal your maintainership anytime.

[legalsylvain]

Hi. Thanks for your RFC.

I would prefer to avoid adding complexity where it is not required. (I am in a position where I consider that it is not up to a robot to solve relational problems between people.;-) )

In the case you mention, it is not an error, but a change without notification on purpose.
I think this can be solved with an "OCA Rule", without developing this feature.
On the other hand, it is still necessary that the PSC agree with this change, it can't be done "on the sly".

So I fear that anybody could remove me as a maintainer anytime without my knowledge or permission.

Well it is asking a question here :

• without knowledge : for me it's about respect and to avoid offending the ego of the former maintainer.
• without permission : do you think that a maintainer can prohibit this change ? I mean, for me, it's a choice of the PSC in definitive.

In a few word :
A) if the community agrees with your request (being pinged when removed from maintainers), then I think @pedrobaeza and others will agree to do so in the PR comment, and it can be defined as an OCA guideline to systematically ping the old maintainer.
B) Conversely, if the community does not agree, there is no need to develop this feature in the bot.

I'm for solution A personally.

What do you think ?

[pedrobaeza]

This is what is called in Spain "el perro del hortelano". Someone that is not bringing value to the module wants to block operations of the rest that continue supporting it. But do what you want. And the change is on a new version, not on the existing one, so I still don't think this is something impolite nor incorrect.

[yajo]

Hi @legalsylvain thanks for your comments. Indeed a guideline could be the easiest "fix" to this issue.

without permission : do you think that a maintainer can prohibit this change ? I mean, for me, it's a choice of the PSC in definitive.

Yes, I think the maintainer should have, in general terms, more privileges than the PSC. Because the PSC handles a lot of stuff and generally has less in-depth knowledge of the module itself. And the maintainer is involved in the development and maintainership of the module, so their decissions should have more weight than those of PSC.

If I wanted to remove maintainership of somebody else and he asked me to keep it (which is not the case at hand, as you see in OCA/calendar#73 (comment)), I should truly have strong objective and proven reasons to still proceed.

Someone that is not bringing value to the module wants to block operations of the rest that continue supporting it.

If you remove somebody else's permissions without notice, that can definitely be a block for them. I think that doesn't need any explanation.

However, please could you elaborate how a ping can be a block for your team? I don't understand that part. Thanks.

[pedrobaeza]

Tell me why do you want a ping of a new version for a module that you developed for a company in which you are not working anymore in. What are you going to do with that ping?

I'm not going to ping you on each module that you developed paid by Tecnativa and that we need to continue migrating/evolving. Are you going to migrate/evolve them instead of us?

[yajo]

Sorry, that doesn't answer my question.

[legalsylvain]

Yes, I think the maintainer should have, in general terms, more privileges than the PSC. Because the PSC handles a lot of stuff and generally has less in-depth knowledge of the module itself. And the maintainer is involved in the development and maintainership of the module, so their decissions should have more weight than those of PSC.

Well, that's really not a "bot" topic. But well, let's continue discuss.
I think the reverse. For me :

• PSC has global vision. (I agree no in-depth knowledge of a module, you're right).
• PSC are "elected" by the community. (in an informal election on the mailing list, I must confess. maintainers are not elected).
• For me PSC delegates maintenance to maintainers, if they are agree. (that's very great, specially to allow to merge trivial migration module, fast tracking patch and bugfixes, etc...)

I don't think that maintainers status is definitive. In fact, if maintainer and PSC are not agree, PSC win.

@pedrobaeza : a ping in a comment doesn't cost much, can we consider doing this when we change maintainer ? something like "FYI : @old_maintainer".

[pedrobaeza]

I don't think it brings any value, except noise and possible blockings on political discussion. If a maintainer is still active, they will see the same the pull requests (it's not done through a direct commit), and can review it. And in this case, an old employee that has made hundred of pull requests under Tecnativa is a bureaucracy overload on our part.

[yajo]

I see your points @legalsylvain and I think I'll have to give it a round or two in my mind.

• PSC are "elected" by the community. (in an informal election on the mailing list, I must confess. maintainers are not elected).

Interesting point indeed.

* For me PSC **delegates** maintenance to maintainers, if they are agree. (that's very great, specially to allow to merge trivial migration module, fast tracking patch and bugfixes, etc...)

I don't think that maintainers status is definitive. In fact, if maintainer and PSC are not agree, PSC win.

I'm not sure to see it like that. The PSC doesn't delegate. It's the maintainer who volunteers more usually.

If it were like you said, then the maintainer should attempt to become a PSC just to be able to make more decisions over the modules he's already maintaining. We'd have more PSC that only care for some modules (which would be pretty similar to a maintainer after all).

The model is weird though, I guess that's why these concerns arise.

In any case, regarding the issue at hand, I'm seeing that the guidelines are already stated here:

PSC may remove maintainers who do not follow OCA rules or fail to their maintenance duties. Such action must be taken in coordination with the board.

That puts an end to the discussion. Thanks everyone!

[legalsylvain]

I'm not sure to see it like that. The PSC doesn't delegate. It's the maintainer who volunteers more usually.

personal feeling, as PSC of OCA/pos :

• I agree that most of the time, maintainers are volunteers (even if sometime I ask to contributors to set them as maintainers of new modules)
• I have more responsibilities that maintainers. If CI is red, (or worse, if the CI is green, but the point of sale is broken), or if two modules are incompatible : -> It's for me !
• I really see it as a delegation, to avoid to be pinged for merge, each time a maintainer make a bugfix.

[sbidoul]

I've not fully read all posts here, but I'd find it normal that the bot should mentions the existing maintainer when one changes the maintainer.

Of course it is a PSC responsibility to "validate" all changes to the maintainers key and make sure the transition is made harmoniously.

So I'd +1 to keep this issue open and eventually implement it.

[yajo]

Yes, I guess the issue is a valid enhancement in any case. Let me reopen. Thanks!