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 <[email protected]> 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 <[email protected]> 
>> 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 <[email protected]>
>> wrote:
>> 
>>> Just to counter that, you are overlooking a crucial point ...
>>>> On Dec 7, 2015, at 11:44 AM, Ray Paseur <[email protected]> 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

Reply via email to