A proper activity policy should be decided upon by Operations to be honest.

Yes, as I said this is just a report detailing activity, it does not mention any actionable.

I propose that if someone has no activity for more than month, and has not informed the sysadmin team of their temporary leave before, their sysadmin status should be suspended (if the person wishes to return they will be subject to a new access request)

I think out of the 4 "categories" of activity (on-wiki doesn't really count so that's why it's 4 and not the 5 listed above) if 2 or more are "NO", that counts as inactive.

In addition, all Operations members should discuss the matter of the person who is inactive, before any permissions are removed.

What do you think?

Well, on-wiki kinda counts for me, as managing finances are a decent part of my contributions here. But not from an ops standpoint.

Honestly, I don't mind either way if you want to revoke my server access; I can always request it again if I need it. And I don't really need that to do extension reviews. The main thing I've used it for in the past is to kick the task runner, since I stopped doing the extension installs.

https://meta.miraheze.org/wiki/User:Reception123/Sysadmin_inactivity_policy_draft

Thoughts?

+1, though should probaly make it easier to rejoin if they want to come back :) (as long as no one rejects)

In T3030#56912, @Paladox wrote:

+1, though should probaly make it easier to rejoin if they want to come back :) (as long as no one rejects)

The wording seems to be not all ops have to agree, like normal requests, so it’s easier than currently.

But the draft looks good.

@Southparkfan @NDKilla ^ any issues with the draft proposal?

My points:

• A week counted as inactivity? That's a bit short. Depending on what you call inactivity (I read IRC logs and my mails daily, yet I haven't taken part in discussions because I am busy enough in real life.) that part should be rewritten (or at least be more clarified).

but if one of the Ops members feels like they should not be part of the sysadmin team again, then they may not be re-added.

• If someone decides to rejoin, one oppose against five supports = no support?

In T3030#56940, @Southparkfan wrote:

My points:

• A week counted as inactivity? That's a bit short. Depending on what you call inactivity (I read IRC logs and my mails daily, yet I haven't taken part in discussions because I am busy enough in real life.) that part should be rewritten (or at least be more clarified).

It’s a month. A week has not been mentioned in the draft at all.

but if one of the Ops members feels like they should not be part of the sysadmin team again, then they may not be re-added.

• If someone decides to rejoin, one oppose against five supports = no support?

That’s how we do all access requests now. And I think it’s more to incite discussion because if someone has legitimate concerns regarding such a trusted role with access to private data, it has to be considered and can’t be ignored because “there’s more support than opposes”.

What @Southparkfan meant was where it says that you should notify sysadmins of long-term inactivity "(i.e a week)", but that was just an example, I will modify it to two weeks, but it still just remains an example.

And yes, afaik all new access requests are the same, if everyone agrees but one until their concerns are addressed the person requesting may not become sysadmin.

In T3030#56943, @John wrote:

In T3030#56940, @Southparkfan wrote:

My points:

• A week counted as inactivity? That's a bit short. Depending on what you call inactivity (I read IRC logs and my mails daily, yet I haven't taken part in discussions because I am busy enough in real life.) that part should be rewritten (or at least be more clarified).

It’s a month. A week has not been mentioned in the draft at all.

but if one of the Ops members feels like they should not be part of the sysadmin team again, then they may not be re-added.

• If someone decides to rejoin, one oppose against five supports = no support?

That’s how we do all access requests now. And I think it’s more to incite discussion because if someone has legitimate concerns regarding such a trusted role with access to private data, it has to be considered and can’t be ignored because “there’s more support than opposes”.

Denying based on one oppose for whatever reason is to my knowledge definitely not how we evaluate access requests, unless the opposing staffer is able to provide a legitimate reason (but then they likely won't be the only opposing anyways, since others would oppose as well).

(actually, I read the draft again and realised the word "may" in the sentence has a different meaning than "must", I feel as a non-native English speaker these words are easy to confuse in such a sentence. So my second point might just be an interpretation error.)

In T3030#56947, @Southparkfan wrote:

In T3030#56943, @John wrote:

In T3030#56940, @Southparkfan wrote:

My points:

• A week counted as inactivity? That's a bit short. Depending on what you call inactivity (I read IRC logs and my mails daily, yet I haven't taken part in discussions because I am busy enough in real life.) that part should be rewritten (or at least be more clarified).

It’s a month. A week has not been mentioned in the draft at all.

but if one of the Ops members feels like they should not be part of the sysadmin team again, then they may not be re-added.

• If someone decides to rejoin, one oppose against five supports = no support?

That’s how we do all access requests now. And I think it’s more to incite discussion because if someone has legitimate concerns regarding such a trusted role with access to private data, it has to be considered and can’t be ignored because “there’s more support than opposes”.

Denying based on one oppose for whatever reason is to my knowledge definitely not how we evaluate access requests, unless the opposing staffer is able to provide a legitimate reason (but then they likely won't be the only opposing anyways, since others would oppose as well).

(actually, I read the draft again and realised the word "may" in the sentence has a different meaning than "must", I feel as a non-native English speaker these words are easy to confuse in such a sentence. So my second point might just be an interpretation error.)

It actually is, otherwise the following is not how we're meant to be doing things:

T2099#48956 "I could immediately reject/approve your request regardless of consensus"

This whole process designed to be based on equality (as that is how trust is built to those less knowledgable) so either everyone can reject regardless or no one can :)

Anyway, I don't think an Ops member would simply oppose the addition of someone, without them having a valid reason to do so.

And yes, everything is about interpretation, and even though this is a policy, discretion needs to be applied for each case.

In T3030#56949, @John wrote:

In T3030#56947, @Southparkfan wrote:

In T3030#56943, @John wrote:

In T3030#56940, @Southparkfan wrote:

My points:

• A week counted as inactivity? That's a bit short. Depending on what you call inactivity (I read IRC logs and my mails daily, yet I haven't taken part in discussions because I am busy enough in real life.) that part should be rewritten (or at least be more clarified).

It’s a month. A week has not been mentioned in the draft at all.

but if one of the Ops members feels like they should not be part of the sysadmin team again, then they may not be re-added.

• If someone decides to rejoin, one oppose against five supports = no support?

That’s how we do all access requests now. And I think it’s more to incite discussion because if someone has legitimate concerns regarding such a trusted role with access to private data, it has to be considered and can’t be ignored because “there’s more support than opposes”.

Denying based on one oppose for whatever reason is to my knowledge definitely not how we evaluate access requests, unless the opposing staffer is able to provide a legitimate reason (but then they likely won't be the only opposing anyways, since others would oppose as well).

(actually, I read the draft again and realised the word "may" in the sentence has a different meaning than "must", I feel as a non-native English speaker these words are easy to confuse in such a sentence. So my second point might just be an interpretation error.)

It actually is, otherwise the following is not how we're meant to be doing things:

T2099#48956 "I could immediately reject/approve your request regardless of consensus"

You have a good point there. I cannot recall for sure why I said that? As far as I know only the one holding a high(er) position on the project could override consensus, something we don't do frequently (for good reason).

We could keep discussing this but I feel that is off-topic for this particular task, so I will end it here (thus further discussion must take place somewhere else).

This policy seems fine to me.

Well, the policy can always be modified as we see fit.

Now we only need @NDKilla's input before we can move forward on this.

PuppyKun> +1 (again)

As the new policy is approved, and per this evaluation two members will be removed.

@labster will be maintain most access due to his position as legal owner and the need to be able to access control panels for payment and such. If server access is required again, feel free to re-request it.

@ImBoPhil has not answered and has been as the evaluation above shows, inactive. Same as above, if you wish to be active again, feel free to re-request.