Wikiversity:Colloquium/archives/August 2018

Mediawiki JavaScript and CSS Editor Role

See meta:Creation of separate user group for editing sitewide CSS/JS. A new role is being added to the Mediawiki software to limit who can edit Mediawiki: .js and .css pages. No one will have this role by default. Bureaucrats will be able to add the role to someone based on community consensus. Due to security concerns, anyone with this role should have the same level of trust as a custodian or higher. We have two to three weeks to come up with an approach to assigning this new role. How does the community want to address this? -- Dave Braunschweig (discuss • contribs) 02:08, 10 July 2018 (UTC)[reply]

Proposed Approaches

Custodians or bureaucrats who request the role?
Custodians, bureaucrats, or curators who request the role?
Either of the above only after community discussion and consensus?
Anyone who requests the role only after community discussion and consensus?
Other?
Grandfather in custodians, who already have these rights (currently included in editinterface).
Add the role as needed, with a 24-hour expiration?

Discussion

1:Custodians or bureaucrats who request the role (Assuming that they will be given the role after community discussion and consensus.) --Luke Isham (discuss • contribs) 03:13, 10 July 2018 (UTC)[reply]

Per 1 above, I have entered or modified code in MediaWiki:Common.css about once a year on an as needed basis and would like to continue to have that option. I recently updated Wikiversity:Support staff for the most recent activity window. We have three currently active curators, three currently active custodians, but only two currently active bureaucrats. Keeping the current status seems to be working fine. Only two custodians have or are likely to need to enter or modify code: myself and Evolution and evolvability. Security concerns are minimal. My password is as strong as allowed. A security breach at Myspace allowed release of a no longer used password with no effect anywhere. Someone tried to use it to access Wikipedia twice and failed both times.
Per 2 above, specifically curators, unless one expresses interest, the current situation is working. The short-term availability of our other two bureaucrats and apparent lack of experience suggests no need for access to .js or .css.
Per 3, 4 & 5 above, if anyone with an extensive .js or .css experience can update these, community consensus and consideration would be a good idea on a contingency basis. --Marshallsumter (discuss • contribs) 17:31, 12 July 2018 (UTC)[reply]

Sounds good to me? I'd say grandfather in anyone who already has these rights, since that's not many people anyway, and then have an application process (after community discussion and consensus) for others that want these rights. Mvolz (discuss • contribs) 14:01, 26 July 2018 (UTC)[reply]

4, and I've added in 6, grandfather in those who already have the rights, which they'll otherwise lose access to (custodians). Mvolz (discuss • contribs) 15:21, 26 July 2018 (UTC)[reply]

If grandfathering is what the community wants, so be it. However, the meta proposal is specifically intended to reduce the risk footprint by not grandfathering in those who currently have the right, and instead only assigning it to those who need or intend to use it.

The meta proposal is largely stemming from en wiki and other larger wikis, which have a large number of admins. That's too many, but there do need to be a minimum number of people with these rights, at the very least who are active enough to revert or blank edits to these pages. But since there *are* very few, I agree it's not too high of a burden just ask them all individually if they want it. Mvolz (discuss • contribs) 07:11, 8 August 2018 (UTC)[reply]

I assumed that there would be those who are not currently custodians who would want this ability. Should we vote for them to have CSS/JS access, or should we ask them to apply for custodianship, since someone with CSS/JS rights should be at least as trusted as a custodian? -- Dave Braunschweig (discuss • contribs) 00:43, 27 July 2018 (UTC)[reply]

Personally I think they should be distinct, because someone applying for interface rights might not have any interest in custodian powers (i.e. me :P). They both do require trust, so in terms of establishing trust the application process should be at least as onerous as custodianship, if not more onerous, for CSS/JS. So there should be some sort of application process akin to custodian-ship. Mvolz (discuss • contribs) 07:11, 8 August 2018 (UTC)[reply]

