Talk:Abstract Wikipedia/Staff editing

Staff edit transparency

I think it is important that it is clear in the edit summary if possible and at the user page of a staff member what the taks of a staff member are and what the person will edit with the expertise. I for myself think if a significant number of staff edits at the beginning will be necessary to speed up the development of functions, this is from my point of view a indicator that Wikifunctions is too complex. So I am not sure if it really serves the goal with supporting little language versions of the Wikimedia projects. Maybe it is better to have language dependent boilerplate templates for the most important topics at the beginning and taking then more time with the development of more specific functions and making it more language independent. In general I like the idea of Wikifunctions and hope that it will be a volunteer project and that the most edits will come from volunteers. I wish more workshops about Wikifunctions with specific small language versions or at regional meetings like the CEE meeting or WikiArabia or WikiIndaba. Hogü-456 (talk) 20:53, 28 September 2022 (UTC)

I agree - if after a few months there are still more staff edits than non-staff edit, I would consider that very problematic.

Regarding the "all staff edits need to be explicated in the edit summary": since all staff accounts will end in "(WMF)", would that be considered sufficient? Or does the actual edit summary also have to explicate it? This sounds like something that is easy to forget, and given that the accounts are already explicitly and visibly marked, can maybe be avoided. I'd rather have a naming policy for the staff accounts to make it clearer. DVrandecic (WMF) (talk) 23:50, 29 September 2022 (UTC)

I suggest staff actions must have an explicit link to a phabricator ticket (or equivalent). It is here that the rationale for staff resources can be provided. GrounderUK (talk) 15:16, 30 September 2022 (UTC)

That sounds very cumbersome. I was thinking, for example, a community member asks for help with implementing a function to do X, a staff member says "oh I can do that", and does it. There wouldn't be a phab ticket involved in that. -- DVrandecic (WMF) (talk) 23:56, 30 September 2022 (UTC)

I don’t think it is cumbersome. There would be no need for a separate ticket for each action, but there must be a separate ticket that authorizes each agreed type of staff action (per language community). That said, we should welcome contributions from staff members acting in a voluntary capacity. If they use their staff account for this, they should indicate that their edit is not in their capacity as a staff member. GrounderUK (talk) 08:16, 1 October 2022 (UTC)

I do not see a need to be that specific. I think it is enough if the working area is explained on the user page. On the other hand I would prefer staff to use another account when they edit in their volunteer capacity. --Ameisenigel (talk) 15:43, 3 October 2022 (UTC)

Agree! All Wikifunctions staff should not use their Wikifunctions staff account to do volunteer editing.

The proposal currently reads: "It is recommended to declare staff edits additionally in the edit summary, if possible." May I suggest to replace that with "Wikifunctions staff account have to follow a specific naming scheme. They have to end in '(Wikifunctions staff)'." or something like that. That would have the same effect, but would not be as easily forgotten. DVrandecic (WMF) (talk) 02:14, 20 October 2022 (UTC)

Sounds good to me --Ameisenigel (talk) 13:53, 20 October 2022 (UTC)

Since there thave been no other comments, I have changed the proposal as requested. --Ameisenigel (talk) 21:03, 27 October 2022 (UTC)

First draft

Since I think that it is easier to discuss things when you have a draft that can be discussed, I just added a draft there. I also tried to include what @Hogü-456: mentioned above. @everyone: Please bring in your thoughts and ideas as well. --Ameisenigel (talk) 11:04, 29 September 2022 (UTC)

Thank you so much! I agree, I think it is a great idea to start a draft. DVrandecic (WMF) (talk) 23:51, 29 September 2022 (UTC)

Apply for advanced rights

Regarding "All staff accounts are eligible to request advanced rights (e.g. sysop)": I have two kinds of thoughts on that:

1) I think I would suggest to automatically make all staff have such advanced roles, in particular because, e.g. deleting pages, editing locked pages, and some other rights, seem like something that would be helpful for staff in the beginning, and are usually attached to the sysop role.

