I’m a light Wikipedia (and related projects) editor, but help to maintain and support two decent sized (hundreds of contributors, thousands of pages) internal wikis in the healthcare industry. Our organization has been using (Semantic) MediaWiki for over 6 years. I’ve been maintaining it for over 3.
The first item we'd like to discuss with MediaWiki users is what should
we actually focus on?
Out of the box experience - As I was putting together this list I thought about how many of the things I do when I setup the wikis. The default installation does include some handy tools, but almost everyone I’ve spoken to has their own brew of extensions they setup by default (I have upwards of 50).
I would love to see improved first-run experience and documentation (on mw.org<http://mw.org>) on what is included by default, what the extensions do, where do I go to get more, etc.
Editing - I think VisualEditor is the future of wiki editing. Wikitext is powerful and at the moment savvy editors can do more than VisualEditor, but that gap is closing. I’ll meet with many internal teams wanting to move away from email archives and Word docs for their documentation needs. I go over the philosophy of MediaWiki, explain it’s features (watchlists are magical!) and then I get to editing. Eww. People think it’s gross and backwards. People expect easy-to-use WYSIWYG editing - and they should have it. I’ve spent more time explaining and fixing wikitext errors than I’d care to admit.
Just in the past few months the VisualEditor team has improved support for things my co-workers care about - IE support and tables. I think Mediawiki should increase the push for use of VisualEditor in third-party wikis. I’ve been running it for a year now with great success.
More consistency in WMF extensions - There’s an inconsistency in documentation, UI/UX, and architecture requirements between WMF-backed projects.
One extension might lack documentation, another has a specific technical requirement, another uses a unique UI paradigm, another an entirely unique set of iconography (for similar actions!). I expect this when dealing with individual non-WMF extensions, but from the same organization?
An example: VisualEditor is great and I think it’s use will continue to grow. But holy cow is it a big requirement to have to install node.js on top of the LAMP stack. Another: MW core requires PHP 5.3.3, but Flow requires 5.3.6. PHP 5.3.3 is the default install for RedHat RHEL 6 - a common flavor found in many enterprise environments (like my own). Getting PHP updated is not only a technical challenge, but also an administrative one inside large organizations. The server team wants to stick with what is supported via the vendor, I want to use the latest innovative features. Conflict arises.
More consistency in extensions in general - There’s an opportunity to show a focused, collaborative, platform for the experience within MediaWiki - and extensions from all sources. Where’s the MediaWiki Style Guide for buttons, dropdowns, menus, etc? Some use bootstrap, some use jquery, some follow WMF’s designs. Developers from all walks are making cool things, but let’s make cool things like behave as part of something bigger. WordPress, while not perfect, is a great example of a robust ecosystem of 1st-party and 3rd-party extensions attempting some semblance of integration.
Updates - Composer is for nerds. I mean that in a positive way - I’m a self professed nerd (as shown by the length of this response). Composer, and the traditional installation/update methodology for extensions is cumbersome and yet another requirement. I want a one-click update button from a Special: page. It would alert met to available updates (from mediawiki.org<http://mediawiki.org> or git gerrit) and let me install them without touching a Terminal window. Yeah, I know that there’s a lot of crazy interdependencies between MW versions and extension version - and between extensions themselves. Maybe that’s telling? How do other open-source projects accomplish a much more unified install/updating experience?
WMF Extensions (or any really!) prepackaged with necessary templates - UploadWizard is a great extension that makes the uploading of images super easy and consistent. I love it. However, it requires numerous template files and images to work, none of which is documented or included. I don’t need to include every language and deep documentation for all those templates. Just the basics.
If you use MediaWiki for your own wiki, what sort of things do you think
need more attention?
Uhh, I may have gotten carried away with the first question. See above? I think some of my thoughts touch on the cultural aspects of MediaWiki. We’re a diverse group without a lead on some of these things. How do we get big things done like improving extension documentation? How do we make the experience more consistent when there are hundreds of cooks in the kitchen? How can we encourage popular developers to lead by example? We’re a very technical community - more so than say (again) WordPress. There’s a large dev-focused community around that particular software, but there’s also a large group of people just using it! I think communication should be a bigger area we focus on.
How can we help you find out about things you need
to know to run your wiki?
Documentation on mw.org<http://mw.org>. Regional (or online) hangouts - where I can see someone’s screen as they talk about something. Social Media - twitter in particular. I feel like it’s hard to know about discussions (like the removal of site stats) as they’re happening. I’m into MediaWiki developments, but not to the point where I read every Request for Comment (RfC). How do we bubble up that to more folks using MediaWiki?
--
Shameless Plug: If you’d like to share the work that you’re doing with a group of 3rd-party wiki folk, you should attend SMWCon Spring 2015: http://semantic-mediawiki.org/wiki/SMWCon_Spring_2015 . I’m the Local Chair for the conference and would love to see you there. I’d be happy to set aside some time on the third day to continue discussions like this one.
Nerd in Residence,
Chris Koerner
This electronic mail and any attached documents are intended solely for the named addressee(s) and contain confidential information. If you are not an addressee, or responsible for delivering this email to an addressee, you have received this email in error and are notified that reading, copying, or disclosing this email is prohibited. If you received this email in error, immediately reply to the sender and delete the message completely from your computer system.
At the developer summit just now, we've decided to use the tag #mwstake
(for twitter, etc) or the subject line prefix (like I've done here) for
communication on mediawiki-l for the MW stakeholders group.
The first item we'd like to discuss with MediaWiki users is what should
we actually focus on?
If you use MediaWiki for your own wiki, what sort of things do you think
need more attention? How can we help you find out about things you need
to know to run your wiki?
For example, someone in this meeting said that they ran from git master
because they need to run Visual Editor. I told him that I was
successfully using VE on MW 1.24.
This is the sort of information that would be useful for him, of course,
but we need to figure out what other things we need to communicate.
And, of course, sometimes I could benefit from things that you know.
How can we gather this sort of information to make it more useful to
everyone?
Mark.
--
Mark A. Hershberger
NicheWork LLC
717-271-1084
Well ItS simple really I have the answers that it takes and I would be happy to share.
> From: mediawiki-l-request(a)lists.wikimedia.org
> Subject: MediaWiki-l Digest, Vol 136, Issue 24
> To: mediawiki-l(a)lists.wikimedia.org
> Date: Tue, 27 Jan 2015 12:00:56 +0000
>
> Send MediaWiki-l mailing list submissions to
> mediawiki-l(a)lists.wikimedia.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
> or, via email, send a message with subject or body 'help' to
> mediawiki-l-request(a)lists.wikimedia.org
>
> You can reach the person managing the list at
> mediawiki-l-owner(a)lists.wikimedia.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of MediaWiki-l digest..."
>
>
> Today's Topics:
>
> 1. [mwstake] What should we focus on? (Mark A. Hershberger)
> 2. Re: [mwstake] What should we focus on? (Dmitrii Kouznetsov)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon 26 Jan 2015 02:48:06 PM EST
> From: "Mark A. Hershberger" <mah(a)nichework.com>
> To: MediaWiki announcements and site admin list
> <mediawiki-l(a)lists.wikimedia.org>
> Subject: [MediaWiki-l] [mwstake] What should we focus on?
> Message-ID: <87h9vcg7qo.fsf(a)flynn.nichework.com>
> Content-Type: text/plain
>
>
> At the developer summit just now, we've decided to use the tag #mwstake
> (for twitter, etc) or the subject line prefix (like I've done here) for
> communication on mediawiki-l for the MW stakeholders group.
>
> The first item we'd like to discuss with MediaWiki users is what should
> we actually focus on?
>
> If you use MediaWiki for your own wiki, what sort of things do you think
> need more attention? How can we help you find out about things you need
> to know to run your wiki?
>
> For example, someone in this meeting said that they ran from git master
> because they need to run Visual Editor. I told him that I was
> successfully using VE on MW 1.24.
>
> This is the sort of information that would be useful for him, of course,
> but we need to figure out what other things we need to communicate.
>
> And, of course, sometimes I could benefit from things that you know.
> How can we gather this sort of information to make it more useful to
> everyone?
>
> Mark.
>
> --
> Mark A. Hershberger
> NicheWork LLC
> 717-271-1084
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 27 Jan 2015 20:15:08 +0900 (JST)
> From: Dmitrii Kouznetsov <dima(a)ils.uec.ac.jp>
> To: MediaWiki announcements and site admin list
> <mediawiki-l(a)lists.wikimedia.org>
> Subject: Re: [MediaWiki-l] [mwstake] What should we focus on?
> Message-ID: <alpine.DEB.2.02.1501271847001.25347(a)dima.ils.uec.ac.jp>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Dear Mark. I type my opinion on your request.
>
> 1. About me. I handle the mizugadro.mydns.jp/t
> It seems to work well during almost two years.
> It is not perfect:
> Sometimes, the text disappears after the closing references;
> Sometimes the tumbnail for a picture fails;
> I could not make work the "short name" service,
> Include of PDF files hapened to be different from that for other
> files and difficult to handle;
> Construction and customing of the skins also happened to be difficult;
> I could not handle the antispam service (I locked the self-authorization),
> I doubt, if they can be reproduced by colleagues; so, I do not report them.
> In general, I am glad, that the configuration I could arrange with your help works
> and I am glad, that I can use it without to enter again into details
> of php, html, mysql and other things.
>
> >From above, you see, my skills in wiki are poor. I try to be just user.
> But for the case, if the point of view of a diletant helps you,
> I type some comments below.
>
> 2. Most important extensions:
> Mathjax,
> Poem (I use it to include the codes into the wiki-text)
> Service for references,
> Service for uploading umages
> (I do not remember the names of these extensions).
>
> I should appreciate the extension to provide the
> "short name", if it will be installed by itself, authomatically,
> just answering "yes" at the installing.
> At least two years ago, the handling requested a lot knowledge.
>
> Few years ago, for me, it was a shoke, when first time I realized, that
> the most of services, installed and configured at the widely known vikis
> (wikipedia, citizendium, etc) are not supported by default.
> I believed them to be parts of the core; then it happened that they are
> only extensions, and each of them requires some handling at the
> installation.
>
> The same refers to caching. I do not undertand, why is it so
> difficlut, that each time it should be handled manually.
>
> 2. Independence.
> Often, trying to improve some thing in the set-up,
> I saw, that I destroy some other thing.
> I know, how difficul is to provide the independence,
> but it is very important.
> You cannot underestimate the stupidity of the beginner,
> who deals with a big large package, knowing close to nothing about
> it, with the naive hope, that the professionals did their job, and
> the rest is just to plug and to use.
>
> 3. Compatibility.
> Often the symbols, formatting, formulas, that appear fine at one computer,
> look ugly at another computer. I do not know, if anything can be done
> about this.
>
> 4. Descriptions. When I begun to deal with mediawiki, my first impression
> was, that the descriptions are written in some strange, unknown to me
> language, slightly similar to English.
> It may have sense to count, how many new terms shoud the beginner learn,
> in order to understand the description.
>
> 5. About errors. The beginner does not know the origin of the errors:
> is it a defect of the internet service,
> or some fault in the setting of the router, or that of a server,
> or something is wrong with mysql, or with some configuration files,
> it is due to a mediawiki bug.
> The first impression is "Everything was working, and then - nothing".
> I think, these instructions should begin with very beginning:
> A. Check that your computer is connected to the electric plug.
> B. Check that your monitor, keyboard and mouse are connected to the
> computer.
> C. Check that your compiter is "on" (type "help" in the command line.)
> D. Check, that ... – and so on.
> I exaggerate a bit, but, I hope, you understand this point.
>
> 6. Instructions. Usually, the most difficult for the beginner is
> to understand, what tools are necessary for his/her goals.
> In the internet, there is tradition, that every package
> clams, that namely it can satisfy the needs of the user.
> Usually, the package tries to form these needs, instead.
> I think, mediawiki could be good exception.
> Over-vice, you get questions like
> "What scissors are better to hummer this screw into a wall?"
> Sometimes, the user does not know even the generic names of the tools
> necessary.
>
> 7. Options and setting.
> The configuration files seem to be designed, optimized for the needs of
> the authors of the software, not for the needs of the users.
> Usually, the arbitrary variation of a parameter leads to some non-working
> configuration. I do not know, how to organize it better; may be, my needs
> are different from those of the most of users. But still, you may imagine
> some diletant, who tries various options in order to get the result by
> the method of probes and errors.. So, keep in mund the question:
> What will be, if some stupid admin changes this option?
> I see, this had improved since previous versions of mediawiki,
> but I think, it still can be improoved.
>
> All the above are just my personal impressions.
> Sorry, if I misunderstand the request below.
>
> ================================
> On Mon, 26 Jan 2015, Mark A. Hershberger wrote:
>
> >
> > At the developer summit just now, we've decided to use the tag #mwstake
> > (for twitter, etc) or the subject line prefix (like I've done here) for
> > communication on mediawiki-l for the MW stakeholders group.
> >
> > The first item we'd like to discuss with MediaWiki users is what should
> > we actually focus on?
> >
> > If you use MediaWiki for your own wiki, what sort of things do you think
> > need more attention? How can we help you find out about things you need
> > to know to run your wiki?
> >
> > For example, someone in this meeting said that they ran from git master
> > because they need to run Visual Editor. I told him that I was
> > successfully using VE on MW 1.24.
> >
> > This is the sort of information that would be useful for him, of course,
> > but we need to figure out what other things we need to communicate.
> >
> > And, of course, sometimes I could benefit from things that you know.
> > How can we gather this sort of information to make it more useful to
> > everyone?
> >
> > Mark.
> >
> > --
> > Mark A. Hershberger
> > NicheWork LLC
> > 717-271-1084
> >
> > _______________________________________________
> > MediaWiki-l mailing list
> > To unsubscribe, go to:
> > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>
> ------------------------------
>
> _______________________________________________
> MediaWiki-l mailing list
> MediaWiki-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
>
>
> End of MediaWiki-l Digest, Vol 136, Issue 24
> ********************************************
Hi,
I have a simple question about using anchors in links.
Example link:
[[SamplePage#SampleAnchor]]
Is there any possible way known to get information about the used anchor
in "SamplePage"?
For example with ParserFunction {{#ifeq: <here the anchor text>| compare
text|.....}}?
Greetings
Frank Baxmann
----- Forwarded Message -----
From: Eric Patrizi <epatrizi(a)yahoo.com>
To: John <phoenixoverride(a)gmail.com>
Sent: Saturday, January 24, 2015 6:32 AM
Subject: Re: [MediaWiki-l] Cannot access wiki from internet through D-Link router
Thanks, for the reply. I had to change the $wgServer in my LocalSettings.php file to the IP address of my router's external IP address. It was set to the IP address of my wiki machine (192.168.0.117). I can now access the wiki from the internet. There are some other settings that probably need to be changed as well (e.g. $wgPasswordSender, $wdEmergencyContact)). Now that I know what to look for, I should be able to figure that out.
Thanks again,
Eric
From: John <phoenixoverride(a)gmail.com>
To: Eric Patrizi <epatrizi(a)yahoo.com>; MediaWiki announcements and site admin list <mediawiki-l(a)lists.wikimedia.org>
Sent: Friday, January 23, 2015 9:16 PM
Subject: Re: [MediaWiki-l] Cannot access wiki from internet through D-Link router
Try just port forwarding 80 and 443
On Fri, Jan 23, 2015 at 9:45 PM, Eric Patrizi <epatrizi(a)yahoo.com> wrote:
I have wiki up and running on my home network. I can access the wiki on the LAN side of the router. I cannot access wiki from the external (Internet) side of the router. I have redirected (using virtual server settings in the D-Link router) ports 80 and 443 to my machine running the wiki. When trying to access from Internet, I get a timeout error. I can access the Apache web server from the internet on the same machine, so I thought it should work.
Any ideas or suggestions would be appreciated.
Eric
_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
I have wiki up and running on my home network. I can access the wiki on the LAN side of the router. I cannot access wiki from the external (Internet) side of the router. I have redirected (using virtual server settings in the D-Link router) ports 80 and 443 to my machine running the wiki. When trying to access from Internet, I get a timeout error. I can access the Apache web server from the internet on the same machine, so I thought it should work.
Any ideas or suggestions would be appreciated.
Eric