Although on second thought, maybe they also need import rights, which requires custodianship. Mvolz (discuss • contribs) 07:21, 8 August 2018 (UTC)[reply]

I've added an option 7 to add the role as needed with a 24-hour expiration. Based on the most recent description, and the (lack of) frequency of editing the user interface, this doesn't seem to be something that anyone needs on a regular basis. In a typical computing environment, users would have different accounts for different roles, only logging in as an administrator when necessary. In this environment, we have one account, but can adjust the roles when needed. -- Dave Braunschweig (discuss • contribs) 15:30, 30 July 2018 (UTC)[reply]

This seems extremely onerous to me. On the off chance that these pages are vandalised, we at least need a few people that can quickly revert them without going through an approval process for editing the pages. Mvolz (discuss • contribs) 07:11, 8 August 2018 (UTC)[reply]

@Mvolz: How would these pages become vandalized? With limited access, the only scenarios I can envision require steward intervention anyway to shut down the rogue account or the rogue user. -- Dave Braunschweig (discuss • contribs) 13:16, 8 August 2018 (UTC)[reply]

I agree with user:Mvolz! No one is here 24/7! Requiring 24 hrs for an okay to respond is dangerous from a security point of view. --Marshallsumter (discuss • contribs) 14:19, 8 August 2018 (UTC)[reply]

Users Interested in Having This Role

Dave Braunschweig (discuss • contribs) 02:08, 10 July 2018 (UTC)[reply]

Is this where we discuss your nomination? --Luke Isham (discuss • contribs) 03:13, 10 July 2018 (UTC)[reply]

@Lukeisham: You voted for option 1, which has no discussion. Did you want to change your vote? Separately, I think we need to wait and see how the community wants to approach the approval process before discussing individual nominations to avoid unnecessary effort. -- Dave Braunschweig (discuss • contribs) 13:20, 10 July 2018 (UTC)[reply]

See above! --Marshallsumter (discuss • contribs) 17:35, 12 July 2018 (UTC)[reply]
I would like to have this role. I have recently identified two JS errors caused by JS scripts in the Mediawiki namespace and would like to be ability to fix them or similar new issues myself. See MediaWiki_talk:Gadget-edittop.js#JS outdated and MediaWiki_talk:Common.js/addin-mooc.js. I'm not a custodian or bureaucrat though so obviously community consensus would be needed (if we decide auto-confirmed can apply to this role without first being a custodian or bureaucrat first.) Mvolz (discuss • contribs)

Consultation on the creation of a separate user group for editing sitewide CSS/JS

(Please help translate to your language)

Hi all,

I'm preparing a change in who can edit sitewide CSS/JS pages. (These are pages like MediaWiki:Common.css and MediaWiki:Vector.js which are executed in the browser of all readers and editors.) Currently all administrators are able to edit these pages, which poses a serious and unnecessary security risk. Soon, a dedicated, smaller user group will take over this task. Your community will be able to decide who belongs in this group, so this should mean very little change for you. You can find out more and provide feedback at the consultation page on Meta. If you are involved in maintaining CSS/JS code, or policymaking around adminship requests, please give it a look!

Thanks!
Tgr (talk) 08:45, 12 July 2018 (UTC) (via global message delivery)[reply]

Unfortunate Sequence leading to Automatic Harmful Action Accusations

I will give a list of things I did to lead my actions to being considered "harmful":

Created the category Tibeto-Burman Languages
Attempted to add Portal:Róng for a minority language (Róng/Lepcha)
Linked to an example of a possible font to use because most fonts do not include Róng characters (not the best idea– people could find one on their own)

This lead me to be automatically labelled as harmful for the following reasons: New user exceeded new page limit and New user created page with external links. After this, it asked me to contact an administrator if I thought what I was doing was constructive, and this is what I am trying to do. Thank you for reading this. --Otvm (discuss • contribs) 18:26, 14 July 2018 (UTC)[reply]