2) Or we could, alternatively, create a new user role, and attach the relevant rights to that role. I.e. create a role "Wikifunctions staff" and attach all relevant rights to that. This would help with not making all staff admins, etc. (but still give them all necessary tools)

Just a comment. -- DVrandecic (WMF) (talk) 23:56, 29 September 2022 (UTC)

Staff is already a global user right. Is an extra level really needed? ♥Ainali ^talk_{contributions} 07:32, 30 September 2022 (UTC)

Despite the name, the +staff global user group exists for actions supporting Trust and Safety and Legal work, it's not a general group for staff accounts. Jdforrester (WMF) (talk) 18:10, 30 September 2022 (UTC)

Oh, maybe something more clearly named, like "wikifunctions-staff". I certainly didn't mean the existing staff role, my bad.

Also to make it clear, wikifunctions-staff edits should not be considered "office actions" or something. Those are different categories. -- DVrandecic (WMF) (talk) 23:58, 30 September 2022 (UTC)

Understood! :-) Jdforrester (WMF) (talk) 14:21, 5 October 2022 (UTC)

@Jdforrester (WMF) Perhaps a bit off-topic now, but if the global user group staff is for trust and safety and legal, why does it exist a local user group on meta for them too (Meta:WMF Support and Safety)? That seems redundant. ♥Ainali ^talk_{contributions} 10:58, 4 October 2022 (UTC)

@Ainali I don't know for sure, sorry. Jdforrester (WMF) (talk) 14:20, 5 October 2022 (UTC)

I have just looked at Wikidata, where we have a staff group. Altough we probably cannot easily compare these two projects, I would like to explain the situation. The staff group on Wikidata has many different advanced rights. Most users in that group never use sny of these rights. A few users just use things like marking pages for translation and very rarely someone deletes a page.

Maybe it would be helpful to discuss the concept for user rights in general: Are there plans for other user groups?

Personally I am not a fan of granting rights randomly without any need, I prefer to give people rights if they need them. --Ameisenigel (talk) 07:35, 30 September 2022 (UTC)

Understood, and a fair point. Here I would also consider that many of the rights wouldn't be used extensively. But we would have some new rights (such as people who can activate implementations), and that's something *in the beginning* would be helpful to locate with Wikifunctions staff, I think. Again, that should move to the community swiftly, too, but just to get things started or unclogged from time to time, it would be good for staffers to be able to use these rights. Just as in Wikidata, I would hope that this would become less and less frequent as the project and the community matures. -- DVrandecic (WMF) (talk) 00:01, 1 October 2022 (UTC)

I think that it might be helpful to have an idea how the concepts for user rights on Wikifunctions looks in general. You should probably not need to be an admin to do some advanced things and seperate user groups might be a good idea in these circumstances. --Ameisenigel (talk) 15:46, 3 October 2022 (UTC)

Yes, agreed. We are about to define these in the coming weeks, and will post a link here. DVrandecic (WMF) (talk) 02:15, 20 October 2022 (UTC)

staff-restricted

Hi @YULdigitalpreservation: Thank you for your idea. I would be interested to know what these staff-restricted areas would be. I cannot really think of such areas: If there are things that should not even be edited by users with advanced rights, they should probably not be editable through the interface at all and such changes should only be possible directly in the database (through Gerrit). --Ameisenigel (talk) 07:41, 30 September 2022 (UTC)

Hi @Ameisenigel Thanks for your response and questions. I am not sure what the staff-restricted roles might be. I read the update: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-09-27 and I wanted to participate in this process. My intention is to express interest in knowing which roles will be staff-restricted, and if any of them are expected to become open to community members at some point. YULdigitalpreservation (talk) 15:07, 30 September 2022 (UTC)

That is a good point. Maybe someone from the Wikifunctions team can give us more information about the plans. --Ameisenigel (talk) 21:09, 30 September 2022 (UTC)

