Re: [Wikitech-l] MediaWiki API at Codecademy?
Is it possible to run other MediaWiki courses on codeacademy? The Extension Development and the Core Development for example? - Yury Katkov, WikiVote On Fri, Feb 8, 2013 at 3:20 AM, Yuri Astrakhan yuriastrak...@gmail.com wrote: I will be happy to part-take in this, as I do have some experience with the API :) I am heading the API v2 project, and this would be a natural extension of that. * RFC http://www.mediawiki.org/wiki/Requests_for_comment/API_Future * Action/Parameter Cleanuphttp://www.mediawiki.org/wiki/Requests_for_comment/API_Future/Naming_Cleanup On Thu, Feb 7, 2013 at 6:12 PM, Quim Gil q...@wikimedia.org wrote: Long story short: the MediaWiki API could be included at http://www.codecademy.com/**tracks/apishttp://www.codecademy.com/tracks/apis if someone wants to do the work. Codecademy is happy to have us there. I think it is a good idea, in need of someone willing to drive this: - It is a good excuse to improve our API documentation at mediawiki.org. - Codecademy is a good place to reach to more developers. - Maybe it is a good chance for someone to take this as a paid job? The Wikimedia movement wants to spread the 1,3T of content we have, and get more free content from as many channels as possible. Our API plays a big role on this. Therefore, I *personally* believe that a project to update the API documentation at mediawiki.org and have corresponding exercises at Codecademy has a chance to receive a grant if the proposal and the candidate(s) are solid. Interested? Let me help you. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/**User:Qgilhttp://www.mediawiki.org/wiki/User:Qgil __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://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] Corporate needs are different (RE: How can we help Corporations use MW?)
Hi Dan, thanks a lot for the insights to the vistaprint MediaWiki ecosystem. Did you give Semantic MediaWiki a try? /Alexander Am 07.02.2013 22:31, schrieb Daniel Barrett: Vistaprint (www.vistaprint.com) has a hugely successful MediaWiki system internally. 150,000+ topics, 1000+ active users across several continents, five years of history, and a fully supported team of developers to create extensions. (We are looking into open-sourcing some of them.) The main requests from our corporate users are: 0. WYSIWIG editor. No surprise here. 1. A desire for a department to have their own space on the wiki. I'm not talking about access control, but (1) customized look feel, and (2) ability to narrow searches to find articles only within that space. The closest related concept in MediaWiki is the namespace, which can have its own CSS styling, and you can search within a namespace using Lucene with the syntax NamespaceName:SearchString. However, this is not a pleasant solution, because it's cumbersome to precede every article title with NamespaceName: when you create, link, and search. If the *concept* of namespaces could be decoupled from its title syntax, this would be a big win for us. So a namespace would be a first-class property of an article (like it is in the database), and not a prefix of the article title (at the UI level). I've been thinking about writing an extension that provides this kind of UI when creating articles, searching for them, linking, etc. Some way to search within categories reliably would also be a huge win. Lucene provides incategory: but it misses all articles with transcluded category tags. 2. Hierarchy. Departments want not only their own space, they want subspaces beneath it. For example, Human Resources wiki area with sub-areas of Payroll, Benefits, and Recruiting. I realize Confluence supports this... but we decided against Confluence because you have to choose an article's area when you create it (at least when we evaluated Confluence years ago). This is a mental barrier to creating an article, if you don't know where you want to put it yet. MediaWiki is so much better in this regard -- if you want an article, just make it, and don't worry where it goes since the main namespace is flat. I've been thinking about writing an extension that superimposes a hierarchy on existing namespaces, and what the implications would be for the rest of the MediaWiki UI. It's an interesting problem. Anyone tried it? 3. Tools for organizing large groups of articles. Categories and namespaces are great, and the DPL extension helps a lot. But when (say) the Legal department creates 700 articles that all begin with the words Legal department (e.g., Legal department policies, Legal department meeting 2012-07-01, Legal department lunch, etc.), suddenly the AJAX auto-suggest search box becomes a real pain for finding Legal department articles. This is SO COMMON in a corporate environment with many departments, as people try to game the search box by titling all their articles with Legal department... until suddenly it doesn't scale and they're stuck. I'd like to see tools for easily retitling and recategorizing large numbers of articles at once. 4. Integration with popular corporate tools like MS Office, MS Exchange, etc. We've spent thousands of hours doing this: for example, an extension that embeds an Excel spreadsheet in a wiki page (read-only, using a $10,000 commercial Excel-to-HTML translator as a back-end), and we're looking at embedding Exchange calendars in wiki pages next. 5. Corporate reorganizations and article titles. In any company, the names and relationships of departments change. What do you do when 10,000 wiki links refer to the old department name? Sure, you can move the article Finance department to Global Finance department and let redirects handle the rest: now your links work. But they still have the old department name, and global search-and-replace is truly scary when wikitext might get altered by accident. Also, there's the category called Finance department. You can't rename categories easily. I know you can do it with Pywikipedia, but it's slow and risky (e.g., Pywikipedia used to have a bug that killednoinclude tags around categories it changed). Categories should be fully first-class so renames are as simple as article title changes. Hope this was insightful/educational... DanB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- semantic::apps by gesinn.it Business Applications with Semantic Mediawiki. http://semantic-apps.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Resign
Dear List(s), Currently I'm inactive for Wikimedia after a lot of things changed. The latest change is that I'm now working for a big datacentre and I do not feel that I have enough time for other things. I already got a few mails that I was collecting hats, so hereby I stop as: LangCom member Administrator for Mediawiki-l Administrator for Wikitech I thank you all. -- Met vriendelijke groet, Huib Laurens ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Langcom-l] Resign
Thank you very much for your work, Huib. I sincerely hope to work with you again! -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore 2013/2/8 Huib Laurens sterke...@gmail.com: Dear List(s), Currently I'm inactive for Wikimedia after a lot of things changed. The latest change is that I'm now working for a big datacentre and I do not feel that I have enough time for other things. I already got a few mails that I was collecting hats, so hereby I stop as: LangCom member Administrator for Mediawiki-l Administrator for Wikitech I thank you all. -- Met vriendelijke groet, Huib Laurens ___ Langcom-l mailing list langco...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/langcom-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Gerrit 2.6 - coming to a server near you
On Mon, Feb 4, 2013 at 6:44 AM, Chad innocentkil...@gmail.com wrote: Hi, After much delay, Gerrit 2.6 will be coming to our servers. This release brings a *lot* of really cool features and fixes, but I'd like to outline a couple of the major ones: I realized a little bit ago that I was a bit ambitious in calling the deployment 2.6, so please let me clarify. Gerrit doesn't name their master 2.6alpha like we do 1.21alpha, which was the source of my confusion. We're actually going to use 2.5.1-1225-gd52acbc, which is based on Wednesday's nightly build of d52acbc from master. This is effectively what will become 2.6 upstream when they finally release ;-) Just wanted to be explicit about which version we're deploying, since I got some questions on IRC a bit ago about 2.5 vs. 2.6. Rest assured--we will still be getting the latest and greatest. And we're still on target for late Monday/early Tuesday. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)
1. A desire for a department to have their own space on the wiki. In our organisation (CUSTIS, Russia) we easily solve it by creating one primary wiki + separate ones for different departments. It's just a normal wiki family with shared code. Very simple solution without any extensions. The main disadvantage is inability to search on all wikis with a single search request, but in practice I've had very little requests for this feature. So it's probably not that oftenly needed. I'm not talking about access control And we also have IntraACL for access control (forked from HaloACL). Still not an ideal solution, but we'll probably improve it more. 2. Hierarchy. Departments want not only their own space, they want subspaces beneath it. For example, Human Resources wiki area with sub-areas of Payroll, Benefits, and Recruiting. I realize Confluence supports this... but we decided against Confluence because you have to choose an article's area when you create it (at least when we evaluated Confluence years ago). This is a mental barrier to creating an article, if you don't know where you want to put it yet. MediaWiki is so much better in this regard -- if you want an article, just make it, and don't worry where it goes since the main namespace is flat. I've been thinking about writing an extension that superimposes a hierarchy on existing namespaces, and what the implications would be for the rest of the MediaWiki UI. It's an interesting problem. Anyone tried it? 3. Tools for organizing large groups of articles. Categories and namespaces are great, and the DPL extension helps a lot. But when (say) the Legal department creates 700 articles that all begin with the words Legal department (e.g., Legal department policies, Legal department meeting 2012-07-01, Legal department lunch, etc.), suddenly the AJAX auto-suggest search box becomes a real pain for finding Legal department articles. This is SO COMMON in a corporate environment with many departments, as people try to game the search box by titling all their articles with Legal department... until suddenly it doesn't scale and they're stuck. I'd like to see tools for easily retitling and recategorizing large numbers of articles at once. Recategorising is very simple with global search-and-replace. Our implementation is called BatchEditor https://github.com/mediawiki4intranet/BatchEditor 4. Integration with popular corporate tools like MS Office, MS Exchange, etc. We've spent thousands of hours doing this: for example, an extension that embeds an Excel spreadsheet in a wiki page (read-only, using a $10,000 commercial Excel-to-HTML translator as a back-end), and we're looking at embedding Exchange calendars in wiki pages next. O_O $1 excel-to-html? O_OOO Why not just copy-paste into for example wikEd (google://wikEd)? :-))) Not that beautiful, but it works. 5. Corporate reorganizations and article titles. In any company, the names and relationships of departments change. What do you do when 10,000 wiki links refer to the old department name? Sure, you can move the article Finance department to Global Finance department and let redirects handle the rest: now your links work. But they still have the old department name, and global search-and-replace is truly scary when wikitext might get altered by accident. Also, there's the category called Finance department. You can't rename categories easily. I know you can do it with Pywikipedia, but it's slow and risky (e.g., Pywikipedia used to have a bug that killed noinclude tags around categories it changed). Categories should be fully first-class so renames are as simple as article title changes. Mass editing tool = BatchEditor, as I've already said. But I agree that Mediawiki needs better mass editing, page selection and page exchanging (import/export) tools. In our distribution (mediawiki4intranet) we partially solve it by implementing selection on Special:Export. BatchEditor uses this implementation when it's available. (you can see examples at http://wiki.4intra.net/Special:Export and http://wiki.4intra.net/Special:BatchEditor) (also we have an improved import/export functionality but unfortunately it's a code bomb and reworking to get it in trunk will take a lot of time...) But it's only a partial solution, because it has no standard interface. So we also have a variation of DPL, also we have SemanticMediaWiki. And all of them has partially the same - but not totally the same - functionality. And it would be good if there existed a single, standartized, optimised and cacheable method of page selection. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] URLs for autogenerated documentation
Hello, We have historically generated MediaWiki documentation on the Subversion server known as formey: https://svn.wikimedia.org/doc/ That the result of running doxygen once per day against the master branch of mediawiki/core.git. We would like to move the documentation to another host and I think it is a good time to change the URL as well to something a bit more meaningful than svn.mediawiki.org :-] We also have auto generated documentation for our puppet manifest at: http://doc.wikimedia.org/puppet/ Timo and I kind of disagree on the URL scheme to use to publish the documentation, so instead of starting a revert war in Gerrit, I thought it would be a good idea to ask some more people to participate in. For the context: We would like to have documentation generated for: - puppet - mediawiki branches and tags (PHP + JS + CSS) - mediawiki extensions (PHP + JS + CSS) The hosts doc.wikimedia.org and doc.mediawiki.org points to the same machine. I guess puppet could land at doc.wikimedia.org/puppet For MediaWiki we need the following parameters: - project (core / extension name) - version (tag / release branch / master) - type of documented source (php / js / css) What kind of magic ordering can we agree on? A) http://doc.wikimedia.org/mediawiki-core/branch|tag/php Would bring: doc.wikimedia.org/mediawiki-core/master/php doc.wikimedia.org/mediawiki-core/master/js doc.wikimedia.org/mediawiki-core/1.20.2/php doc.wikimedia.org/mediawiki-core/REL1_20/js doc.wikimedia.org/mediawiki-AbuseFilter/1.20.2/php B) doc.mediawiki.org/project/type/version/ Would bring: doc.mediawiki.org/core/php/master doc.mediawiki.org/core/js/master doc.mediawiki.org/core/php/1.20.2 doc.mediawiki.org/core/js/REL1_20 doc.mediawiki.org/AbuseFilter/php/REL1_20 Other thoughts? I would prefer having the MediaWiki doc hosted on the mediawiki.org domain. As for the ordering I guess we can bikeshed for a long time but most probably some ordering will seem natural for most people there :-] Thanks! -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki API at Codecademy?
On 02/08/2013 12:25 AM, Yury Katkov wrote: Is it possible to run other MediaWiki courses on codeacademy? The Extension Development and the Core Development for example? We can ask, but it is probably better do it after having started effectively with the API task. On Fri, Feb 8, 2013 at 3:20 AM, Yuri Astrakhan yuriastrak...@gmail.com wrote: I will be happy to part-take in this, as I do have some experience with the API :) Great! How do you feel about taking the lead? I can help making sure we are in sync with WMF in terms of authorization, trademarks, etc. Our contact in Codecademy told us that it is fine to start with a couple of very basic exercises to have the content published, and then we can add more content as we go receive feedback. They also sent us the documentation to get started. I can forward all this to you. On Thu, Feb 7, 2013 at 6:12 PM, Quim Gil q...@wikimedia.org wrote: Long story short: the MediaWiki API could be included at http://www.codecademy.com/**tracks/apishttp://www.codecademy.com/tracks/apis -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] URLs for autogenerated documentation
Whichever way we chose, could we have http redirects from the old svn.wikimedia.org? There's a lot of urls that link there. I prefer doc.mediawiki.org/project/version/master (aka doc.mediawiki.org/core/master/php ) as in my mind, the hierarchy makes more sense like that, as the type of code is something more fine-grained than what version, and also something that belongs to the version number in a sense. I also like keeping the names MediaWiki and Wikimedia separate. At the end of the day it doesn't really matter which way though. It would also be cool if puppet docs were on doc.wikimedia.org, but if you had doc.mediawiki.org in the url, things auto redirected (and vice veras: if you went to doc.wikimedia.org/core/master/php things redirected to doc.mediawiki.org/core/master/php ) Cheers, Bawolff On Fri, Feb 8, 2013 at 11:18 AM, Antoine Musso hashar+...@free.fr wrote: Hello, We have historically generated MediaWiki documentation on the Subversion server known as formey: https://svn.wikimedia.org/doc/ That the result of running doxygen once per day against the master branch of mediawiki/core.git. We would like to move the documentation to another host and I think it is a good time to change the URL as well to something a bit more meaningful than svn.mediawiki.org :-] We also have auto generated documentation for our puppet manifest at: http://doc.wikimedia.org/puppet/ Timo and I kind of disagree on the URL scheme to use to publish the documentation, so instead of starting a revert war in Gerrit, I thought it would be a good idea to ask some more people to participate in. For the context: We would like to have documentation generated for: - puppet - mediawiki branches and tags (PHP + JS + CSS) - mediawiki extensions (PHP + JS + CSS) The hosts doc.wikimedia.org and doc.mediawiki.org points to the same machine. I guess puppet could land at doc.wikimedia.org/puppet For MediaWiki we need the following parameters: - project (core / extension name) - version (tag / release branch / master) - type of documented source (php / js / css) What kind of magic ordering can we agree on? A) http://doc.wikimedia.org/mediawiki-core/branch|tag/php Would bring: doc.wikimedia.org/mediawiki-core/master/php doc.wikimedia.org/mediawiki-core/master/js doc.wikimedia.org/mediawiki-core/1.20.2/php doc.wikimedia.org/mediawiki-core/REL1_20/js doc.wikimedia.org/mediawiki-AbuseFilter/1.20.2/php B) doc.mediawiki.org/project/type/version/ Would bring: doc.mediawiki.org/core/php/master doc.mediawiki.org/core/js/master doc.mediawiki.org/core/php/1.20.2 doc.mediawiki.org/core/js/REL1_20 doc.mediawiki.org/AbuseFilter/php/REL1_20 Other thoughts? I would prefer having the MediaWiki doc hosted on the mediawiki.org domain. As for the ordering I guess we can bikeshed for a long time but most probably some ordering will seem natural for most people there :-] Thanks! -- 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] Jenkins tests reporting more errors
Hello, Due to some mistake I made during the Jenkins job overhaul last year, the PHPUnit jobs were no more using $wgDevelopmentWarnings. That is now fixed. I have also enabled $wgShowExceptionDetails per bug 43059. If that cause any serious trouble, shell users could change the setting file on gallium at: /var/lib/jenkins/jobs/_shared/ExtraSettings.php -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] NullLockManager and the math extension
Yes a654a6e79adc8f4730bb69f79e0b6a960d7d3cbe should be fixed. It should add the nullLockManager back. -- View this message in context: http://wikimedia.7.n6.nabble.com/NullLockManager-and-the-math-extension-tp4995536p4995767.html Sent from the Wikipedia Developers mailing list archive at Nabble.com. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)
vita...@yourcmc.ru writes:
In our organisation (CUSTIS, Russia) we easily solve it by creating one
primary wiki + separate ones for different departments.
In practice, we have found this doesn't work well for us (with thousands of
employees).
Each department winds up writing its own wiki page about the same topic (say,
Topic X), and they're all different.
Users don't know which one is the real or right article.
We find it better to have one central wiki with one definitive article per
topic.
No redundancy, no coupling, and no version skew between wikis.
Recategorising is very simple with global search-and-replace.
Our implementation is called BatchEditor
https://github.com/mediawiki4intranet/BatchEditor
Thanks, I'll check it out. Categorization can get very complicated on a
MediaWiki system though.
Consider this fairly simple template example:
{{#if:{{{department|}}} | [[Category:{{{department}}} projects]]}}
I would be amazed if any global search-and-replace could handle this!
O_O $1 excel-to-html? O_OOO
Why not just copy-paste into for example wikEd (google://wikEd)? :-))) Not
that beautiful, but it works.
Now, I will demonstrate what I mean by Corporate needs are different. :-)
With our extension, the Excel spreadsheet is rendered live in the wiki page.
So if somebody updates the spreadsheet (on a network drive), the wiki page is
automatically and instantly up to date! This is totally different from a
one-time
copy-and-paste, and much more maintainable. (And it's pretty fast too, with
AJAX and good caching.)
Even better, if your spreadsheet generates a graph or chart, the image gets
embedded
in the wiki page too, and is automatically kept up to date. And if your
spreadsheet
calls out to a database for its data, to generate the chart, then the wiki is
updated
when the database changes too! Suddenly, MediaWiki has all the charting
capability of
Excel + SQL. This is very powerful and definitely worth $10K for a highly
analytical
company like ours.
We've had this feature for about 2 months, and so far we have 350+ articles with
embedded spreadsheets, updated live.
also we have SemanticMediaWiki.
We started looking into Semantic MediaWiki - it has impressive features.
But we got scared off by stories that it slows down the
wiki too much. Maybe we should give it another look.
DanB
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] NullLockManager and the math extension
On 02/08/2013 12:55 PM, Aaron Schulz wrote: Yes a654a6e79adc8f4730bb69f79e0b6a960d7d3cbe should be fixed. It should add the nullLockManager back. Done, please review. https://gerrit.wikimedia.org/r/#/c/48144/ Thanks, Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)
On 02/08/2013 01:23 PM, Daniel Barrett wrote: also we have SemanticMediaWiki. We started looking into Semantic MediaWiki - it has impressive features. But we got scared off by stories that it slows down the wiki too much. Maybe we should give it another look. DanB A recent improvement in SMW is the new database structure for Semantic MediaWiki, SMWSQLStore3 -- this makes SMW faster and more efficient. http://semantic-mediawiki.org/wiki/Semantic_MediaWiki_1.8 It got released 2 December 2012. So yeah, check it out. (Shout-out to Nischay Nahata who led that work as his 2012 Summer of Code project.) -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)
On 2013-02-08 2:28 PM, Sumana Harihareswara suma...@wikimedia.org wrote: On 02/08/2013 01:23 PM, Daniel Barrett wrote: also we have SemanticMediaWiki. We started looking into Semantic MediaWiki - it has impressive features. But we got scared off by stories that it slows down the wiki too much. Maybe we should give it another look. DanB A recent improvement in SMW is the new database structure for Semantic MediaWiki, SMWSQLStore3 -- this makes SMW faster and more efficient. http://semantic-mediawiki.org/wiki/Semantic_MediaWiki_1.8 It got released 2 December 2012. So yeah, check it out. (Shout-out to Nischay Nahata who led that work as his 2012 Summer of Code project.) -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l I know nothing of smw, but surely using an rdf store backend ( which from what i understand has been supported for quite some time) would be more efficient than a relational db backend, no matter how optimized that backend might be. -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Developer Hub update
Hi, in the past we have been discussing the need to update http://www.mediawiki.org/wiki/Developer_hub Here is a basic proposal to get started. If we agree on the main idea the implementation will be easier. Perhaps we can do it edit by edit during some weeks, instead of an ambitious full rewrite: http://www.mediawiki.org/wiki/Talk:Developer_hub#Developer_Hub_update Once we are done with this we will decide whether something needs to be done about https://meta.wikimedia.org/wiki/Wikimedia_developer_hub or not. My personal opinion today is that it is simpler and better to have all software development info under mediawiki.org - and referenced through a one and only Developer Hub. But I'm open to be convinced with better arguments. :) PS: next week I'm on not-Xmas holidays, quite offline. Looking forward to seeing more thoughts and offers to help by Feb 18. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)
Hey, We started looking into Semantic MediaWiki - it has impressive features. But we got scared off by stories that it slows down the wiki too much. Maybe we should give it another look. You _can_ abuse SMW in a way that it will kill performance on your wiki. If you use it in a sane fashion, it does not greatly affect performance. Sure there is room for improvement in some places, though it is certainly nowhere near being unusable due to performance issues, as i clearly demonstrated by many people using it very effectively. So though such stories due have a kernel of truth, they tend to be propagated by people not really knowing what they are talking about and tend to portray things bleaker then they actually are. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Developer Hub update
Are you going to reference software that has nothing to do with mediawiki on mediawiki.org as well? if not, then keep the hub we have on meta... On Fri, Feb 8, 2013 at 7:54 PM, Quim Gil q...@wikimedia.org wrote: Hi, in the past we have been discussing the need to update http://www.mediawiki.org/wiki/**Developer_hubhttp://www.mediawiki.org/wiki/Developer_hub Here is a basic proposal to get started. If we agree on the main idea the implementation will be easier. Perhaps we can do it edit by edit during some weeks, instead of an ambitious full rewrite: http://www.mediawiki.org/wiki/**Talk:Developer_hub#Developer_**Hub_updatehttp://www.mediawiki.org/wiki/Talk:Developer_hub#Developer_Hub_update Once we are done with this we will decide whether something needs to be done about https://meta.wikimedia.org/**wiki/Wikimedia_developer_hubhttps://meta.wikimedia.org/wiki/Wikimedia_developer_hubor not. My personal opinion today is that it is simpler and better to have all software development info under mediawiki.org - and referenced through a one and only Developer Hub. But I'm open to be convinced with better arguments. :) PS: next week I'm on not-Xmas holidays, quite offline. Looking forward to seeing more thoughts and offers to help by Feb 18. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/**User:Qgilhttp://www.mediawiki.org/wiki/User:Qgil __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://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] MediaWiki API at Codecademy?
Do you want help? I don't know much about the API at the moment, but it is my Level-Up assignment this quarter. Documenting things is a good way to learn them. I have written a lot of courseware in the past. Luke Welling On Thu, Feb 7, 2013 at 6:20 PM, Yuri Astrakhan yuriastrak...@gmail.comwrote: I will be happy to part-take in this, as I do have some experience with the API :) I am heading the API v2 project, and this would be a natural extension of that. * RFC http://www.mediawiki.org/wiki/Requests_for_comment/API_Future * Action/Parameter Cleanup http://www.mediawiki.org/wiki/Requests_for_comment/API_Future/Naming_Cleanup On Thu, Feb 7, 2013 at 6:12 PM, Quim Gil q...@wikimedia.org wrote: Long story short: the MediaWiki API could be included at http://www.codecademy.com/**tracks/apis http://www.codecademy.com/tracks/apis if someone wants to do the work. Codecademy is happy to have us there. I think it is a good idea, in need of someone willing to drive this: - It is a good excuse to improve our API documentation at mediawiki.org. - Codecademy is a good place to reach to more developers. - Maybe it is a good chance for someone to take this as a paid job? The Wikimedia movement wants to spread the 1,3T of content we have, and get more free content from as many channels as possible. Our API plays a big role on this. Therefore, I *personally* believe that a project to update the API documentation at mediawiki.org and have corresponding exercises at Codecademy has a chance to receive a grant if the proposal and the candidate(s) are solid. Interested? Let me help you. -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/**User:Qgil http://www.mediawiki.org/wiki/User:Qgil __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-l 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] Corporate needs are different (RE: How can we help Corporations use MW?)
On 02/08/2013 10:23 AM, Daniel Barrett wrote: O_O $1 excel-to-html? O_OOO Why not just copy-paste into for example wikEd (google://wikEd)? :-))) Not that beautiful, but it works. Now, I will demonstrate what I mean by Corporate needs are different. :-) With our extension, the Excel spreadsheet is rendered live in the wiki page. So if somebody updates the spreadsheet (on a network drive), the wiki page is automatically and instantly up to date! This is totally different from a one-time copy-and-paste, and much more maintainable. (And it's pretty fast too, with AJAX and good caching.) Even better, if your spreadsheet generates a graph or chart, the image gets embedded in the wiki page too, and is automatically kept up to date. And if your spreadsheet calls out to a database for its data, to generate the chart, then the wiki is updated when the database changes too! Suddenly, MediaWiki has all the charting capability of Excel + SQL. This is very powerful and definitely worth $10K for a highly analytical company like ours. We've had this feature for about 2 months, and so far we have 350+ articles with embedded spreadsheets, updated live. As an aside, you could almost certainly do this cheaper with WorkingWiki. If you can write a make rule to retrieve the Excel file from the network drive and make it into html and image files (and maybe a little wikitext to format the page), you're done. LW ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)
In practice, we have found this doesn't work well for us (with
thousands of employees).
Yeah, our company doesn't have thousands of employees :-)
Each department winds up writing its own wiki page about the same
topic (say, Topic X), and they're all different.
So it means most of your departments work on something very similar?
Probably we don't have this problem because our departments and
projects strongly differ, so everyone just writes their specific
articles to their own wikis and general information to the primary
CustisWiki.
We have ~7 wikis for the whole company (~200 employees).
Users don't know which one is the real or right article.
We find it better to have one central wiki with one definitive
article per topic.
No redundancy, no coupling, and no version skew between wikis.
Just an idea - you can also setup the replication process between wikis
to ease fighting
Thanks, I'll check it out. Categorization can get very complicated on
a MediaWiki system though.
Consider this fairly simple template example:
{{#if:{{{department|}}} | [[Category:{{{department}}} projects]]}}
I would be amazed if any global search-and-replace could handle this!
Such examples of course are much harder, but if there is not much
chaos, you can handle it with regexps... Not a task for an average user,
but he can ask someone who knows regexps to do it :-)
With our extension, the Excel spreadsheet is rendered live in the
wiki page.
Ooh, I see, of course it's a big feature!
Also another question - didn't you try to use some automation using
excel itself to save xls as an html?
We started looking into Semantic MediaWiki - it has impressive
features.
But we got scared off by stories that it slows down the
wiki too much. Maybe we should give it another look.
As someone already said, it should not affect performance noticeably if
you don't abuse it.
And also, even if use abuse it - it has a very good feature: concept
caching, i.e. caching of semantic query results with correct
invalidation (as I understand it has some limitations though).
(http://semantic-mediawiki.org/wiki/Help:Concept_caching)
Overall, it's very nice to see that a big company like yours has
successful MediaWiki usage experience (I assume it's successful, yeah?
:))
Do you have any extensions or modifications that you would like to make
public free open source? Or maybe you even already did it with
something? :-)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki API at Codecademy?
On Fri, Feb 8, 2013 at 3:33 PM, Luke Welling WMF lwell...@wikimedia.orgwrote: Do you want help? I don't know much about the API at the moment, but it is my Level-Up assignment this quarter. Documenting things is a good way to learn them. I have written a lot of courseware in the past. Luke Welling Luke, that would be awesome! Even though we have tons of various documentation at https://www.mediawiki.org/wiki/Api , it can use a lot of cleanup and simplification, so as not to scare people away. A simple slow start tutorial might help. Also, as part of the docs cleanup, if you want to get your feet wet with the api code, you could help with simplifying the api.php help system - api.php without params shows this huge dump of all docs. This is not very helpful. Instead, it would be better to create a TOC with links - just module names and short description. Clicking on the module would bring up the detailed information about just one module (per module help has already been done). Let me know what you think. --Yurik ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki API at Codecademy?
Great! How do you feel about taking the lead? I can help making sure we are in sync with WMF in terms of authorization, trademarks, etc. Sure, although it seems everything legal takes forever with WMF... (its been over a week since I asked to get an NDA to see the api logs, no response :) ) Our contact in Codecademy told us that it is fine to start with a couple of very basic exercises to have the content published, and then we can add more content as we go receive feedback. They also sent us the documentation to get started. I can forward all this to you. Yes, please send. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki API at Codecademy?
On 02/08/2013 04:12 PM, Yuri Astrakhan wrote: On Fri, Feb 8, 2013 at 3:33 PM, Luke Welling WMF lwell...@wikimedia.orgwrote: Do you want help? I don't know much about the API at the moment, but it is my Level-Up assignment this quarter. Documenting things is a good way to learn them. I have written a lot of courseware in the past. Luke Welling Luke, that would be awesome! Even though we have tons of various documentation at https://www.mediawiki.org/wiki/Api , it can use a lot of cleanup and simplification, so as not to scare people away. A simple slow start tutorial might help. We have some material to start with: https://www.mediawiki.org/wiki/API/Tutorial Updating improving that would be great. And don't forget https://www.mediawiki.org/wiki/Special:ApiSandbox . Luke, thanks in advance for your help! -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Bootstrap based theme for Mediawiki
https://github.com/OSAS/strapping-mediawiki looks pretty awesome! (Example at http://www.ovirt.org/Home). This also makes bootstrap's classes / layouting helpers available to content inside the wiki itself, which is pretty cool. (thanks to Patrick Reilly on IRC) -- Yuvi Panda T http://yuvi.in/blog ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bootstrap based theme for Mediawiki
Le 08/02/13 22:37, Yuvi Panda a écrit : https://github.com/OSAS/strapping-mediawiki looks pretty awesome! (Example at http://www.ovirt.org/Home). This also makes bootstrap's classes / layouting helpers available to content inside the wiki itself, which is pretty cool. (thanks to Patrick Reilly on IRC) Oh man, We need that in core by default :-] Lot of people use bootstrap nowadays and I guess that will be a good way for them to easily build new skins using something they already know. Next project idea: get a twitter bootstrap customized to look like Vector so we can create tiny website that have the look'n feel of Vector without having to install all of MediaWiki. I could use that for a few static sites. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Documentation for Extensions
All, Do we have an existing method for extensions to autogenerate documentation (via a commit hook or something) and then to upload that to a documentation server? (Something akin to what we do with MediaWiki core.) We should have this for Doxygen, and make something similar for JSDuck -- the JS documentation system being pioneered by the VisualEditor team. -- ~Matt Walker ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki API at Codecademy?
On 02/08/2013 01:15 PM, Yuri Astrakhan wrote: Great! How do you feel about taking the lead? I can help making sure we are in sync with WMF in terms of authorization, trademarks, etc. Sure, fyi I have put Yuri in touch with our Codecademy contact. Anybody willing to get involved: please coordinate with Yuri. although it seems everything legal takes forever with WMF... (its been over a week since I asked to get an NDA to see the api logs, no response :) ) I'm optimistic. :) (but I will be away until Feb 19) Thank you Yuri and the rest of people showing interest in this initiative. Looking forward to the outcome! -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki API at Codecademy?
On Fri, Feb 8, 2013 at 4:58 PM, Antoine Musso hashar+...@free.fr wrote: Arent you contracting for the WMF? ... Nope, all my work so far has been volunteering. Sponsors are welcome :) On Fri, Feb 8, 2013 at 7:26 PM, Quim Gil q...@wikimedia.org wrote: fyi I have put Yuri in touch with our Codecademy contact. Anybody willing to get involved: please coordinate with Yuri. Thanks Quim! ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki API at Codecademy?
On 02/08/2013 04:32 PM, Yuri Astrakhan wrote: On Fri, Feb 8, 2013 at 4:58 PM, Antoine Musso hashar+...@free.fr wrote: Arent you contracting for the WMF? ... Nope, all my work so far has been volunteering. Sponsors are welcome :) https://meta.wikimedia.org/wiki/Grants:IEG Give it a try? Deadline: Feb 15! -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Technical design review of extension
Hello. I wrote an extension[1] for Wikinews and Wiktionary to replace the JS-driven custom tabs (Opinions in Wikinews, Citations/Template documentation in Wiktionary). According to the manual, as there were no pros heard from Design-l, now the extension must undergo a technical design review, before it is decided whether the extension is able to fly on production sites - deployment review. -- [1] https://www.mediawiki.org/wiki/Extension:NamespaceRelations -- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki API at Codecademy?
I would love to test the course once it comes out! I don't know how MediaWiki API works so I should be able to give feedback as a newbie. On Fri, Feb 8, 2013 at 4:35 PM, Quim Gil q...@wikimedia.org wrote: On 02/08/2013 04:32 PM, Yuri Astrakhan wrote: On Fri, Feb 8, 2013 at 4:58 PM, Antoine Musso hashar+...@free.fr wrote: Arent you contracting for the WMF? ... Nope, all my work so far has been volunteering. Sponsors are welcome :) https://meta.wikimedia.org/wiki/Grants:IEG Give it a try? Deadline: Feb 15! -- Quim Gil Technical Contributor Coordinator @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil ___ 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] Technical design review of extension
On 02/08/2013 08:35 PM, Paul Selitskas wrote: According to the manual, as there were no pros heard from Design-l, now the extension must undergo a technical design review, before it is decided whether the extension is able to fly on production sites - deployment review. Out of curiosity, where is this in the manual? Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Technical design review of extension
On Sat, Feb 9, 2013 at 4:56 AM, Matthew Flaschen mflasc...@wikimedia.orgwrote: On 02/08/2013 08:35 PM, Paul Selitskas wrote: According to the manual, as there were no pros heard from Design-l, now the extension must undergo a technical design review, before it is decided whether the extension is able to fly on production sites - deployment review. Out of curiosity, where is this in the manual? Matt Flaschen https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment? -- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Technical design review of extension
I suppose that means there should be a review to see if the extension design is OK to be deployed live. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Fri, Feb 8, 2013 at 9:07 PM, Paul Selitskas p.selits...@gmail.comwrote: On Sat, Feb 9, 2013 at 4:56 AM, Matthew Flaschen mflasc...@wikimedia.org wrote: On 02/08/2013 08:35 PM, Paul Selitskas wrote: According to the manual, as there were no pros heard from Design-l, now the extension must undergo a technical design review, before it is decided whether the extension is able to fly on production sites - deployment review. Out of curiosity, where is this in the manual? Matt Flaschen https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment? -- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects ___ 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] Technical design review of extension
Well, those tabs are already used in Wikinews and Wiktionary, so I personally find no reason for design review. On Sat, Feb 9, 2013 at 5:14 AM, Tyler Romeo tylerro...@gmail.com wrote: I suppose that means there should be a review to see if the extension design is OK to be deployed live. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Fri, Feb 8, 2013 at 9:07 PM, Paul Selitskas p.selits...@gmail.com wrote: On Sat, Feb 9, 2013 at 4:56 AM, Matthew Flaschen mflasc...@wikimedia.org wrote: On 02/08/2013 08:35 PM, Paul Selitskas wrote: According to the manual, as there were no pros heard from Design-l, now the extension must undergo a technical design review, before it is decided whether the extension is able to fly on production sites - deployment review. Out of curiosity, where is this in the manual? Matt Flaschen https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment? -- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects ___ 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 P.S. bikeshedding, guys... bikeshedding... -- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Technical design review of extension
To be honest, I doubt that many extensions go through a ui review prior to their main review. Given that the ui components have already existed, I would reccomend you just skip to the next step of that guide If you can't find anyone. Trust me as a volunteer contributed extension it will probably get the ninth degree before it gets deployed anyhow -bawolff On 2013-02-08 10:24 PM, Paul Selitskas p.selits...@gmail.com wrote: Well, those tabs are already used in Wikinews and Wiktionary, so I personally find no reason for design review. On Sat, Feb 9, 2013 at 5:14 AM, Tyler Romeo tylerro...@gmail.com wrote: I suppose that means there should be a review to see if the extension design is OK to be deployed live. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Fri, Feb 8, 2013 at 9:07 PM, Paul Selitskas p.selits...@gmail.com wrote: On Sat, Feb 9, 2013 at 4:56 AM, Matthew Flaschen mflasc...@wikimedia.org wrote: On 02/08/2013 08:35 PM, Paul Selitskas wrote: According to the manual, as there were no pros heard from Design-l, now the extension must undergo a technical design review, before it is decided whether the extension is able to fly on production sites - deployment review. Out of curiosity, where is this in the manual? Matt Flaschen https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment ? -- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects ___ 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 P.S. bikeshedding, guys... bikeshedding... -- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects ___ 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] Technical design review of extension
I agree, I'm just saying I think the guide is implying that the extension should be reviewed for security and whatnot before being deployed. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Fri, Feb 8, 2013 at 9:33 PM, Brian Wolff bawo...@gmail.com wrote: To be honest, I doubt that many extensions go through a ui review prior to their main review. Given that the ui components have already existed, I would reccomend you just skip to the next step of that guide If you can't find anyone. Trust me as a volunteer contributed extension it will probably get the ninth degree before it gets deployed anyhow -bawolff On 2013-02-08 10:24 PM, Paul Selitskas p.selits...@gmail.com wrote: Well, those tabs are already used in Wikinews and Wiktionary, so I personally find no reason for design review. On Sat, Feb 9, 2013 at 5:14 AM, Tyler Romeo tylerro...@gmail.com wrote: I suppose that means there should be a review to see if the extension design is OK to be deployed live. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Fri, Feb 8, 2013 at 9:07 PM, Paul Selitskas p.selits...@gmail.com wrote: On Sat, Feb 9, 2013 at 4:56 AM, Matthew Flaschen mflasc...@wikimedia.org wrote: On 02/08/2013 08:35 PM, Paul Selitskas wrote: According to the manual, as there were no pros heard from Design-l, now the extension must undergo a technical design review, before it is decided whether the extension is able to fly on production sites - deployment review. Out of curiosity, where is this in the manual? Matt Flaschen https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment ? -- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects ___ 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 P.S. bikeshedding, guys... bikeshedding... -- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects ___ 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] URLs for autogenerated documentation
On Feb 8, 2013, at 7:18 AM, Antoine Musso hashar+...@free.fr wrote: A) http://doc.wikimedia.org/mediawiki-core/branch|tag/php Would bring: doc.wikimedia.org/mediawiki-core/master/php doc.wikimedia.org/mediawiki-core/master/js doc.wikimedia.org/mediawiki-core/1.20.2/php doc.wikimedia.org/mediawiki-core/REL1_20/js doc.wikimedia.org/mediawiki-AbuseFilter/1.20.2/php B) doc.mediawiki.org/project/type/version/ Would bring: doc.mediawiki.org/core/php/master doc.mediawiki.org/core/js/master doc.mediawiki.org/core/php/1.20.2 doc.mediawiki.org/core/js/REL1_20 doc.mediawiki.org/AbuseFilter/php/REL1_20 I would prefer having the MediaWiki doc hosted on the mediawiki.org domain. As for the ordering I guess we can bikeshed for a long time but most probably some ordering will seem natural for most people there :-] Thanks! Presenting them as A and B seems flawed as they are separate things: Let's decouple them into a matrix of more tangible decisions: A) Do we want to maintain two domain names for our documentation? No, * We already have doc.wikimedia.org, doc.mediawiki.org would be a new one * If we maintain separate domain names, when is something mediawiki and when is it wikimedia? For example, documentation for jQuery plugins, VisualEditor etc are stand alone, most certainly not MediaWiki specific. There is no reason to force ourselves into this ambiguity. One domain is all we need. With some redirects perhaps. B) Hierarchy of directories project, branch and category of code (usually a programming language). 6 possible combinations of these 3. *The one I've proposed before and rationalised in the comment thread is project branch code-category. * This because not all projects have the same code categories. A tree is usually structured towards more specificity down the tree. * With the separator of time as high up as possible so that you don't duplicate versions in multiple locations. * Easier to maintain if we rename the code categories later on. * Easier to generate to have everything go in 1 target directory and not separate directories in different locations. I appreciate you putting thought into these minor details, but I think this discussion is pointless because you're not providing any rational input yourself (all I see it I prefer which is undeniably a useless argument to defend against). I can talk for hours, but it help get the documentation deployed if you don't communicate. The thread can become slightly more useful if you had actually provided some arguments of your own. I've explained the reasons for my version, then you reverted it with no explanation, linking[1] only to this post on wikitech-l, where you merely present A and B once again with no explanation as to why you disagree in the first place. I'd love to discuss the advantage of your version or disadvantage of mine, preferably as a simple response to my question in Gerrit, but here is fine too. Let's keep in mind the bigger picture and do what's best for the users. On Feb 8, 2013, at 7:41 AM, bawolff bawolff...@gmail.com wrote: Whichever way we chose, could we have http redirects from the old svn.wikimedia.org? There's a lot of urls that link there. Unrelated. Yes, of course. When we move it, the old location will become a redirect. I prefer doc.mediawiki.org/project/version/master (aka doc.mediawiki.org/core/master/php ) as in my mind, the hierarchy makes more sense like that, as the type of code is something more fine-grained than what version, and also something that belongs to the version number in a sense. I also like keeping the names MediaWiki and Wikimedia separate. At the end of the day it doesn't really matter which way though. I agree. It would also be cool if puppet docs were on doc.wikimedia.org, but if you had doc.mediawiki.org in the url, things auto redirected (and vice veras: if you went to doc.wikimedia.org/core/master/php things redirected to doc.mediawiki.org/core/master/php ) I'm not sure we should be maintaining two domains. We can have doc.mediawiki.org redirect to doc.wikimedia.org/mediawiki-core, but to maintain both would be confusing, decentralising and depending on the implementation, it would encourage using multiple urls for the same thing. Might as well stick with one canonical url. Best, -- Krinkle [1] https://gerrit.wikimedia.org/r/39212 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] URLs for autogenerated documentation
Before we get too entrenched in the address layout, can we have a better url than doc, it doesn't really scream out what it does, Something along the lines documentation or development (probably not so much) suggest better about what the address will contain. On Sat, Feb 9, 2013 at 1:37 PM, Krinkle krinklem...@gmail.com wrote: On Feb 8, 2013, at 7:18 AM, Antoine Musso hashar+...@free.fr wrote: A) http://doc.wikimedia.org/mediawiki-core/branch|tag/php Would bring: doc.wikimedia.org/mediawiki-core/master/php doc.wikimedia.org/mediawiki-core/master/js doc.wikimedia.org/mediawiki-core/1.20.2/php doc.wikimedia.org/mediawiki-core/REL1_20/js doc.wikimedia.org/mediawiki-AbuseFilter/1.20.2/php B) doc.mediawiki.org/project/type/version/ Would bring: doc.mediawiki.org/core/php/master doc.mediawiki.org/core/js/master doc.mediawiki.org/core/php/1.20.2 doc.mediawiki.org/core/js/REL1_20 doc.mediawiki.org/AbuseFilter/php/REL1_20 I would prefer having the MediaWiki doc hosted on the mediawiki.org domain. As for the ordering I guess we can bikeshed for a long time but most probably some ordering will seem natural for most people there :-] Thanks! Presenting them as A and B seems flawed as they are separate things: Let's decouple them into a matrix of more tangible decisions: A) Do we want to maintain two domain names for our documentation? No, * We already have doc.wikimedia.org, doc.mediawiki.org would be a new one * If we maintain separate domain names, when is something mediawiki and when is it wikimedia? For example, documentation for jQuery plugins, VisualEditor etc are stand alone, most certainly not MediaWiki specific. There is no reason to force ourselves into this ambiguity. One domain is all we need. With some redirects perhaps. B) Hierarchy of directories project, branch and category of code (usually a programming language). 6 possible combinations of these 3. *The one I've proposed before and rationalised in the comment thread is project branch code-category. * This because not all projects have the same code categories. A tree is usually structured towards more specificity down the tree. * With the separator of time as high up as possible so that you don't duplicate versions in multiple locations. * Easier to maintain if we rename the code categories later on. * Easier to generate to have everything go in 1 target directory and not separate directories in different locations. I appreciate you putting thought into these minor details, but I think this discussion is pointless because you're not providing any rational input yourself (all I see it I prefer which is undeniably a useless argument to defend against). I can talk for hours, but it help get the documentation deployed if you don't communicate. The thread can become slightly more useful if you had actually provided some arguments of your own. I've explained the reasons for my version, then you reverted it with no explanation, linking[1] only to this post on wikitech-l, where you merely present A and B once again with no explanation as to why you disagree in the first place. I'd love to discuss the advantage of your version or disadvantage of mine, preferably as a simple response to my question in Gerrit, but here is fine too. Let's keep in mind the bigger picture and do what's best for the users. On Feb 8, 2013, at 7:41 AM, bawolff bawolff...@gmail.com wrote: Whichever way we chose, could we have http redirects from the old svn.wikimedia.org? There's a lot of urls that link there. Unrelated. Yes, of course. When we move it, the old location will become a redirect. I prefer doc.mediawiki.org/project/version/master (aka doc.mediawiki.org/core/master/php ) as in my mind, the hierarchy makes more sense like that, as the type of code is something more fine-grained than what version, and also something that belongs to the version number in a sense. I also like keeping the names MediaWiki and Wikimedia separate. At the end of the day it doesn't really matter which way though. I agree. It would also be cool if puppet docs were on doc.wikimedia.org, but if you had doc.mediawiki.org in the url, things auto redirected (and vice veras: if you went to doc.wikimedia.org/core/master/php things redirected to doc.mediawiki.org/core/master/php ) I'm not sure we should be maintaining two domains. We can have doc.mediawiki.org redirect to doc.wikimedia.org/mediawiki-core, but to maintain both would be confusing, decentralising and depending on the implementation, it would encourage using multiple urls for the same thing. Might as well stick with one canonical url. Best, -- Krinkle [1] https://gerrit.wikimedia.org/r/39212 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki API at Codecademy?
On Feb 8, 2013 7:42 PM, Teresa Cho tcho...@gmail.com wrote: I would love to test the course once it comes out! I don't know how MediaWiki API works so I should be able to give feedback as a newbie. +1 I would love to test it out as well. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki API at Codecademy?
Hi All I have worked lot on MediaWiki API. If someone needs help then I can definitely help. I have one suggestion that we have to improve some portion of documentation so that new bee can easily understand. Thanks Harsh --- Harsh Kothari Research Fellow, Physical Research Laboratory(PRL). Ahmedabad. On 09-Feb-2013, at 9:56 AM, Valerie Juarez wrote: On Feb 8, 2013 7:42 PM, Teresa Cho tcho...@gmail.com wrote: I would love to test the course once it comes out! I don't know how MediaWiki API works so I should be able to give feedback as a newbie. +1 I would love to test it out as well. ___ 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] Technical design review of extension
Yes, extensions need to be reviewed (esp. In terms of security and performance) before anyone will deploy them. -bawolff On 2013-02-08 10:35 PM, Tyler Romeo tylerro...@gmail.com wrote: I agree, I'm just saying I think the guide is implying that the extension should be reviewed for security and whatnot before being deployed. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Fri, Feb 8, 2013 at 9:33 PM, Brian Wolff bawo...@gmail.com wrote: To be honest, I doubt that many extensions go through a ui review prior to their main review. Given that the ui components have already existed, I would reccomend you just skip to the next step of that guide If you can't find anyone. Trust me as a volunteer contributed extension it will probably get the ninth degree before it gets deployed anyhow -bawolff On 2013-02-08 10:24 PM, Paul Selitskas p.selits...@gmail.com wrote: Well, those tabs are already used in Wikinews and Wiktionary, so I personally find no reason for design review. On Sat, Feb 9, 2013 at 5:14 AM, Tyler Romeo tylerro...@gmail.com wrote: I suppose that means there should be a review to see if the extension design is OK to be deployed live. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Fri, Feb 8, 2013 at 9:07 PM, Paul Selitskas p.selits...@gmail.com wrote: On Sat, Feb 9, 2013 at 4:56 AM, Matthew Flaschen mflasc...@wikimedia.org wrote: On 02/08/2013 08:35 PM, Paul Selitskas wrote: According to the manual, as there were no pros heard from Design-l, now the extension must undergo a technical design review, before it is decided whether the extension is able to fly on production sites - deployment review. Out of curiosity, where is this in the manual? Matt Flaschen https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment ? -- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects ___ 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 P.S. bikeshedding, guys... bikeshedding... -- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects ___ 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
