Wikiversity:Colloquium

From Wikiversity
Jump to navigation Jump to search
Marburger-Religionsgespräch.jpg
Please do not include wiki markup or links in section titles.
Sign your posts with   ~~~~
Welcome

Do you have questions, comments or suggestions about Wikiversity? That is what this page is for! Before asking a question, you can find some general information at:

Shortcut:
WV:C

var wgArticlePath = "/wiki/$1"; var wgServer = "http://en.wikiversity.org"; var wgPageName = "Wikiversity:Colloquium"; var wgTitle = "Wikiversity Colloquium"; var wgContentLanguage = "en"; var x-feed-reverse = "true"; var x-blog-description = "You have questions, comments or suggestions about Wikiversity? That's what this page is for!";

"The mind is not a vessel to be filled, but a fire to be kindled." — Plutarch (discuss)

Photosynthesis

Mediawiki JavaScript and CSS Editor Role[edit]

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 (discusscontribs) 02:08, 10 July 2018 (UTC)

Proposed Approaches[edit]

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

Discussion[edit]

  • 1:Custodians or bureaucrats who request the role (Assuming that they will be given the role after community discussion and consensus.) --Luke Isham (discusscontribs) 03:13, 10 July 2018 (UTC)
  • 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 (discusscontribs) 17:31, 12 July 2018 (UTC)
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 (discusscontribs) 14:01, 26 July 2018 (UTC)
  • 4, and I've added in 6, grandfather in those who already have the rights, which they'll otherwise lose access to (custodians). Mvolz (discusscontribs) 15:21, 26 July 2018 (UTC)
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 (discusscontribs) 07:11, 8 August 2018 (UTC)
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 (discusscontribs) 00:43, 27 July 2018 (UTC)
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 (discusscontribs) 07:11, 8 August 2018 (UTC)
Although on second thought, maybe they also need import rights, which requires custodianship. Mvolz (discusscontribs) 07:21, 8 August 2018 (UTC)
  • 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 (discusscontribs) 15:30, 30 July 2018 (UTC)
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 (discusscontribs) 07:11, 8 August 2018 (UTC)
@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 (discusscontribs) 13:16, 8 August 2018 (UTC)
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 (discusscontribs) 14:19, 8 August 2018 (UTC)

Users Interested in Having This Role[edit]

Is this where we discuss your nomination? --Luke Isham (discusscontribs) 03:13, 10 July 2018 (UTC)
@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 (discusscontribs) 13:20, 10 July 2018 (UTC)

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

Unfortunate Sequence leading to Automatic Harmful Action Accusations[edit]

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 (discusscontribs) 18:26, 14 July 2018 (UTC)

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 (discusscontribs) 20:25, 14 July 2018 (UTC)
@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 (discusscontribs) 13:34, 15 July 2018 (UTC)
@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 (discusscontribs) 02:29, 18 July 2018 (UTC)

DOI links[edit]

Coming from Wikipedia, I noticed that the DOI number redirects to the current publicly-editable version of the article instead of the actual peer-reviewed version. For example, https://doi.org/10.15347/wjs/2018.006 links to Radiocarbon dating which has been edited after peer review and could be edited by any member of the public. Shouldn't the DOI link to either the PDF or the specific revision that was accepted? Dlthewave (discusscontribs) 17:31, 21 July 2018 (UTC)

Dlthewave, I'm not sure who maintains the doi links but it's likely to be someone over at Talk:WikiJournal_of_Science Mvolz (discusscontribs) 07:37, 8 August 2018 (UTC)

Edit blocked[edit]

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 (discusscontribs) 17:49, 24 July 2018 (UTC)

@KoshVorlon: This is likely due to a setting at MediaWiki:Spam-blacklist rather than someone specifically blocking you or protecting that page. —Justin (koavf)TCM 00:53, 25 July 2018 (UTC)
@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 (discusscontribs) 02:52, 25 July 2018 (UTC)

@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 (discusscontribs) 13:35, 25 July 2018 (UTC)

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 (discusscontribs) 15:01, 25 July 2018 (UTC)
@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 (discusscontribs) 15:55, 25 July 2018 (UTC)
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 (discusscontribs) 16:12, 25 July 2018 (UTC)