Otvm: Welcome to Wikiversity! I looked through your logs and see that you are a newbie, so welcome to the WMF, as well. Somebody with a more extensive knowledge of our wikis should verify whether what I am about to tell you actually true, but I saw nothing in your logs that is likely to damage your reputation. My first edit on Wikipedia was far more destructive: I deleted everything in an article except an equation that I wanted to copy and paste into a student handout, not realizing that the "edit" would appear on the wiki. I didn't know I had a talk page, so I repeated the action a few times before someone finally caught my attention. I'm sure someone with more knowledge of such things will respond here, but till then: Welcome! If you have any questions do not hesitate to contact me on my talk ("discuss") page--Guy vandegrift (discuss • contribs) 20:25, 14 July 2018 (UTC)[reply]

@Otvm: Welcome! Your enthusiasm is appreciated, but Wikiversity abuse filters are configured to encourage users to learn more about Wikiversity before they create too many new pages. Please continue participating and learning about our community. You'll be able to add new pages after a few days and a few more edits to existing pages. -- Dave Braunschweig (discuss • contribs) 13:34, 15 July 2018 (UTC)[reply]

@Otvm: Welcome to Wikiversity, that message confused me as well when I first saw it. You need 100 edits plus 5 days before you can create pages and link to pages outside Wikiversity.--Luke Isham (discuss • contribs) 02:29, 18 July 2018 (UTC)[reply]

Edit blocked

I was blocked from editing User:KoshVorlon/badwords. I'm pretty sure I know why this happened, first of all, any page called "badwords" is going to get some kind of attention, so that I got it isn't suprising. However, this page is not an enemy list or any kind of a flame page, it's part of a script I've imported from the English Wikipedia , Lupin's AntiVandal tool. It uses a badword list to seek them out and highlight them. So I'm requesting assistance from an admin to unblock this page. Thanks KoshVorlon (discuss • contribs) 17:49, 24 July 2018 (UTC)[reply]

@KoshVorlon: This is likely due to a setting at MediaWiki:Spam-blacklist rather than someone specifically blocking you or protecting that page. —Justin (koavf)❤T☮C☺M☯ 00:53, 25 July 2018 (UTC)[reply]

@KoshVorlon: Once you've been active for four days (22 July + 4 = 26 July) you become an Autoconfirmed user. Further, per Wikiversity:Uploading files to upload files you must be logged in, and your account must be autoconfirmed (an account that is at least 4 days old and has more than 10 edits to Wikiversity) or confirmed. If you are not an autoconfirmed or confirmed user, please request an upload at Wikiversity:Request custodian action. You are not yet autoconfirmed so if you tried to upload a file you may have been prevented by a filter. You have more than 10 edits, it's just the two more days. --Marshallsumter (discuss • contribs) 02:52, 25 July 2018 (UTC)[reply]

@KoshVorlon: The blocked edit is due to the presence of one or more of the bad words. There is an abuse filter that prevents them being added here. It is possible to turn off the filter, either temporarily or permanently, but that requires a larger discussion about how Wikiversity wants to address vandalism and who is going to do the work.

Abuse filters are the MediaWiki built-in method for finding and/or preventing abuse. They can be set to either tag, warn, or prevent abuse. They are very effective, as you, yourself have experienced. The list you are using seems to be quite thorough and, with a bit of work, could be added to one or more abuse filters rather than imported as a page of HTML. The advantage of using abuse filters is that some of it may be automated, and the rest follows a standard that others already use here in identifying potential abuse.

If Lupin's AntiVandal tool is going to be used, it's not entirely clear to me yet that the page needs to be imported. See MediaWiki:Gadget-LintHint.js. This gadget works fine here with the source loaded from en.wikipedia. Perhaps modifications can be made so that a single source would work across Wikipedia and Wikiversity. Even better if it was loaded at Meta and supported from there.

It's also not entirely clear to me yet why you are leading this effort. Your edit history shows great interest in wiki tools and configuration, but in 10 years of edits at Wikiversity, you have no contributions outside your own user space. There's also a 10-year gap in that edit history, complicated by the fact that you are currently banned from editing en.wikipedia for long-term disruptive editing.

