Re: [Wikitech-l] Video Uploads to Commons
Thank you for adding that. I'm sure when my tool is ready using OAuth, it might be added to the list. Is it possible to run/host a python based application on wmflabs? On Feb 6, 2015 7:25 PM, S Page sp...@wikimedia.org wrote: On Wed, Feb 4, 2015 at 1:28 AM, Nkansah Rexford seanmav...@gmail.com wrote: Its very interesting for me to know similar tools exist in the system. I wish a tool like https://tools.wmflabs.org/videoconvert/ was listed on the ways to upload videos on commons page. I would have used it right away. I added a section Online conversion tools to https://commons.wikimedia.org/wiki/Help:Converting_video -- =S Page WMF Tech writer ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Naming conventions for data centers
... followed by closest major airport. I guess that's supposed to give quick idea where the DC is located? On Feb 6, 2015 12:54 AM, Legoktm legoktm.wikipe...@gmail.com wrote: On 02/05/2015 04:51 PM, Pine W wrote: What is the naming convention for these data centers? https://wikitech.wikimedia.org/wiki/Infrastructure_naming_conventions#Datacenter_Sites -- Legoktm ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Video Uploads to Commons
Thanks for all the ideas and suggestions. Will start with enabling oauth right away. I'm dead in php so I always look for python related hooks. I think this will do for the oauth? http://pythonhosted.org/mwoauth/ As regards the conversion to webm instead of ogv, I tried but couldn't get avconv to process files into the webm format. Perhaps I'm not putting things together right. Will read more on that. Its very interesting for me to know similar tools exist in the system. I wish a tool like https://tools.wmflabs.org/videoconvert/ was listed on the ways to upload videos on commons page. I would have used it right away. Really appreciate all your thoughts. With MediaWiki I wish I was a bit good in php. Thus I always look around for python related packages to interact with the API. But with the oauth module found, I think authentication won't be the 'crude' way I'm doing it now. Will reach out to 'real' users on VP soon too. Hi, there is the tool by Holger which does that using WebM - but it is hosted on WMF Labs. It uses OAuth for unified login and moving the files to Commons. Then, a more elaborate tool for * storing raw material at the Internet Archive * generating patent free WebM proxy clips for editing * rendering high-quality videos * moving these rendered videos to Commons directly is the Video Editing Server, developed by some Wikipedians and a MLT developer, hosted by the Internet Archive: https://wikimedia.meltvideo.com/ It also uses OAuth for login and moving files to Commons. The workflow with this: # upload all your raw files to the server for ## long-term storage ## to make them available to other editors ## to let the server use them in the rendering process # the server transcodes all files into WebM proxy clips # editors download the WebM proxy clips ## do the editing on your computer ## create an MLT project file (eg. using kdenlive or another MLT-based video editor) # upload the project file ## server will replace proxy clips with raw material ## server will render video project ## server will move generated file to Commons It comes with a search engine, meta data forms... it's still pretty new (development started in December '14) but can be used. We plan to add some more features like tagging using Wikidata QIDs (hence allowing multilingual / localised tagging / searching, adding more project file formats and renderer, making old project file revisions available for download, give it a nice vector-based theme, give it a better domain name and SSL certificate... Play with it and have fun! For source code or any issues refer to GitHub: https://github.com/ddennedy/wikimedia-video-editing-server also there see the wiki for the specs and a deployment guide: https://github.com/ddennedy/wikimedia-video-editing-server/wiki /Manuel -- Wikimedia CH - Verein zur Förderung Freien Wissens Lausanne, +41 (21) 34066-22 - www.wikimedia.ch ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Video Uploads to Commons
I couldn't find a tool to convert my videos from whatever format into .ogv outside my PC box before pushing to Commons. I guess there might exist something like that, but perhaps I can't find it. But I made one for myself. Maybe it might be useful to others too. I call it CommonsConvert. Upload any video format, enter username and password, and get the video converted into .ogv format plus pushed to Commons all in one shot. You upload the original video in whatever format, and get it on Commons in .ogv Some rough edges currently, such as can't/don't know/no available means to append license to uploaded video among other issues. Working on the ones I can asap. It uses mwclient module via Django based on Python. Django gives user info to Python, Python calls avconv in a subprocess, and the converted file is relayed to Commons via mwclient module via Media Wiki API. I think not everyone has means/technical know how/interest/time converting videos taken on their PC to an Ogg-Vorbis-whatever format before uploading to Commons. Doing the conversion on a server leaves room for user to focus on getting videos than processing them. I don't know if this is or will be of any interest that someone might wanna use, but I personally would enjoy having a server sitting somewhere convert my videos I want to save onto Commons, than using my local computer doing that boring task. In an email to this list a week or so ago, I 'ranted' about why commons wants a specific format (which if not for commons, I never come across that format anywhere), but has no provision for converting any videos thrown at it into that format of its choice. Well Tool can be found here: khophi.co http://khophi.co/commonsconvert/ http://khophi.co/commonsconvertcommonsconvert http://khophi.co/commonsconvert And this is sample video uploaded using the tool. https://commons.m.wikimedia.org/wiki/File:Testing_file_for_upload_last.ogv (will be deleted soon, likely) What I do not know or have not experimented yet is whether uploading using the api also has the 100mb upload restriction. Will appreciate feedback. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Feature request.
Please endure. That's the way forward now. For now, technically, there's no known or brought-forth solution, I'll recommend you endure. I'm sorry, but that's the reality many people face. On Nov 16, 2014 10:07 PM, Pine W wiki.p...@gmail.com wrote: I have just lost *two hours* of work due to an edit conflict. I thought using my browser's back button would fix it, but the text is gone forever. Argh. Pine *This is an Encyclopedia* https://www.wikipedia.org/ *One gateway to the wide garden of knowledge, where lies The deep rock of our past, in which we must delve The well of our future,The clear water we must leave untainted for those who come after us,The fertile earth, in which truth may grow in bright places, tended by many hands,And the broad fall of sunshine, warming our first steps toward knowing how much we do not know.* *--Catherine Munro* On Thu, Nov 13, 2014 at 3:40 AM, James Forrester jforres...@wikimedia.org wrote: On 13 November 2014 06:40, Federico Leva (Nemo) nemow...@gmail.com wrote: What's the point in being (allegedly) responsible of something you can't influence? Hey Nemo, Unfortunately you've accidentally cropped off all the context of whoever's e-mails to which you were responding. What were you trying to say? J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Feature request.
Indeed Forester, your answer on the wiki research list is outstanding and shines light on what collaborative editing entails. I really appreciate pointing those issues out, and I fully agree. You ended by saying The short answer is that it's a really interesting area of possibilities, but we're going to want to work through a lot of these issues and come up with an actual proposal about what this would mean. My question is, is there currently a proposal to handle the issue of Edit Conflicts for the mean time, before the holy grail wikipedia collaborative editing concept presented at wikimania is realized? Or, we all, new editors and old editors alike, continue to endure, most times, the annoyance that comes with editing conflicts? Has that actual proposal started? I fully agree its a daunting challenge with the realtime editing thing, but before that is achieved (perhaps maybe next 10 years time), I believe there should be a quick 'hack' to that. Can't wait to learn what the proposal finally is. As you explained, I don't think the locking articles like wordpress does will be much sensible in this wikipedia context. thanks for your explanations On Wednesday, November 12, 2014, James Forrester jforres...@wikimedia.org wrote: On 8 November 2014 20:31, Nkansah Rexford nkansahrexf...@gmail.com wrote: One session I really looked forward to at the Wikimania was the one on Visual Editor and the talk on RealTime Editing (the one presented by Erik). Of course, I enjoyed, seeing some of the nice future goals of how realtime editing could be possible, however with very strong huddles to overcome. One slide pointed out the number of edit conflicts that happened in the month of July only: https://plus.google.com/107174506890941499078/posts/NCPzu4G5cbP There were *120k edit conflicts of about 23k registered user accounts* (anonymous conflicts might be higher or around this same value, or even less) The proposals and design concepts of how the concurrent editing could be on Wikimedia projects were/are nice to see, and very hi-tech. However, I considered these proposals and design concepts to be far fetched, at least, at least, looking at how pressing the issue of edit conflicts are. I think that that's a fair assessment. Doing real-time collaborative editing is a quite hard engineering challenge, but it's a much bigger issue for how our users would be affected, and working out some pretty fundamental ways in which MediaWiki would need to change. See https://lists.wikimedia.org/pipermail/wiki-research-l/2014-September/003828.html which I wrote a couple of months ago which outlines some of these issues. I might be the only person that suffers from that problem, thus I ask about. The simple solution to edit conflict in my own opinion isn't that complex, as at least, there's a living example of how it could be. The WordPress* way of resolving edit conflicts, for me, at this point in time, will look more promising and do much better than the highly advanced concepts that were presented, which are not even near to realization, at least for the next 5 years. Until those concepts presented are completed, how many more edit conflicts should be suffered? Losing lots (or even a line of edit) of edits because of editing conflict isn't something to take easily, at least when one has limited time and resources, but voluntarily decided to add content to an article. It's a superficially attractive option that goes completely against the Wikimedia ethos, though. Allowing users to lock pages so that only they can edit them is anti-wiki. It works for WordPress because that's a totally different product; altering this model would massively change the way that people interact with wikis, and I'm not sure it's a reasonable change to make. There are some useful points we're going to reach along the path to proper real-time collaboration, however, which might be better things on which to focus - flagging pages currently being edited, DOM diff-based edit merges and so on. J. -- James D. Forrester Product Manager, Editing Wikimedia Foundation, Inc. jforres...@wikimedia.org | @jdforrester ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tor relay, and freenode
Always thought Wikimedia has a freenode instance, as they do for etherpad. Well then, I think its about time. On Nov 10, 2014 9:29 AM, Pine W wiki.p...@gmail.com wrote: Thanks for the note. Would it be within our mission scope to host a Freenode server? We use Freenode a *lot* for public and private communications. There have been previous discussions about WMF support for upstream services, and WMF has been talking about offering non-monetary support to affiliates, so I think hosting a Freenode server could make sense. Pine On Nov 10, 2014 1:11 AM, Faidon Liambotis fai...@wikimedia.org wrote: Hi, This is just a quick update that as of late October, WMF is officially hosting a Tor relay: https://atlas.torproject.org/#details/DB19E709C9EDB903F75F2E6CA95C84D637B62A02 This is not an exit node, and it's just a small contribution to the network. Really - anyone can do it: https://www.eff.org/torchallenge/ We want to note that editing via Tor is a whole other matter, and I would refer to previous conversations on this list if you have questions about the current state of things. We also currently have no plans to run an exit node or a hidden service, but we're open to suggestions for additional ways in which WMF can support anonymity and privacy. Sincerely, Faidon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Tor relay, and freenode
Hello Antoine Thanks for pointing out. For some reason, I can't access the address. Maybe its down. Pings dont go through at all. Glad to know there's at least one freenode for Wikimedia. But if I may ask, it it official? It happens to be a sub domain of freenode. Not a bad idea, but was expecting to see something like freenode.Wikimedia.org or something like that. On Nov 10, 2014 9:35 AM, Antoine Musso hashar+...@free.fr wrote: Le 10/11/2014 10:28, Pine W a écrit : Thanks for the note. Would it be within our mission scope to host a Freenode server? We use Freenode a *lot* for public and private communications. There have been previous discussions about WMF support for upstream services, and WMF has been talking about offering non-monetary support to affiliates, so I think hosting a Freenode server could make sense. Pine Hello, We do since October 2013, the server is dickson.freenode.net https://wikitech.wikimedia.org/wiki/Dickson -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Feature request.
/listinfo/wikitech-l -- +Rexford https://plus.google.com/+Nkansahrexford | +CG Central https://plus.google.com/b/103109918657638322478/103109918657638322478/posts | +233 266 811 165 l BFCT http://www.blendernetwork.org/member/nkansah-rexford-nyarko/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Feature request.
Looked for it and found this doc on it: http://codex.wordpress.org/Post_Locking Your points are also valid, at least far better than the current diff system which isn't that easy to understand what is actually going on or whatnot. On Nov 8, 2014 10:01 PM, Brian Wolff bawo...@gmail.com wrote: Honestly i dont think anyone's even tried to improve the conflict screen. There's probably a lot of low hanging fruit on the usability of edit conflicts which could be persued that have nothing to do with the hard, real time editing solutions (as cool as those are). If someone is intrested in trying to improve edit conflicts, id reccomend starting with: *only showing relavent parts. If your conflict is in a section, and you were doing a section edit, dont ask user to resolve entire page (this is particularly painful on VP type pages). Furthermore: find some way to present only the conflicted lines (ie what conflict markers show in a source control system) in a user friendly way. *better conflict resolution algorithms. This would require experimentation, but im sure there exists something better for merging natural language documents than just shoving it to gnu diff3. Perhaps even just adding a newline after every sentence (period) so that it merges on a more fine grained level would be appropriate. I imagine there must be papers written on this subject we could look to for advice. I'm unfamilar with what wordpress does for this. Do you have a link describing its process? --bawolff On Nov 8, 2014 4:31 PM, Nkansah Rexford nkansahrexf...@gmail.com wrote: One session I really looked forward to at the Wikimania was the one on Visual Editor and the talk on RealTime Editing (the one presented by Erik). Of course, I enjoyed, seeing some of the nice future goals of how realtime editing could be possible, however with very strong huddles to overcome. One slide pointed out the number of edit conflicts that happened in the month of July only: https://plus.google.com/107174506890941499078/posts/NCPzu4G5cbP There were *120k edit conflicts of about 23k registered user accounts* (anonymous conflicts might be higher or around this same value, or even less) The proposals and design concepts of how the concurrent editing could be on Wikimedia projects were/are nice to see, and very hi-tech. However, I considered these proposals and design concepts to be far fetched, at least, at least, looking at how pressing the issue of edit conflicts are. I might be the only person that suffers from that problem, thus I ask about. The simple solution to edit conflict in my own opinion isn't that complex, as at least, there's a living example of how it could be. The WordPress* way of resolving edit conflicts, for me, at this point in time, will look more promising and do much better than the highly advanced concepts that were presented, which are not even near to realization, at least for the next 5 years. Until those concepts presented are completed, how many more edit conflicts should be suffered? Losing lots (or even a line of edit) of edits because of editing conflict isn't something to take easily, at least when one has limited time and resources, but voluntarily decided to add content to an article. rexford **I'm no wordpress dev, neither have I ever even done coding in php. I mention the wordpress here because, as someone who uses wordpress a lot, and have seen how its editing conflict has been, in a typical way, resolved, I find it impressive, and think Wikipedia of all websites, should have implement that approach long time ago, if not just after wordpress did it.* On Aug 9, 2014 11:58 AM, Pine W wiki.p...@gmail.com javascript:_e(%7B%7D,'cvml','wiki.p...@gmail.com'); wrote: Rexford, it happens that there are 2 Wikimania sessions about concurrent editing starting at 17:00 today in Auditorum I. Pine On Tue, Aug 5, 2014 at 10:38 PM, Quim Gil q...@wikimedia.org javascript:_e(%7B%7D,'cvml','q...@wikimedia.org'); wrote: On Mon, Aug 4, 2014 at 9:50 PM, Pine W wiki.p...@gmail.com javascript:_e(%7B%7D,'cvml','wiki.p...@gmail.com'); wrote: I am asking Quim to provide us an update. Me? :) I'm just an editor who, like many of you, has suffered this problem occasionally. On Mon, Aug 4, 2014 at 10:02 AM, rupert THURNER rupert.thur...@gmail.com javascript:_e(%7B%7D,'cvml','rupert.thur...@gmail.com'); wrote: that would be a hullarious feature! which is btw available in some other opensoure and proprietory wikis. TWiki is an open source wiki and also has (had?) a concept of blocking a page while someone else is editing. This feature might sound less than ideal in the context of, say, Wikipedia when a new Pope is being nominated, but I can see how many editors and MediaWiki adminis have missed such feature at some
Re: [Wikitech-l] Feature request.
The fact that no one has even tried improving the conflict issue in simplest way possible for years now is even something a bit strange. On Nov 8, 2014 10:01 PM, Brian Wolff bawo...@gmail.com wrote: Honestly i dont think anyone's even tried to improve the conflict screen. There's probably a lot of low hanging fruit on the usability of edit conflicts which could be persued that have nothing to do with the hard, real time editing solutions (as cool as those are). If someone is intrested in trying to improve edit conflicts, id reccomend starting with: *only showing relavent parts. If your conflict is in a section, and you were doing a section edit, dont ask user to resolve entire page (this is particularly painful on VP type pages). Furthermore: find some way to present only the conflicted lines (ie what conflict markers show in a source control system) in a user friendly way. *better conflict resolution algorithms. This would require experimentation, but im sure there exists something better for merging natural language documents than just shoving it to gnu diff3. Perhaps even just adding a newline after every sentence (period) so that it merges on a more fine grained level would be appropriate. I imagine there must be papers written on this subject we could look to for advice. I'm unfamilar with what wordpress does for this. Do you have a link describing its process? --bawolff On Nov 8, 2014 4:31 PM, Nkansah Rexford nkansahrexf...@gmail.com wrote: One session I really looked forward to at the Wikimania was the one on Visual Editor and the talk on RealTime Editing (the one presented by Erik). Of course, I enjoyed, seeing some of the nice future goals of how realtime editing could be possible, however with very strong huddles to overcome. One slide pointed out the number of edit conflicts that happened in the month of July only: https://plus.google.com/107174506890941499078/posts/NCPzu4G5cbP There were *120k edit conflicts of about 23k registered user accounts* (anonymous conflicts might be higher or around this same value, or even less) The proposals and design concepts of how the concurrent editing could be on Wikimedia projects were/are nice to see, and very hi-tech. However, I considered these proposals and design concepts to be far fetched, at least, at least, looking at how pressing the issue of edit conflicts are. I might be the only person that suffers from that problem, thus I ask about. The simple solution to edit conflict in my own opinion isn't that complex, as at least, there's a living example of how it could be. The WordPress* way of resolving edit conflicts, for me, at this point in time, will look more promising and do much better than the highly advanced concepts that were presented, which are not even near to realization, at least for the next 5 years. Until those concepts presented are completed, how many more edit conflicts should be suffered? Losing lots (or even a line of edit) of edits because of editing conflict isn't something to take easily, at least when one has limited time and resources, but voluntarily decided to add content to an article. rexford **I'm no wordpress dev, neither have I ever even done coding in php. I mention the wordpress here because, as someone who uses wordpress a lot, and have seen how its editing conflict has been, in a typical way, resolved, I find it impressive, and think Wikipedia of all websites, should have implement that approach long time ago, if not just after wordpress did it.* On Aug 9, 2014 11:58 AM, Pine W wiki.p...@gmail.com javascript:_e(%7B%7D,'cvml','wiki.p...@gmail.com'); wrote: Rexford, it happens that there are 2 Wikimania sessions about concurrent editing starting at 17:00 today in Auditorum I. Pine On Tue, Aug 5, 2014 at 10:38 PM, Quim Gil q...@wikimedia.org javascript:_e(%7B%7D,'cvml','q...@wikimedia.org'); wrote: On Mon, Aug 4, 2014 at 9:50 PM, Pine W wiki.p...@gmail.com javascript:_e(%7B%7D,'cvml','wiki.p...@gmail.com'); wrote: I am asking Quim to provide us an update. Me? :) I'm just an editor who, like many of you, has suffered this problem occasionally. On Mon, Aug 4, 2014 at 10:02 AM, rupert THURNER rupert.thur...@gmail.com javascript:_e(%7B%7D,'cvml','rupert.thur...@gmail.com'); wrote: that would be a hullarious feature! which is btw available in some other opensoure and proprietory wikis. TWiki is an open source wiki and also has (had?) a concept of blocking a page while someone else is editing. This feature might sound less than ideal in the context of, say, Wikipedia when a new Pope is being nominated, but I can see how many editors and MediaWiki adminis have missed such feature at some point. If I understood correctly, VisualEditor already represents an improvement vs
Re: [Wikitech-l] Realtime common upload plugin - wordpress
Thanks Petr. Will give it a try. +Rexford https://plus.google.com/+Nkansahrexford | +CG Central https://plus.google.com/b/103109918657638322478/103109918657638322478/posts | +233 266 811 165 l BFCT http://www.blendernetwork.org/member/nkansah-rexford-nyarko/ On Mon, Sep 1, 2014 at 9:41 AM, Petr Kadlec petr.kad...@gmail.com wrote: Hi, On Thu, Aug 28, 2014 at 1:41 PM, Nkansah Rexford seanmav...@gmail.com wrote: Is there any way to display images uploaded into a particular category on Wikimedia Commons to be displayed in realtime on a WordPress site? Like a plugin that follows a particular category on commons and displays any images that are added to it? Kinda a feeder? Well, there is Magnus' CatFood https://tools.wmflabs.org/catfood/catfood.php, which creates an RSS feed from newly added items in a specified category. And I guess there could be a WordPress plugin which displays the content of an RSS feed? -- [[cs:User:Mormegil | Petr Kadlec]] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Realtime common upload plugin - wordpress
Hi, Is there any way to display images uploaded into a particular category on Wikimedia Commons to be displayed in realtime on a WordPress site? Like a plugin that follows a particular category on commons and displays any images that are added to it? Kinda a feeder? Thanks Rexford | google.com/+Nkansahrexford | sent from Smartphone ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Future platforms, devices, and consumers
Thanks Jeroen, you just reminded me I have a thread here to respond to. I
agree with you points.
I said revamp the mediawiki from ground up because I think the mediawiki
was developed some years ago, and its obvious there are many changes that
have taken effect that need adapting to.
Revamping here doesn't mean deleting all the code for mediawiki, and
starting from the first function name { bla bla } thing and coming up.
However I mean sitting back, and spending time to extract the actual
portion that is required for the basic functioning of the wiki, remove the
portions that are not needed, adapt it for today's best practices and
features, and as the word Revamp means: *give new and improved form,
structure, or appearance to.*
The WikiWand guys did a similar thing to the look of Wikipedia, and I think
they're in the right direction. Adapting to changes on the wikis, I think
its one of the hard-to-change things the wikimedia ever want to do, and
same with the MediaWiki system.
Though most of the changes to the WikiWand thing were UI based in
particular, the MediaWiki system can also take a similar approach and
revamp things up to improve speed and efficiency, and will give room for
more possibilities, I think.
I think when the media wiki is re-made today, decisions that'll go into it
will be different from the ones made in its beginning.
rexford | google.com/+Nkansahrexford | sent from smartphone
On Aug 18, 2014 10:17 PM, Jeroen De Dauw jeroended...@gmail.com wrote:
Hey,
Hi Rexford,
What objectives would we achieve if we were to revamp the MediaWiki
system
from ground up? Even if we pretend that we have infinite financial and
human resources to do this, I am not sure what we would accomplsh, and we
would likely introduce a lot of new reliability and security bugs.
I can't answer for Rexford, though can provide you with a reply of my own.
You are quite right that the resources needed to rewrite a software as big
and complex as MediaWiki from ground up in one go are not realistic. I
think this is simply not feasible and a bad idea to begin with. There is
plenty of good writing on the topic of migrating away from legacy systems,
often cautioning against the big rewrite.
That does not mean that moving away from the current platform is a bad
idea. Of course there needs to be good reason to do so. Is the current
platform causing problems severe enough to warrant changing direction? Look
at all the effort being put into the software surrounding Wikipedia and
associated projects. A lot of enthusiastic and smart people are spending
plenty of time on it. So how come progress has slowed down so much? How
come we cannot easy add new functionality? What exactly is causing all this
effort to be spend so inefficiently? And how much more would we be able to
achieve if those issues where not there?
One concern with rewriting or redesigning things that I've seen outlined
often is that it is easy to just end up at the same place again. If no
effort is put into identifying why the old system ended up in a bad state,
then it's naive to expect the new one will not suffer the same fate.
and we would likely introduce a lot of new reliability and security bugs.
Is that something inherent to writing new software or migrating away from
legacy systems? Or is that simply what would happen if such a task was
attempted without altering development practices first?
Cheers
--
Jeroen De Dauw - http://www.bn2vs.com
Software craftsmanship advocate
Evil software architect at Wikimedia Germany
~=[,,_,,]:3
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Recruiting for Wikimedia security newsletter
Nice idea, I think rexford | google.com/+Nkansahrexford | sent from smartphone On Aug 18, 2014 9:38 PM, Pine W wiki.p...@gmail.com wrote: Hi, In collaboration with Chris Steipp, I am considering starting a monthly security newsletter for Wikimedia, focused on common risks and mitigation techniques. The target audience is the broad Wikimedia community including developers, WMF and chapter employees, and volunteers with high risk accounts. Example topics: Phishing Coding best practices Wifi security Securing data stored on cell phones Check fraud Preventing insider theft of funds in Wikimedia organizations If you are interested in contributing to the newsletter please email me off list. Thanks, Pine ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] need for an app? (was: Future platforms, devices, and consumers)
I agree with you too on that. apps are redundant, unless one has the resources to support. 'Nativity' is great and can unleash some potentials, which are hard to accomplish via browsers. I personally find the mobile site for Wikipedia great enough and I use it for editing instead of the native app. rexford | google.com/+Nkansahrexford | sent from smartphone On Aug 16, 2014 9:28 AM, svetlana svetl...@fastmail.com.au wrote: On Sat, 16 Aug 2014, at 12:45, Nkansah Rexford wrote: [...] The Wikipedia app is currently under good development and I think its doing great. We don't need apps. We need mobile websites which work as good as an app does. Oh, the waste of effort. I truly pledge you to work together to make a website which is so good that an 'app' is redundant. svetlana ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] need for an app? (was: Future platforms, devices, and consumers)
I agree with you too on that. apps are redundant, unless one has the resources to support. 'Nativity' is great and can unleash some potentials, which are hard to accomplish via browsers. I personally find the mobile site for Wikipedia great enough and I use it for editing instead of the native app. rexford | google.com/+Nkansahrexford | sent from smartphone On Aug 16, 2014 9:34 AM, Nkansah Rexford nkansahrexf...@gmail.com wrote: I agree with you too on that. apps are redundant, unless one has the resources to support. 'Nativity' is great and can unleash some potentials, which are hard to accomplish via browsers. I personally find the mobile site for Wikipedia great enough and I use it for editing instead of the native app. rexford | google.com/+Nkansahrexford | sent from smartphone On Aug 16, 2014 9:28 AM, svetlana svetl...@fastmail.com.au wrote: On Sat, 16 Aug 2014, at 12:45, Nkansah Rexford wrote: [...] The Wikipedia app is currently under good development and I think its doing great. We don't need apps. We need mobile websites which work as good as an app does. Oh, the waste of effort. I truly pledge you to work together to make a website which is so good that an 'app' is redundant. svetlana ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Future platforms, devices, and consumers
@svetlana, I thought http is rather being strengthened via REST? The Internet of things all will better work with HTTP. From your list of items, @pine, I will recommend, smart watches, AI, and smart homes and buildings. But why would Wikimedia wanna include the yet-to-well-surface technologies when mere edit conflicts isn't solved on the Wiki? The Wikipedia app is currently under good development and I think its doing great. Your question is worth considering, but in reality, I don't think Wikimedia will be up to the task, even if one from your list is chosen. Just pondering over how many months, if not years its taken to get the Wikipedia app in shape, not to mention the Wikimedia commons app that's seems to have been abandoned as it hardly enjoys updates, makes me wonder if Wikimedia will ever finish a native application should they wanna even try AI. For me, if I should suggest what should be Wikimedia's biggest priority today will be to revamp the MediaWiki system from ground up. rexford | google.com/+Nkansahrexford | sent from smartphone On Aug 16, 2014 12:43 AM, svetlana svetl...@fastmail.com.au wrote: On Sat, 16 Aug 2014, at 07:21, Pine W wrote: Following up on Lila's Wikimania keynote: what platforms and devices should we have in mind when making decisions today or in the near future about Wikimedia content creation and delivery? also think of something outside of web browser ? and then also outside of http protocol ? svetlana ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Feature request.
Thanks for the update Quim. I hope it gets done as soon as possible, as it'll go a long way to help multiple concurrent edits. I think it's been lacking for a long time now, and can't wait to see it in action. +Rexford https://plus.google.com/+Nkansahrexford | +CG Central https://plus.google.com/b/103109918657638322478/103109918657638322478/posts | +233 266 811 165 l BFCT http://www.blendernetwork.org/member/nkansah-rexford-nyarko/ On Tue, Aug 5, 2014 at 10:38 PM, Quim Gil q...@wikimedia.org wrote: On Mon, Aug 4, 2014 at 9:50 PM, Pine W wiki.p...@gmail.com wrote: I am asking Quim to provide us an update. Me? :) I'm just an editor who, like many of you, has suffered this problem occasionally. On Mon, Aug 4, 2014 at 10:02 AM, rupert THURNER rupert.thur...@gmail.com wrote: that would be a hullarious feature! which is btw available in some other opensoure and proprietory wikis. TWiki is an open source wiki and also has (had?) a concept of blocking a page while someone else is editing. This feature might sound less than ideal in the context of, say, Wikipedia when a new Pope is being nominated, but I can see how many editors and MediaWiki adminis have missed such feature at some point. If I understood correctly, VisualEditor already represents an improvement vs Wikitext because the chances of triggering conflicting edits are smaller, because of the way the actual content is modified and updated in every edit. There was some idea to add to VisualEditor Etherpad-like concurrent and real-time editing, but maybe JamesF or marktraceur know better the current status. Rupert, in any case you see that the trend is going in the direction of being more efficient handling concurrent edits. Blocking pages while another editor supposedly is working on them might work in e.g. corporate wikis where most f the times the Edit link is clicked for a reason, but it could be potentially counterproductive in sites like Wikipedia. Just my 2 cents not even being an expert in this topic. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Feature request.
Hi all, I'm Rexford, and just posting here for the first time. Please inform if this place isn't the right area to suggest features. I was encouraged to request features here. Please correct me if I'm wrong. Its about edit conflict on Wikipedia and other projects. It happens when I get into an article to edit, but before I could save, someone else goes into the article, edits and save. It happens to myself and many out there. Sometimes many minutes work of changes can be lost. The feature request is this: When a person starts editing an article, and another person tries to edit that same article, he or she gets a message on screen that the article is already engaged. This suggestion is similar to how WordPress informs the second person who tries to edit a page whiles someone else is already editing. Its likely one wouldn't like to edit a page when he or she knows someone is in it editing. I think its much better that way than allowing multiple edits on the page but allowing one persons edit to go in per save. Thanks. rexford | google.com/+Nkansahrexford | sent from smartphone ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
