[Wikitech-l] IDE for wiki-markup
Hi everyone! What tools exist to edit templates and other article that are rich with wiki markup? I mean not WYSIWYG editor but something like IDE for markup: 1) good highlighting 2) auto-completion, guessing the template parameters 3) Dealing with curly brackets (at least showing where the closing bracket is) 4) hings and auto-completion for parser functions WikEd [1] is slightly better than the default editor but still... is there something else? [1] http://www.mediawiki.org/wiki/Extension:WikEd - Yury Katkov, WikiVote ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Gerrit Atom feeds
This is very useful and I'm definitely interested in using such a thing to keep tabs on growing numbers of contributions. I've also been experimenting with a python script to send email digests of outstanding pull requests to the mobile team from the MobileFrontend project. It is written in python and it lists all outstanding pull requests with a link and the current status (-2,-1,0,+1,+2) and groups them by the contributor. If a contributor doesn't have a @wikimedia.org e-mail address they are flagged with [VOLUNTEER] (as I believe these contributions are much more important and should get more attention). I currently have this setup to send on a daily basis via a cronjob. The code is a bit rough around the edges but achieves the goal I had in mind: Feel free to fork and improve it if this is interesting: https://github.com/jdlrobson/gerrit-review-mailbot On Wed, Nov 7, 2012 at 11:25 AM, Ori Livneh o...@wikimedia.org wrote: I built a simple Atom service for Gerrit, available at: http://schmerrit.wmflabs.org/gerrit/changes/repository.atom For example, here's the feed for mediawiki/core: http://schmerrit.wmflabs.org/gerrit/changes/mediawiki/core.atom Is this useful for people? It scratches a personal itch I've had, but I'll only put in the trouble to make it robust and reliable if someone other than me finds it useful -- so please let me know if you do. Right now there's no caching at all -- all the content is generated dynamically by making calls against Gerrit's API. So go easy on it. Ori ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson http://jonrobson.me.uk @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MW 1.20 backwards compatibility in extensions
Tim Starling tstarl...@wikimedia.org wrote: All extension branches were removed during the migration to Git. Very few extensions have branches for MW core major version support. There's no longer a simple way to branch all extensions when a core release is updated, and nobody has volunteered to write a script. So we're back to the situation we had in MW 1.9 and earlier, where it's usually not possible to run any actively maintained extension against an MW core that's not the current trunk. Given this, I think code reviewers should insist on backwards compatibility with MW 1.20 for commits to the master branch of extensions that are commonly used outside Wikimedia, at least until the release management issue is solved. ACK. Also, I do not think that branching in accord with core is the right thing to do for extensions as then a user is faced with a squared number of potential combinations. Extensions instead should have proper versioning (of their own), with clearly stated support for/requirement of a Me- diaWiki release/HEAD, so no extension releases are made just to increase the version number even when no code was changed, and on the other hand breaking changes in exten- sions can be handled in different extension releases, i. e., you don't have to update to LiquidThread 3.0 just to get compatibility with MediaWiki 1.21. Tim ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
Andre Klapper aklap...@wikimedia.org wrote in message news:1352303717.10307.18.ca...@embrace.foo... On Tue, 2012-11-06 at 14:10 -0800, Quim Gil wrote: Andre, I don't think we need a new resolution WAITING_FOR_UPSTREAM. After reading Krinkle's and your email I agree that there is no urgent need for it. This could still be reevaluated in the future. Please therefore mark the suggestion as RESOLVED LATER :-) - HappyDog ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Wikidata review status
Hi all, we have here a number of bugfixes and testfixes and other stuff where some reviewing input would be very appreciated. == Bugfixes == * There was some vanishing content https://bugzilla.wikimedia.org/show_bug.cgi?id=41352 , and a temporary fix for it. Here is a proper fix for the problem, reverting the temp and doing proper merge: https://gerrit.wikimedia.org/r/#/c/29981/ * Revision sometimes had errors https://bugzilla.wikimedia.org/show_bug.cgi?id=41244 , here is a fix for that: https://gerrit.wikimedia.org/r/#/c/30624/ * Use ContentHandler together with OAI. There are two changesets that have been both reviewed by Brion and accepted, but they have not been validated. We can go ahead and validate ourselves, but I guess that is bad practice. So if someone can validate these two changesets, it would be awesome: https://gerrit.wikimedia.org/r/#/c/30722/ and https://gerrit.wikimedia.org/r/#/c/30724/ == Better tests == * EditPages does not have enough tests! We have a changeset that does not solve that issue, but it improves it: https://gerrit.wikimedia.org/r/#/c/29973/ * Some core test was assuming wikitext in main namespace, which is corrected here https://gerrit.wikimedia.org/r/#/c/28014/ == Refactoring == * New hook to let extensions override the ContentHandler model https://gerrit.wikimedia.org/r/#/c/28199/ * Use the new hook https://gerrit.wikimedia.org/r/#/c/28201/ == Puppet and Vagrant setup == * We are working on polishing the Puppet script for Wikidata: https://gerrit.wikimedia.org/r/#/c/30593/ (this will also lead directly to the Vagrant setup) == Ongoing discussions == * How will the data from Wikidata get to the Wikipedias? ** http://www.gossamer-threads.com/lists/wiki/wikitech/309727 -- seems to be the most current place ** http://meta.wikimedia.org/wiki/Wikidata/Notes/Change_propagation - a bit out of date ** http://meta.wikimedia.org/wiki/Talk:Wikidata/Notes/Change_propagation * ULS and caching do not go well together currently, and both are used on Wikidata. Can you help us? ** https://bugzilla.wikimedia.org/show_bug.cgi?id=41451 (most of the discussion seems here) ** http://www.gossamer-threads.com/lists/wiki/wikitech/310807 ** https://gerrit.wikimedia.org/r/#/c/32030/ We invite input, comments, merges, and chocolate. Cheers, Denny -- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Duplicate API files
So I'm trying to figure out if there's some logic behind the similarly named files in the API includes: includes/api/ApiQueryAllimages.php includes/api/ApiQueryAllImages.php includes/api/ApiQueryAllmessages.php includes/api/ApiQueryAllMessages.php includes/api/ApiQueryAllpages.php includes/api/ApiQueryAllPages.php The capitalized versions dont exist before: commit 720c1b7be0d881f782e227ac7a2b86eab996fff3 Author: Petr Onderka gsv...@gmail.com Date: Wed Apr 11 17:10:22 2012 +0200 Corrected capitalization in the file and class names of API modules Change-Id: I8f317e458ee0f8706434e43a7890cda530595e64 And the non-capitalized versions haven't been edited after. So there's this broken git history. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Duplicate API files
On Fri, Nov 9, 2012 at 10:16 AM, OQ overlo...@gmail.com wrote: So I'm trying to figure out if there's some logic behind the similarly named files in the API includes: Actually nevermind, I realized those uncapitalized files in my directory are untracked, some reason they weren't cleaned up, and I forgot I took out the --follow argument to git log. So . . .yea, I need my coffee. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fwd: [Tech/Product] Engineering/Product org structure
Thank you for the explanations. On 11/07/2012 11:47 AM, Terry Chay wrote: It turns out we use a lot of industry terminology, without realizing that we are poorly communicating what that means to most people. Actually I'm familiar with industry terminology, and also with the wrong assumptions and prejudices it carries many times. I know *you* get it right but a basic goal of any reorg is that *everybody* gets it right now and in the future. While it makes total sense to organize Product Management, Design and Analytics under Product Development, it feels old school and odd to leave out the software engineers fully dedicated to product development. It enforces the old vision that software development is something that comes apart and after the product definition. But being Erik (a software developer himself) the proposed VP in that area I don't need to insist in this point. The current proposal of having software developers working on products (Language, Mobile, Platform...) together with Operations (sysadmins, not directly involved in product development) feels just as old school and odd. The common denominator seems to be teams that know to code, the command line dudes, etc. I might be mistaken, but it feels as consistent as a VP of Presentations overseeing Marketing, Analytics, Design and other teams with high communications skills and able to produce great slides. :) And whoever leads the proposed Engineering team still would need to deal at a high level with two very different agendas: those from teams actually developing software features and those from the operations teams, the latter probably still complaining that they don't get as much attention at the top level. So... If the goals are narrowing focus + scale the dept, and take seriously our identity as a tech org (as stated by Sue) (Erik says) then why not flattening more all this tech structure? Something like - Product Management. - Design. - Software development. -- Features -- MediaWiki. -- Language. -- Mobile. - Operations. - Analytics. This would mean 5 tech managers (already leading their teams) where now you have Erik alone, 4 of them focused on product development + Operations. Erik himself could act as EVP overseeing the product development activities, since this is the narrowed focus now. He should focus on vision, strategy and glue between the tech teams and with the rest of WMF. The reporting and leadership of each team would be done by those 5 managers, now interacting with Sue non-tech managers more often. Doesn't this sound like a more flat and scalable org, with a clearer tech org identity? PS: yes, it's easy for an outsider to shuffle proposals without much background and knowledge of the day to day. :) But since you asked for feedback... I hope it's useful, regardless of what you decide at the end. Thank you for listening! -- Quim ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