So, please tell us your intentions, how the tool will be used, by whom, how often, and why it must be loaded here to be used here. Then give us some time to discuss your proposal and see if this is the way we'd like to address abuse at Wikiversity. -- Dave Braunschweig (discuss • contribs) 13:35, 25 July 2018 (UTC)[reply]

User:Dave Braunschweig actually, in 10 years I mainly gnomed and cleaned up vandalism, so more of my edits are outside of my userspace and I used Lupin's AntiVandal tool for that purpose. I would use it for the same purpose here. The file that's being blocked is essentially a list of dirty words, Lupin's script works in part by searching for those words, so that it can bring them to the attention of the human operator , who then makes the decision to remove them or not, and paste a warning (template of course) to the individuals page. It's one of the only tools available that doesn't require rollback to use. That's why I was looking to bring it over here. KoshVorlon (discuss • contribs) 15:01, 25 July 2018 (UTC)[reply]

@KoshVorlon: Please expand on your gnome and cleanup efforts. Special:Contributions/KoshVorlon shows zero edits outside user space, except for this thread in the Colloquium. What account or accounts were used for this effort? Regarding rollback, Wikiversity makes rollback available to Wikiversity:Curators, so users interested in supporting Wikiversity have access to the tools necessary for doing so. You might consider providing or working toward an edit history that documents your efforts supporting Wikiversity and then applying for curator status. -- Dave Braunschweig (discuss • contribs) 15:55, 25 July 2018 (UTC)[reply]

User:Dave Braunschweig Fair question, I use only this ID, however, I was an active gnome on en.wikipedia.org under this name. I am currently blocked over there , indef (not for socking or outing either - and yes I know this immediately makes me look bad!) the short version is I had a very bad history on Wiki, made myself a very unpopular user, decided to gnome and keep out of everyone's way to earn back their good faith and made the mistake of editing in an area another sysop (who had been involved with me before) edited. he didn't like it, took it to ani and requested a ban. You can read all about it, it was a real Kangaroo court. KoshVorlon (discuss • contribs) 16:12, 25 July 2018 (UTC)[reply]

New user group for editing sitewide CSS/JS

(Please help translate to your language)

Hi all!

