Wikiversity

Wikiversity:Technical needs

Action required

Templates

Development

Reference

Events and news


Wikiversity is an educational wiki running on MediaWiki software - which has its benefits and drawbacks. This page is to brainstorm and discuss various technical needs that we may have - as individuals or as a community. Hopefully, we will be able to discuss these needs with the MediaWiki developer team - to identify what we really need in order to function better, and what's possible in both the short and long term.

See also Proposals for Wikiversity, at Strategic Planning.

Ideas

edit

Please sign your suggestions so that people can get back to you about them!

Ideas which can be resolved internally

edit

These are ideas which can be resolved internally (i.e. internal to WV's MediaWiki installation; no sandbox server backdoors). Typically they will involve templates, CSS modifications or human-organisational structures.

  • Course structuring - one idea from the KDE community is to have a web of content (ie lessons), over which is placed a network of specific "learning paths". Each learning path would specify what content the learner should look into in order to become proficient in that particular subject.
  • Improved file structure - Some instructors are creating more formal kinds of courses with lessons and pages of lessons, quiz pages, explanation pages, etc. A much stronger and clearer file structure is needed so this instructor can keep track of all of his pages and can easily set up navigation among the 2000 pages and illustration. Robert Elliott 13:22, 7 March 2008 (UTC)[reply]

Ideas which probably need a MediaWiki extension

edit
One possibility would be an install of http://limesurvey.org on a test server. -- Jtneill - Talk 05:35, 27 March 2008 (UTC)[reply]
The ability to conduct research anonymously, but at the same time being able to detect bad data
  • WikiTimeline - Activating the WikiTimeLine extension on wikiversity would be a good idea I think. Its the, kind of, interactive and real-time version of easytimeline. Controlled by the reader of the article instead by the writer. You add tags to an article, if the reader clicks on such a link, an event will be added to the timeline. You can add the events you want (and so create an individual timeline), zoom in/out and move around. See the live example and more information here (just click on a few of the links at the "Examples" section) and the MediaWiki page here. Its like a mix out of WikiTimeScale and the Simile Timeline. The interface is in JavaScript, so there's no heavy load put on the server since nearly everything runs client-side. Thus it can be used by heavy traffic wikis (like the wikimedia foundation wikis) too. The guys at bugzilla told me we would need to be interested here first and afterwards the admins of wikiversity could go to bugzilla/the developers of mediawiki and request the activation of the extension. Any interest? ColdCase 11:18, 31 July 2008 (UTC)[reply]
This discussion has moved to Wikiversity:Colloquium#Discussion_about_activating_WikiTimeLine_extension_on_Wikiversity ColdCase 12:32, 31 July 2008 (UTC)[reply]

Ideas which probably need a readjustment of LocalSettings.php

edit
  • Easier name changes - Allow instructors to make greater and easier name changes. Some instructors occasionally make mistakes in the names that they select for pages. The current method for fixing this just creates more pages that eventually confuse everyone... including the instructor. Robert Elliott 13:22, 7 March 2008 (UTC)[reply]
    • It is possible to assign privileges to different categories of user using LocalSettings.php. For example, you could assign anonymous IP's the right to appoint bureaucrats. More sensibly, registered users could be assigned to the right to move pages. Even more sensibly, long-standing registered users with high edit counts and a need to apply sysop tools to their projects could be assigned sysop (custodian) status. --McCormack 07:09, 9 March 2008 (UTC)[reply]
      • On further reading of this (and thinking a bit this time), do you mean a new move function which does not yet exist? If so, please give a more precise description of how this would work; e.g. a combined "rename-and-delete-old-page-and-update-all-links" ? --McCormack 07:16, 9 March 2008 (UTC)[reply]
        • Yes, currently a name change is simply a new page with a redirect from the old page. What is needed is a SAFE way to completely change the name and ALL references to that name. (That should be a challenge!) Robert Elliott 01:58, 17 May 2008 (UTC)[reply]
    • An associated issue is that of dealing with classes on a wiki. Sometimes we experience a rush of new user account creations as a class descends on a project. In the long term, it is sensible for classes to use prefixes or suffixes on their usernames (rather like school uniforms) so that the instructor can recognize them (at least a bit). It is also the case that classes faced with wiki sign-up tasks typically make a lot of mistakes and want to change their usernames anyway. It would be helpful if it was easier to change usernames. I'd suggest extending this privilege from bureaucrats to custodians for Wikiversity's specific needs in "classroom management". --McCormack 07:09, 9 March 2008 (UTC)[reply]

Ideas which may need both internal reforms and new programming

edit
  • Metadata - could address search issues. This could take different forms (think categories and/or 'tagging') and it could be used to link/interface Wikiversity resources with other sites, such as OER Commons. (See the Semantic MediaWiki project for a metadata extension for mediawiki.)
  • Student assignment - A non-threatening way for students to upload assignments with a single button and present them in both the page for completed lessons and on the students USER page. Robert Elliott 13:22, 7 March 2008 (UTC) (Further details on this request here and here.)[reply]
    • On the whole I would see this as being so ambitious as to go beyond what is prudent or possible with MediaWiki. Perhaps others see it differently? --McCormack 07:20, 9 March 2008 (UTC)[reply]
      • The current system cannot be greatly changed, that is true. But MediaWiki was never designed as a way to organize and write lessons for a school. Therefore, sometime down the road (possible for Wikiversity II), you will have to bite the bullet and create a new system more appropriate for a school. Painful but necessary. Therefore you can begin to plan now.~~~~ Robert Elliott 09:33, 16 March 2008 (UTC)[reply]
  • Categorized Search Results - Search results which are close to a subject but not quite right could help users narrow down the possibilities if a term or a phrase is not exact. Similarly, a missed connection (a page related to the subject but not what the user is looking for) could guide the user to the proper subject pages. - gustable 02:06, 8 July 2008 (UTC)[reply]
  • Anonymous pages - These pages could be created as anonymous, and then all contributions would be anonymous. Perhaps only stewards and/or bureaucrats could see who the contributors are. These of course could be deleted if they are inappropriate, and then also, moved if the page name needs to be used in non-anonymous ways. They could perhaps be only created as subpages maybe.
  • A seminar feature. Seminars play an important role at brick and mortar universities, and they could provide an important learning mode at Wikiversity. The seminar session itself would likely consist of several students (and perhaps an instructor) on a shared zoom (or other) video meeting. A difficulty that has to be addressed is identifying interested participants and scheduling a time for the seminar meeting. Game sites such as chess.com allow participants to find other players immediately because of the high traffic levels they serve. That is unlikely on Wikiversity at this time. An innovative queueing, scheduling, and notifying system will be needed.
  • Student discussion groups. Classroom discussions play an important role in brick and mortar universities. Wikiversity would benefit from providing an analogous capability. This might be implemented as a discussion widget that can be added to a course. This widget would implement an on-line chat group so that any student could join the thread and participate in real time text discussion of class topics. Perhaps a decade from now we can have a metaverse version of this!

Other ideas, uncategorised ideas and new ideas

edit
  • Login - (opt-in) differential login for learners/students and facilitators/teachers (?)
Because there are people here that are teachers/mentors and students I don't think this would work very well. But an idea similar to this could be to make a userbox type thingy where you can label yourself as a teacher and then also list what things you are teaching. And then you can also list what courses you are learning from. Perhaps this could add you into the category system as well so it would be easy for people to find other teachers and other peers and such. --Devourer09 02:56, 7 September 2008 (UTC)[reply]
  • Certifications—provide students with a recognized certificate for completing some number of courses. One option would be to connect with the open badges project.
  • Federated WM Foundation project search - a way is needed to search across multiple WikiMedia Foundation wiki projects. It is inefficient and time consuming to search separately on the different domains. See also March, 2008 discussion about this on wikiversity-l -- Jtneill - Talk 16:02, 22 March 2008 (UTC)[reply]
  • Enhancing social features (eg SocialProfile Extension) Could this be extended to a way of finding people of similar interests, with whom you could collaborate and learn?
    • Yes. For example, ArmchairGM (the sports wiki where the social tools were originally developed) had a special page (Special:SimilarFans) to find users similar to you — users could choose their favorite sports and sports teams on a special page and the SimilarFans special page would look for users who like the same sports and teams as you. --Jack Phoenix 18:49, 16 August 2011 (UTC)[reply]
PRO: this could be done so far with Categories or userboxes or a central page where people add themselves, but this needs knowledge that these exist :-( ----Erkan Yilmaz Wikiversity:Chat 18:48, 11 March 2008 (UTC)[reply]
  • Discussions - how to keep discussions accessible and "current"? One idea might be LiquidThreads
  • Tracking and monitoring facility - a learner management system where the system tracks the progress of oneself on a particular course and/or the achieved test scores. source
  • Showing activity level of participants in a course: e.g. all people listed on a course page and sort them after their activity level by contributions ? ok, perhaps not so nice because of privacy reasons, but helps the others (instructor,...) to keep the overview. So far this was done manually here. ----Erkan Yilmaz uses the Wikiversity:Chat 10:35, 17 March 2008 (UTC)[reply]
  • RSS feeds for users' watchlists - -- Jtneill - Talk 12:07, 16 March 2008 (UTC)[reply]
  • When moving a page there could be a check box that would also move all its subpages to reflect to moved page's new name
  • Move category feature - moving a category would automatically edit all pages within that category to reflect the moved category
  • Hiding noinclude sections from edit windows: This is something that was broken when the last major mediawiki update went through a month or two ago. Look, for example, at BCP/Taraxacum officinale, and specifically see what happens when you hit the [edit] button next to "Recent Logs" (on the right hand column). The way it used to work is that you would only see that section when you edited, and all we needed to tell people was "add *~~~~ on a new line below the last one to log the plant". This doesn't work anymre though, since the nonincluded section (archived logs) also comes up in the edit window when you hit the button. I'm not sure that there's any advantage to how it is now, but it's a major difficulty in making that part of bloom clocking easy for the newbies to do. Using the clock is complicated as it is, but it was nice before that new users could "get their feet wet" by doing something quite simple (later on they need to start using templates on the profiles as well, but it's a "one step at a time" thing. --SB_Johnny | talk 14:44, 30 March 2008 (UTC)[reply]
  • Allow uploading of .blend files
  • Page name masks within categories - Since we use subpages fairly liberally here, if a page is named This or that page/Links, then within Category:This or that page, it could be displayed as "Links" and would link to This or that page/Links. Maybe syntax on the page being categorized could be something like [[Category:This or that page|L|Links]].
  • Advanced Category Searching; ie, allowing one to search for all pages in the "Topic" namespace under Category:History and all subcategories. This sort of thing would be very useful in categorizing stuff. The Jade Knight 09:56, 10 September 2008 (UTC)[reply]
  • Category Redirects (while I'm at it): It would be WONDERFUL if there were any way to make a category redirect to another category in such a way that everything in the first category would be immediately placed in the second category. This would save an awful lot of grunt work, and would be terribly convenient for making sure categories stayed consistent. The Jade Knight 09:56, 10 September 2008 (UTC)[reply]
  • Collaborative 3d modeling with Cad support and wiki-like versioning
  • Collaborative programming You edit source files like you edit a wiki, but you can download all linked files in bundles ready to be compiled (or maybe even precompiled) with attatched resources (graphics)

Getting technical needs addressed

edit

The mechanism for addressing technical needs within Wikimedia projects is generally to add a request to Bugzilla. Also, there is a mailing list for technical issues, Wikitech-l, as well as an IRC channel, #wikimedia-tech (on freenode).

Generally it is a bad idea to go along to #wikimedia-tech with a poorly-formed request, or even a well-formed one, and don't even dream of putting a vague request on bugzilla.. Get your development team and your proposal together in advance, and don't assume the MediaWiki development people will devote any resources to you, other than code-reviews (once they're convinced you aren't wasting their time). Start by contacting the people listed below instead, and learning how the system works.

Truly good ideas are also mostly old ideas, and there is often evidence of this on MediaWiki in the form of incomplete projects. One way forward is to take over a stalled project and move it forwards.

List of Wikiversitarians who have skills which could be used in implementing technical requests

edit

See also

edit
Retrieved from "https://en.wikiversity.org/w/index.php?title=Wikiversity:Technical_needs&oldid=2365113"