Apart from technical ability, there is also practical ability, tharpenator.
I guess I'd be able to install VisualEditor for example, but unfortunately
I'm not the owner of a server and I have no command-line access. No
Parsoid, no VisualEditor
This not only makes me jealous of the "real" Wikipedia, but I'm also
struggling with diminishing support for the other editors like WYSIWYG.
On Mon, Dec 7, 2015 at 11:31 PM, <tharpenator(a)gmail.com> wrote:
Bill, I think you're right there's different
classes of Mediawiki
administrators, but I also think you're missing the bigger picture. I use
composer, the command line, etc., and find it's great. The nexus of the
problem is the one you identified: the development of Mediawiki is almost
100% directed by the needs of Wikipedia, which is understandable, but also
very limiting. I don't want a command GUI based administration experience
for me, but I want it as an option for the mass majority of people who will
move on to an easier software if they don't have it. Why should we care if
people move on? Options. The more people who use Mediawiki the better the
software will be become. More & better extensions will be created faster,
more skins will be created, etc., the easier the software is to use. How
many more plugins & extensions exist in the Joomla & Wordpress ecosystems
than Mediawiki's?
Why did Mediawiki finally come out with a VisualEditor? Because of concern
about the declining number of editors in Wikipedia. The mass majority of
world wants to just write without concern for syntax. Creating a
VisualEditor was an exercise in making it easy for new Wikipedians (I know
there was a revolt about that, but that's another story). Maybe, just
maybe, the same thought process that is directing the development of easier
end user interfaces could be directed at making it easier for more people
to use the software (maybe installing VisualEditor should be as easy as
using it). The mission of Wikipedia is to empower people by giving free
access to knowledge (paraphrase); shouldn't Mediawiki empower more people
also (not just the technical able)?
Sent from my iPad
On Dec 7, 2015, at 1:25 PM, Bill Traynor
<btraynor(a)gmail.com> wrote:
Perhaps I'm confused, but it sounds to me like there are certain
classes of MediaWiki administrators out there. There's those who
would prefer a hands free experience, or at the very least a point and
click GUI-based administration experience and those that are would
prefer a more command-line based, power-user administrative
experience. Am I wrong?
Personally, I fall in the latter group. I prefer to track MediaWiki
and all extensions from the command line using Git. I've never used
Composer up to this point and have had no problems.
My only gripe about MediaWiki is that the development road map seems
to be directed foremost by the needs of Wikimedia in support of
Wikipedia. Of course, I can't really complain as it's FOSS and if I
was highly motivated, I could develop the things I really want.
Examples being somewhat "enterprisey", like better Oracle support,
finer grained and flexible content management, etc. etc.
> On Mon, Dec 7, 2015 at 3:55 PM, Francis Franck <
francis.franck(a)gmail.com> wrote:
> I'm afraid you've got a point there,
Boris. Your not alone.
>
> Contrary to you, I 've (up to now) tried to keep everything up to date.
I
> must now admit that the advantages of doing
so are rapidly vanishing.
Too
> often this ends in a time consuming trial and
error, leading into fault
> messages and malfunction, hence a loss of confidence. I think I will
change
> policies and keep things as they are until I
notice a more coherent
upgrade
> approach.
>
> On Mon, Dec 7, 2015 at 9:34 PM, Boris Steipe <boris.steipe(a)utoronto.ca>
> wrote:
>
>> Just to counter that, you are overlooking a crucial point ...
>>> On Dec 7, 2015, at 11:44 AM, Ray Paseur <ray.paseur(a)armedia.com>
wrote:
>>>
>>> I believe that using the latest software is almost always a good idea.
>> We are going to upgrade eventually - why deny ourselves the benefits
of
the
>> latest software by putting off the
upgrades? The only argument in
favor of
>> delay would be a breaking change, and
this is something that the
authors of
>> the software must publicize.
>>
>> I hold off updates as long as at all possible, the reason being that
over
>> the last years new versions of the
software have almost never come with
>> tangible benefits to my core use. It is almost always just fixing
>> edge-cases we don't care about and better support for things we don't
use.
>> Why? Because we have developed a workflow
around the software as it
existed
>> about three years ago and there is really
no reason to change that. The
>> benefit of not using the latest is that we get to skip releases and
frankly
>> every single release just takes way, way
to long to install and verify
and
>> fix across our multiple Wikis. Every
release I can skip gives me half
a day
>> of my life!
>>
>> The release cycles are too short. As far as I'm concerned, MediaWiki
works
>> oK, if it would do just what it does;
that would be nice, and aspiring
to
>> anything else is just not what I'm
interested in. The only reason why
I'm
>> constantly on the lookout for
alternatives to MW are the frequent
>> required/recommended updates.
>>
>> I'm pretty sure I'm not alone in this.
>>
>> Now, if a new version would come out that would autoupdate and
configure
itself and make sure it keeps on working with my
(completely standard)
extensions, that would be nice. Too modern?
Boris
_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
_______________________________________________
MediaWiki-l mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l