To improve the security of our readers and editors, permission handling for CSS/JS pages has changed. (These are pages like MediaWiki:Common.css and MediaWiki:Vector.js which contain code that is executed in the browsers of users of the site.) A new user group, interface-admin, has been created. Starting four weeks from now, only members of this group will be able edit CSS/JS pages that they do not own (that is, any page ending with .css or .js that is either in the MediaWiki: namespace or is another user's user subpage).

You can learn more about the motivation behind the change here.

Please add users who need to edit CSS/JS to the new group (this can be done the same way new administrators are added, by stewards or local bureaucrats). This is a dangerous permission; a malicious user or a hacker taking over the account of a careless interface-admin can abuse it in far worse ways than admin permissions could be abused. Please only assign it to users who need it, who are trusted by the community, and who follow common basic password and computer security practices (use strong passwords, do not reuse passwords, use two-factor authentication if possible, do not install software of questionable origin on your machine, use antivirus software if that's a standard thing in your environment).

Thanks!
Tgr (talk) 13:08, 30 July 2018 (UTC) (via global message delivery)[reply]

Importing user scripts

User:Dudley_Miles has asked for the use of a set of scripts (User:Dudley_Miles/common.js). What's the preferred location to special:import user java scripts to?

Imported to the equivalent userspace even if that user isn't active on wikiversity
Imported to a different user's userspace
Imported to some script repositry

Any other issues I'm not thinking of? Thanks! T.Shafee(Evo﹠Evo)^talk 23:09, 6 August 2018 (UTC)[reply]

@Evolution and evolvability: Dudley Miles has already imported the scripts in User:Dudley_Miles/common.js. That should be working for him. What additional functionality is being sought beyond what is already available?

From a general code perspective, a single source is preferred, so importing as it is now reduces maintenance. If the code is required by multiple users, we need to determine how many, and whether it should be imported by MediaWiki:Common.js. For that, it should be hosted here from a security perspective. -- Dave Braunschweig (discuss • contribs) 01:17, 7 August 2018 (UTC)[reply]

I think they're not working for him because the common.js page is trying to failing to call to Wikipedia (e.g. call from User:Dudley_Miles/common.js to w:User:Ucucha/duplinks.js). I don't think they're universal enough to warrant addition to MediaWiki:Common.js (they're for spotting duplicate links, harvard referencing errors etc), but could be imported to either v:User:Ucucha/duplinks.js etc or v:User:Dudley_Miles/duplinks.js. T.Shafee(Evo﹠Evo)^talk 04:49, 7 August 2018 (UTC)[reply]

The links need to be in URL format, like

mw.loader.load("https://en.wikipedia.org/w/index.php?title=User:Ucucha/duplinks.js&action=raw&bcache=1&maxage=86400&ctype=text/javascript");

. I tried loading that one both ways (loading by URL and copying the code directly). I don't get any errors either way, but it also doesn't seem to do anything either way. -- Dave Braunschweig (discuss • contribs) 14:12, 7 August 2018 (UTC)[reply]

hi I am wanting to learn basic computer skills on a Mac book pro

--Rhyejan (discuss • contribs) 05:35, 22 August 2018 (UTC)[reply]

@Rhyejan: I recommend GCF Learn Free, now called GCF Global. There are also tutorials on the Apple website. -- Dave Braunschweig (discuss • contribs) 01:42, 23 August 2018 (UTC)[reply]

OK to accept cryptocurrency tips on user page? - or use free speech to at least include a wallet address?

From: w:Bitcoin#Academia "In September 2015, the establishment of the peer-reviewed academic journal Ledger (ISSN 2379-5980) was announced. It will cover studies of cryptocurrencies and related technologies, and is published by the University of Pittsburgh.[239]

The journal encourages authors to digitally sign a file hash of submitted papers, which will then be timestamped into the bitcoin blockchain. Authors are also asked to include a personal bitcoin address in the first page of their papers.[240][241]"

So here is one example of where a publisher of research actually requires authors to include a bitcoin address on the first page. Bitcoin can be sent to a Bitcoin address. So if I include cryptocurrency addresses on my user page will they be removed? I will continue to devote little time to this potentially worthwhile wiki until the best interest of all stake-holders seems to be more taken into account. cheers. Michael Ten (discuss • contribs) 04:04, 24 August 2018 (UTC)[reply]

Wikimedia resources may not be used for personal financial gain. Soliciting payments from users will result in both the links being removed and your account being blocked from further participation. -- Dave Braunschweig (discuss • contribs) 15:07, 24 August 2018 (UTC)[reply]

Growth Team Looking for Feedback

The Wikimedia Growth team is looking for feedback on eight proposals that will initially impact medium-sized wikipedias. See Wikiversity talk:Organizing Wikiversity for more information. -- Dave Braunschweig (discuss • contribs) 15:38, 24 August 2018 (UTC)[reply]

Editing of sitewide CSS/JS is only possible for interface administrators from now

(Please help translate to your language)

Hi all,

as announced previously, permission handling for CSS/JS pages has changed: only members of the interface-admin (Interface administrators) group, and a few highly privileged global groups such as stewards, can edit CSS/JS pages that they do not own (that is, any page ending with .css or .js that is either in the MediaWiki: namespace or is another user's user subpage). This is done to improve the security of readers and editors of Wikimedia projects. More information is available at Creation of separate user group for editing sitewide CSS/JS. If you encounter any unexpected problems, please contact me or file a bug.

Thanks!
Tgr (talk) 12:39, 27 August 2018 (UTC) (via global message delivery)[reply]