Let's clear up a bit terminology: when I say "role" I mean "user group", and "right" "user right", as per the Mediawiki documentation. In short, a right is some specific thing that can be done, a role / group is something that an account can belong to and that has a set of rights.

I am not sure there is need for any staff-restricted rights. All rights should eventually (and rather swiftly) be open to the community. If we want, we might have a new group, wikifunctions-staff, that would be restricted to staff, and that have to follow this new policy. This would make it easy to write a single policy and manage those accounts, and we wouldn't need to make staff admins etc. with all the further connotation that entails.

So we could have a staff-restricted group, but I don't think we should have staff-restricted rights. Does this make sense? -- DVrandecic (WMF) (talk) 00:08, 1 October 2022 (UTC)

It makes sense for me not to have staff-restricted rights. If we want to have a staff user group, that would obviously be restricted to staff. --Ameisenigel (talk) 08:37, 1 October 2022 (UTC)

I removed the paragraph I had written about staff-restricted roles based on the clarifications from @DVrandecic (WMF) on this page. YULdigitalpreservation (talk) 15:38, 5 October 2022 (UTC)

Suggested additions

Here are a few suggested additions:

• Wikifunctions staff accounts are there to serve the community and the project. They should avoid controversial topics, and should focus on such areas where they help the community and the project inclusively. Wikifunctions staff account holders are invited to participate in controversial topics with their volunteer accounts and following volunteer guidelines like everyone else.
• Wikifunctions staff accounts are given and deactivated by the Wikimedia Abstract Wikipedia team. Not everyone with a staff account will necessarily be an employee of the Wikimedia Foundation, and not all Wikimedia Foundation employees are automatically getting a staff account.
• Wikifunctions staff account holders may or may not have a volunteer account, and they do not have to (but may) disclose what their volunteer account is, in order to preserve their pseudonymity if they so wish. But they are forbidden to interact with themselves in any patterns that reminds of sockpuppets, e.g. to interact with themselves in discussions without making that explicit. (Since Wikifunctions staff accounts should avoid controversial issues anyway, this situation should rarely occur in the first place)
• It is OK for the community to override, revert, and make edits to content by Wikifunctions staff account in most cases. These are not anything like office actions, and should not be regarded as unchangeable.
• The exception to that will be clearly marked in the edit and linked to a respective Phabricator task, and will only be used in cases where the stability of Wikifunctions or some other Wikimedia project is threatened. Examples of that would be the removal of a specific function or implementation because they cause unsafe runtime behavior or unreasonable load. Such Phabricator tasks will be prioritized by the team, and once closed the change becomes available for normal editing again.
• Whereas the different accounts should be kept separate, work edits should be only done with work accounts and volunteer edits only through volunteer accounts, it should be also acknowledged that mistakes will happen. Let's be lenient with these mistakes, particularly early on in the project and early on when a new staffer starts.

Please feel free to add these suggestions. DVrandecic (WMF) (talk) 02:44, 20 October 2022 (UTC)

Thank you for these ideas. I am fine with adding them, since they sound reasonable to me. What do others think? --Ameisenigel (talk) 14:00, 20 October 2022 (UTC)

Since there have been no other comments, I was bold and just added these suggestions to the proposal. Comments are still welcome. --Ameisenigel (talk) 21:05, 27 October 2022 (UTC)

Access to auto-translate as tool to contribute content?

is this feature available, or is this only top interpreters of "foreign" languages? Kinnonvolunteer (talk) 15:31, 5 November 2023 (UTC)

Hi. This is the talkpage for an unrelated policy-draft.

You may wish to see the documentation at mw:Content translation and perhaps re-ask your question at the talkpage there if the documentation doesn't help. If you do need to re-ask, it might also be helpful if you describe what you are trying to translate, and where (which wiki), as some wikis have different settings. I hope that information helps. Quiddity (WMF) (talk) 20:06, 6 November 2023 (UTC)