New user group for editing sitewide CSS/JS[edit]

Importing user scripts[edit]

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)

@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 (discusscontribs) 01:17, 7 August 2018 (UTC)
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)
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 (discusscontribs) 14:12, 7 August 2018 (UTC)

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

--Rhyejan (discusscontribs) 05:35, 22 August 2018 (UTC)

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

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

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 (discusscontribs) 04:04, 24 August 2018 (UTC)

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 (discusscontribs) 15:07, 24 August 2018 (UTC)

Growth Team Looking for Feedback[edit]

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 (discusscontribs) 15:38, 24 August 2018 (UTC)

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

(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)

Read-only mode for up to an hour on 12 September and 10 October[edit]

13:33, 6 September 2018 (UTC)

Science[edit]

--Odey370 (discusscontribs) 13:42, 9 September 2018 (UTC) Please send data so that I can be able to help with the projects

Depending on your interests there are What is science?, Search Wikiversity using the word Science, and Sciences. --Marshallsumter (discusscontribs) 19:14, 9 September 2018 (UTC)

Agriculture[edit]

--Odey370 (discusscontribs) 13:52, 9 September 2018 (UTC)grade12

For Agriculture, check out the Portal:Agriculture! --Marshallsumter (discusscontribs) 19:17, 9 September 2018 (UTC)

CC-BY 4.0 as default license in upload forms[edit]

I suggest that CC-BY 4.0 should be the default suggested licensing when using the upload forms in Wikimedia projects for own works, instead of the current CC BY-SA 4.0 license (example at Commons), sometimes with dual GFDL licensing (example here at Wikiversity). The main difference would be that derivatives are not required to have the same license. Reasons for changing to CC-BY 4.0 are:

  • It is a more permissive license.
Derivative of medical imaging.jpg
  • It makes it much easier to combine and mix works. The combination of the two images at right, for example, would not have been possible at all if the images were licensed under let's say CC BY-SA 4.0 for the first one and CC BY-NC 2.0 for the other. However, if either was CC-BY 4.0 it would have been permitted. See WP:Adaptation for further information in this regard.
  • CC-BY is by far the most popular licensing for open access journals (see Directory of Open Access Journals - Journal license tab), and is similarly popular in databases (see CC: Data and CC licenses). CC BY-SA is therefore not compatible for inclusion in most open access journals, denying them free access to the sum of Wikimedia knowledge.
  • Most uploaders may very well be as willing to upload under CC-BY, but may not be familiar with the differences between having SA or not. The current upload form layouts thus make lots of works receiving a more restrictive licensing than necessary. Just because uploaders can upload under the most restrictive license Wikimedia has to offer doesn't mean they need to be presented with that option by default. Those who still want to put the additional SA restriction would still be able to actively choose so.
  • The currently suggested dual licensing with CC BY-SA 4.0 with GFDL such as here in Wikiversity (link to form) is actually incompatible in a strict sense (see Wikipedia section on this matter, and is also a lot of extra read for those who want to know what GFDL means, since it doesn't provide the short presentation as given in Creative Commons licenses (compare GFDL license page to the CC BY-SA 4.0 page. It would therefore be both easier for uploaders and more legally correct if we simply dropped GFDL from the default license suggestion. Again, those who do want to choose dual licensing for some reason would still be able to actively choose so.

I want to know if you agree with this suggestion, and we can then bring it to Wikimedia's legal team for review before implementation. I know the change is technically not that hard, since we only need to change the upload form layouts, not the licenses of any already uploaded works, nor the overall licensing of any wiki. I've started a vote on this issue in Wikimedia Commons. Please go to that page to join:

Mikael Häggström (discusscontribs) 20:48, 10 September 2018 (UTC)

Would it be possible to add a default option in our Special:Preferences page?--Guy vandegrift (discusscontribs) 12:42, 12 September 2018 (UTC)

The GFDL license on Commons[edit]

18:11, 20 September 2018 (UTC)