Re: [Wikitech-l] Limiting storage/generation of thumbnails without loss of functionality
On 24/01/13 13:54, Matthew Flaschen wrote: On 01/23/2013 10:07 PM, Georgiy Tugai wrote: As the linked thread mentioned, MediaWiki is used on many deployments outside of Wikimedia. For example, I'm running three instances on a server with 10 GB of disk space. Therefore, this should be an option in LocalSettings.php rather than a global change; that way, the installations which are CPU-constrained rather than disk-constrained can use other solutions, from user education to Squid. Yeah, I think it should probably an option (we could debate the default later). Besides the obvious bandwidth issue, some browsers may do worse scaling then MediaWiki's library (imagemagick I believe). Of course, others might be better. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Maybe put a CSS box over/next to the image, in preview mode and possibly in normal viewing mode as well, suggesting that the user specifies a standard size for higher quality etc..? Also, a lightbox feature may help - expand the image to the full size (as sent by the server) on click, then link to the file page upon a second click (hide the lightbox upon a click outside of the image borders). I am unsure how difficult this feature would be to add -- I have not dug around in MediaWiki's code before. Can someone point me in the right direction? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A testing bug management wheel
On Wed, Jan 23, 2013 at 10:56 PM, Quim Gil q...@wikimedia.org wrote: https://www.mediawiki.org/**wiki/QA/Weekly_goalshttps://www.mediawiki.org/wiki/QA/Weekly_goals The first two events have the same date, Jan 28. Is that on purpose? Željko ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Why are we still using captchas on WMF sites?
On Tue, Jan 22, 2013 at 5:18 PM, Luke Welling WMF lwell...@wikimedia.org wrote: That was not the end of the problem I was referring to. We know our specific captcha is broken at turning away machines. As far as I am aware we do not know how many humans are being turned away by the difficulty of it. It's a safe bet that it is non-zero given the manual account requests we get, but given that we have people to do those kinds of experiments it would make sense to get a number from them before making any drastic decisions based on a reasonable gut feeling. I don't think anybody claims to have a perfect solution to the spam vs usability balancing act, so it's possible we'll try (and measure) a few approaches. I think the impact on humans will be mensurable once actions which trigger a CAPTCHA are logged: https://bugzilla.wikimedia.org/show_bug.cgi?id=41522 https://gerrit.wikimedia.org/r/#/c/40553/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] An actual bikeshed
Excuse me, but your proposed solution is wholly inadequate. For example, a few people might prefer a green bikeshed, more people might prefer blue, yet a small majority might prefer awful grey. The greens would of course prefer blue to grey, yet this would not be reflected in the voting outcome. Obviously, if this is ever to be implemented, we need a better way of counting the votes, such as instant-runoff voting. This doesn't make any sense. I'm not sure what you mean by small majority, but I'm going to assume that it's a majority nonetheless. If a majority prefers gray, even if everybody who voted green and blue banded together and voted for one color, they'd still have less votes than those who voted from gray. Hence the reason for using a majority vote. On that note, I'd be perfectly fine doing a quick majority vote on small bikeshed items just so we can get them over with and so people can stop -1'ing my patchsets because of them. This especially applies in cases where there are only two choices, e.g., if( v. if (. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Thu, Jan 24, 2013 at 2:30 AM, Nikola Smolenski smole...@eunet.rs wrote: On 23/01/13 20:38, Jon Robson wrote: Suggested solution: Maybe some kind of voting system might be of use to force some kind of consensus rather than leaving problems unsolved. I'm fed up of receiving emails about the same problem I discussed weeks before that never got solved. It makes my mailbox ill. I mean if the question is really what colour is the bikeshed it would be good for people to propose colours, people to vote on preferred colours and at the end of say a week the majority colour wins and gets implemented (or in cases where there is no majority we discuss the front runners and other possible solutions). Excuse me, but your proposed solution is wholly inadequate. For example, a few people might prefer a green bikeshed, more people might prefer blue, yet a small majority might prefer awful grey. The greens would of course prefer blue to grey, yet this would not be reflected in the voting outcome. Obviously, if this is ever to be implemented, we need a better way of counting the votes, such as instant-runoff voting. __**_ 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] An actual bikeshed
On Thu, Jan 24, 2013 at 10:19 AM, Tyler Romeo tylerro...@gmail.com wrote: Excuse me, but your proposed solution is wholly inadequate. For example, a few people might prefer a green bikeshed, more people might prefer blue, yet a small majority might prefer awful grey. The greens would of course prefer blue to grey, yet this would not be reflected in the voting outcome. Obviously, if this is ever to be implemented, we need a better way of counting the votes, such as instant-runoff voting. This doesn't make any sense. I'm not sure what you mean by small majority, but I'm going to assume that it's a majority nonetheless. I expect Nikola meant a relative majority (sometimes called a plurality) rather than an absolute, overall, or simple majority. This reminds me of the differences in US versus UK meaning for the verb to table. Or for the noun fanny. But we should use the Schulze method, not IRV. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] An actual bikeshed
On Jan 24, 2013 11:06 AM, Brad Jorsch bjor...@wikimedia.org wrote: But we should use the Schulze method, not IRV. In either case we should use selectricity. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] An actual bikeshed
On 23 January 2013 19:11, Chad innocentkil...@gmail.com wrote: Hi, There's been a lot of bikeshedding topics recently. On things ranging from spaces, to typos, to naming things. I was kind of tired of these mundane threads, so I decided to start one on something productive. What color should the bikeshed be? I vote blue. -Chad The list is more professional than ever. Looking back to the beggining of the history of the list is amazing how the wikitech has evolved. Very impresive. And that make me very happy. But this also make the list very tecnical. Sometimes I don't even understand what you guys are talking about, gerrit this, gerrit that, ..but I always feel like I am learning something every time I read a email here. *insert here a funny and witty joke about bikesheeds* -- -- ℱin del ℳensaje. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A testing bug management wheel
On 01/24/2013 02:10 AM, Željko Filipin wrote: On Wed, Jan 23, 2013 at 10:56 PM, Quim Gil q...@wikimedia.org wrote: https://www.mediawiki.org/**wiki/QA/Weekly_goalshttps://www.mediawiki.org/wiki/QA/Weekly_goals The first two events have the same date, Jan 28. Is that on purpose? No, but it's real. :) Let's take it as an initial wheelslip, fixed in the following weeks. :) The Mobile team is committing to the next Features testing week starting on Feb 25. Yay! Who else? Note that these QA weeks are open to ALL projects, not just Wikimedia Foundation teams. -- 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] Bugzilla and Automated tests backlog [was: Re: A testing bug management wheel]
On Thu, 2013-01-17 at 10:54 -0700, Chris McMahon wrote: I'm glad you mentioned this, it's something I'd like to bring up with Andre and Valerie. Note that much of the backlog for automated tests is the result of fixed BZ tickets http://www.mediawiki.org/wiki/Qa/test_backlog. Fixed bugs are great candidates for regression tests because a) what broke once is more likely to break again and b) an issue fixed may indicate more issues in nearby areas of the feature. Our UploadWizard test is a great example of a single test catching multiple issues in the same area over time. How do items currently end up on http://www.mediawiki.org/wiki/QA/Browser_testing/Test_backlog#Backlog ? Who thinks This is a candidate for an automated browser test, I should list it on the wikipage? QA reading the commit backlogs? Developers who fixed the issue and know about automated tests? Knowing the target audience might help finding the best workflow. So a mechanism by which fixed browser bugs become entered in the automated browser test backlog would be a fine thing. 1) Bugzilla already has a number of keywords such as * need-integration-test (Selenium test should be written for this.) * need-parsertest (bug needs a parsertest written for it.) * need-unittest (bug needs a test written for it.) We could introduce yet another keyword in Bugzilla to mark reports that could benefit from a regression-test. Then somebody (who?) could set the keyword and QA could query that bug list [1↓]. However, I don't know how actively these three keywords are used. Even more I wonder how many different workflow interpretations exist. Developer closes bug report as RESOLVED FIXED and adds keyword followed by some volunteer finds out how to search for *closed* tickets with these keywords, writes a test, and removes the keyword again? I'd love to find out to better understand if it's useful. 2) Another option inside of Bugzilla would be creating a dedicated Automated browser tests to be created component and filing (or cloning) a ticket under it everytime when a bug got FIXED. Again, who would be expected to create that ticket - QA going through recently fixed reports? Developers who fixed it? Triagers? I'm not totally convinced by these two yet, as both need buy-in (developers and reporters need to know and remember that QA works on automated browser tests, and should mark issues accordingly), but nothing better came to my mind in the last days. :-/ andre [1↑] or display the buglist embedded in a wiki page, by using something like http://www.mediawiki.org/wiki/Extension:Bugzilla_Reports -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A testing bug management wheel
We in QA discussed some possibilities for the browser test automation community activities, and we suggest that the first couple of community events be educational. In particular, we think it would be beneficial to start with some introductory topics to be presented as a hangout+IRC chat+documentation on the wiki. Our suggestions for the first two events: * how anyone can write an Test Scenario to be automated (and why this is important!) * how to read, understand and analyze results in the Jenkins system we have for browser automation -Chris On Wed, Jan 23, 2013 at 2:56 PM, Quim Gil q...@wikimedia.org wrote: This proposal got a basic agreement and is being implemented at https://www.mediawiki.org/**wiki/QA/Weekly_goalshttps://www.mediawiki.org/wiki/QA/Weekly_goals A rough start is expected in the first iteration of the four areas but we hope to have improvements every week. Get involved! Development teams: your proposals for testing bug management weekly goals are welcome. On 01/16/2013 02:25 PM, Quim Gil wrote: There are ongoing separate discussions about the best way to organize testing sprints and bug days. The more we talk and the more we delay the beginning of continuous activities the more I believe the solution is common for both: Smaller activities and more frequent. Each one of them less ambitious but more precise. Not requiring by default the involvement of developer teams. Especially not requiring the involvement of WMF dev teams. Of course we want to work together with development teams! But just not wait for them. They tend to be busy, willing and at the same time unwilling (a problem we need to solve but not necessarily before starting a routine of testing and bug management activities. If a dev team (WMF or not) wants to have dedicated testing and bug management activities we will give them the top priority. Imagine this wheel: Week 1: manual testing (Chris) Week 2: fresh bugs (Andre) Week 3: browser testing (Željko) Week 4: rotten bugs (Valerie) All the better if there is certain correlation between testing and bugs activities, but no problem if there is none. From the point of view of the week coordinators this is how a cycle would look like: Week 1: decide the goal of the next activity. Weeks 2-3: preparing documentation, recruiting participants. Week 4: DIY activities start. Support via IRC mailing list. Group sprint on Wed/Thu DIY activities continue. Week 4+1: Evaluation of results. Goal of the next activity During the group sprints there would be secondary DIY tasks for those happy to participate but not fond of the main goal of the week. If one group needs more than one activity per month they can start overflowing the following week, resulting in simultaneous testing bugs activities. Compared to the current situation, this wheel looks powerful and at the same time relatively easy to set up. There will plenty of things to improve and fine tune, but probably none of them will require to stop the wheel. What do you think? -- 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] Portuguese Wikipedia village pump and crowdsourcing ideas
Hi all, I would like to ask some help to do one thing and brainstorm a little about some tools for crowdsourcing wikimedians ideas. 1) My first question is if someone could help me to create a RSS feed of threads of the Portuguese Wikipedia village pump (= /esplanada/). The feed would contain the title and link to the thread, the thread body and the author. Our /esplanada/ has one subpage per thread, which makes easy to watch what I want. See bellow http://pt.wikipedia.org/wiki/Wikip%C3%A9dia:Esplanada/geral But I miss sometimes topics being created only using my watchlist and a RSS feed would facilitate my life to read and follow all threads I am interested in using an aggregator or even making the feed send each thread by e-mail. Once I created a RSS feed using a Web service that found HTML patterns, so I think that could be done in a similar way (I cannot remember the service name now). Would be easy to create a Python script for that? (maybe with beautifulSoup?) Any other method suggestion? 2) Not only for reading purposes, I also would like to add this threads and possible ideas inside the discussion on systems like All our ideas http://www.allourideas.org/, OSQA http://osqa.net (see this example http://ideas.okfn.org/) or possible other softwares to evaluate the best ideas and threads using a crowdsourcing model - other ideas for tools welcome. Any help for 1 and any idea for 2 is welcome. Thanks, Tom -- Everton Zanella Alvarenga (also Tom) A life spent making mistakes is not only more honorable, but more useful than a life spent doing nothing. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Marking all of SVN as read-only
Hi all, I've been taking a look at the SVN history[0], and it doesn't look like anything is actively using SVN anymore. Looking at the logs, it doesn't look like much of anything has been committed in the last few months that hasn't since been moved to Git (in Gerrit or elsewhere). This being said: I'm going to mark all of the MediaWiki SVN repository as read-only tomorrow, Jan. 25th. Note this won't make anything in SVN go away, as we're still committed to leaving the SVN repositories available in a read-only manner. This also doesn't prevent us from converting extensions or other code to Git if someone decides to resurrect a project. Finally, this does not affect the Wikimedia repository, which still has a couple of active projects. -Chad [0] http://www.mediawiki.org/wiki/Special:Code/MediaWiki ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia Hackathon 2013 brainstorming
On 01/23/2013 10:46 PM, Gregory Varnum wrote: Greetings, Wikimania is six months away - and in terms of planning - that means it is right around the corner. As such, folks involved with programme and Hackathon organizing are very interested in any ideas that WM developers may have for this year's Hackathon. Please contribute them on-wiki - https://wikimania2013.wikimedia.org/wiki/Hackathon/Brainstorming Or if that is just too much wiki for today - feel free to email me and I'll make sure it gets posted. :) Thank you! -greg aka varnent Wikimania 2013 Programme Committee / geek helping with Hackathon Thank you! Before jumping to the Wikimania website, could you share your own thoughts and lessons learned from last Wikimania Hackathon? Feedback from any other participants is welcome as well. URLs with feedback are welcome too! There are the valuable http://lists.wikimedia.org/pipermail/wikitech-l/2012-July/062065.html http://lists.wikimedia.org/pipermail/wikitech-l/2012-July/062066.html As an outsider (not for long) the main concerns I see are: * No local tech contact specifically interested in the Hackathon found so far. Who is the varnent of Hong Kong 2013? And what is your role this year, by the way? Good to see you involved! * Personally no idea about the Hong Kong Wikimedia tech / MediaWiki community. * Far from US Europe, unclear how many usual suspects of this community will make it. * Unclear (to me, still) actual purpose, goal and fit with the rest of Wikimania. Before having this framework more clear, it is difficult to jump to specific ideas at the Wikimania website, other than wlan should work well, we need plugs in each table and so on. :) -- 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] Bugzilla and Automated tests backlog [was: Re: A testing bug management wheel]
[CC'ing wikitech-l@ again] On Thu, 2013-01-24 at 10:50 -0700, Chris McMahon wrote: On Thu, Jan 24, 2013 at 10:30 AM, Andre Klapper aklap...@wikimedia.org wrote: 1) Bugzilla already has a number of keywords such as * need-integration-test (Selenium test should be written for this.) I didn't know this existed, and a quick look makes me think it will take some gardening to cull actual potential browser tests, but it might be a worthwhile exercise. I'm not totally convinced by these two yet, as both need buy-in (developers and reporters need to know and remember that QA works on automated browser tests, and should mark issues accordingly), but nothing better came to my mind in the last days. :-/ Thanks. I'm not certain either, and I'm still thinking... Right after clicking the Send button a 3rd option came to my mind, remembering all the Mozilla bugmail that I receive. Mozilla uses a Bugzilla flag called in-litmus. It's explained here: https://quality.mozilla.org/docs/qmo-community/lesson-plans/investigating-in-litmus-bugs/ In short, * in-litmus? indicates the bug is nominated for a testcase * in-litmus+ indicates the bug has a testcase * in-litmus- indicates the bug does not need a testcase andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Caching of images in varnish
On Sat, 2013-01-19 at 11:18 -0400, Bawolff Bawolff wrote: There are reports everywhere of uploading new versions of images failing (upload works but new version does not show up). Last time this happened all that needed to be done was fot varnishhtcpd to be restarted on the image cache servers. [1] could someone with the ability to check, check if that needs to be done again? Imho this type of issue is a rather serious one which causes lots of frustration and confusion. [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=41130 There are several cases of missing thumbnails on Commons, with Error generating thumbnail: The source file for the specified thumbnail does not exist. Images uploaded to Commons on Tuesday between 19:14 (or earlier) to 19:17 (Datacenter migration ongoing) did not see any thumbnails generated. Scroll down to see missing thumbnails: https://commons.wikimedia.org/w/index.php?title=Special:ListFilesoffset=20130122191730limit=50user=Smallbot This was brought up in https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29oldid=534474300#Images_not_rendering Not sure if the datacenter move is just a coincidence or related for above issue. Other issues with similar outcome, but unsuspicious timing: https://commons.wikimedia.org/wiki/File:%E6%85%88%E6%BF%9F%E5%AE%AEwikipedia.jpg was uploaded January 23rd (yesterday) and a reupload worked. https://commons.wikimedia.org/wiki/File:Halfanim.jpg was uploaded Jan15 2013 already and reported by matanya on IRC today. Help appreciated. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A testing bug management wheel
Thanks Chris Zeljko. We have two more weeks booked now: https://www.mediawiki.org/wiki/QA/Weekly_goals On 01/24/2013 09:30 AM, Chris McMahon wrote: We in QA discussed some possibilities for the browser test automation community activities, and we suggest that the first couple of community events be educational. Very good idea! Still, all the better if we can define actual contribution goals around those educational activities. For instance: In particular, we think it would be beneficial to start with some introductory topics to be presented as a hangout+IRC chat+documentation on the wiki. Our suggestions for the first two events: * how anyone can write an Test Scenario to be automated (and why this is important!) Booked for the week starting on Feb 11 as Write your first Test Scenario in plain English The educational approach is exactly how you expose it. The practice is to write one test scenario at the end of the week. We will give actual scenarios to volunteers asking for them and we will help them getting through. At the end of the week we should have not only a group of people theoretically knowing how to write test scenarios in plain English, but also a real set of new descriptions ready to go for the next step. * how to read, understand and analyze results in the Jenkins system we have for browser automation A good proposal, booked for the week starting on Mar 11. Please help defining what could be the practice, the actual contribution made by participants at the end of the week. -- 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] A testing bug management wheel
* how to read, understand and analyze results in the Jenkins system we have for browser automation A good proposal, booked for the week starting on Mar 11. Please help defining what could be the practice, the actual contribution made by participants at the end of the week. It's right here if you want to take a look: https://wmf.ci.cloudbees.com/ -C ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] A testing bug management wheel
On 01/24/2013 10:52 AM, Chris McMahon wrote: * how to read, understand and analyze results in the Jenkins system we have for browser automation A good proposal, booked for the week starting on Mar 11. Please help defining what could be the practice, the actual contribution made by participants at the end of the week. It's right here if you want to take a look: https://wmf.ci.cloudbees.com/ What we need to decide is what useful contribution can we ask volunteers to do with it during the week of training. -- 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] Naming our developer events
I may be in the minority - but I like the idea of adding some structure to the naming and logos. It may not matter to those of us already involved, but in trying to engage new people - having three events with very similar purpose but three different names is confusing and sometimes makes us look a bit unorganized. While it appears no one will be winning popularity contests shepherding this conversation along, I am glad to see it happening. -Greg aka varnent ___ Sent from my iPad. Apologies for any typos. A more detailed response may be sent later. On Jan 23, 2013, at 7:23 PM, Quim Gil q...@wikimedia.org wrote: On 01/23/2013 03:07 PM, bawolff wrote: To be honest making naming requirements sounds like a bikeshed discussion. I'm sorry it has been perceived by some as such. I started the discussion after the real need this morning of suggesting a name to a local promoter willing to organize an event. End of discussion at wikitech-l. If anybody is interested please continue at https://www.mediawiki.org/wiki/Talk:Groups/Promotion#Naming_our_developer_events_23068 The Promotion group is actually the perfect context for discussions about names, logos, events and such. If you are interested in these topics please watch https://www.mediawiki.org/wiki/Groups/Promotion and consider joining the group. -- 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] Wikimedia Hackathon 2013 brainstorming
I'm actually at another conference right now - so I am limited in how much I can answer right now. :) I do not think there are answers to who is coordinating it - beyond that the programme committee has been tasked with making sure it happens. As far as how it fits into the larger scheme of things - I think the Hackathon at Wikimania has become the main developer hangout and working part of the conference. Also our best chance to do hands on with newbies, meet in person to discuss complex projects, and spend a few hours collectively hammering out code. I don't think it will matter where the folks organizing it are from - the folks organizing last year were not in the DC area (although many of us were out there several times beforehand anyway - so there was certainly familiarity. As for me - I'm once again serving on the Wikimania programme committee - so basically doing my part to make sure the Hackathon comes together and that developers have good representation in workshops, etc. :) So I'm in a position to help whomever is running it, but I like the idea of mixing up who the primary people are so we can get variety in Hackathon programming - although maybe folks would prefer consistency. I'm open to thoughts on that, obviously. :) I don't personally think it matters if the Hackathon coordinator is involved with other parts of Wikimania, is local, is staff or volunteer, or is a Borg queen - I think the main qualifier is a developer that can organize and willing to lead conversations on coordinating the event, and then helping make sure things run smoothly the day of. We had volunteers, staff, and a consultant helping with it last year. Okay - so that was more info than I thought I'd have time to share. :) -Greg aka varnent PS. God help us if we ever find a varnent in Hong Kong or elsewhere. As my partner can attest to - one of me is one too many already. ___ Sent from my iPad. Apologies for any typos. A more detailed response may be sent later. On Jan 24, 2013, at 1:10 PM, Quim Gil q...@wikimedia.org wrote: On 01/23/2013 10:46 PM, Gregory Varnum wrote: Greetings, Wikimania is six months away - and in terms of planning - that means it is right around the corner. As such, folks involved with programme and Hackathon organizing are very interested in any ideas that WM developers may have for this year's Hackathon. Please contribute them on-wiki - https://wikimania2013.wikimedia.org/wiki/Hackathon/Brainstorming Or if that is just too much wiki for today - feel free to email me and I'll make sure it gets posted. :) Thank you! -greg aka varnent Wikimania 2013 Programme Committee / geek helping with Hackathon Thank you! Before jumping to the Wikimania website, could you share your own thoughts and lessons learned from last Wikimania Hackathon? Feedback from any other participants is welcome as well. URLs with feedback are welcome too! There are the valuable http://lists.wikimedia.org/pipermail/wikitech-l/2012-July/062065.html http://lists.wikimedia.org/pipermail/wikitech-l/2012-July/062066.html As an outsider (not for long) the main concerns I see are: * No local tech contact specifically interested in the Hackathon found so far. Who is the varnent of Hong Kong 2013? And what is your role this year, by the way? Good to see you involved! * Personally no idea about the Hong Kong Wikimedia tech / MediaWiki community. * Far from US Europe, unclear how many usual suspects of this community will make it. * Unclear (to me, still) actual purpose, goal and fit with the rest of Wikimania. Before having this framework more clear, it is difficult to jump to specific ideas at the Wikimania website, other than wlan should work well, we need plugs in each table and so on. :) -- 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
[Wikitech-l] MediaWiki Event in the Philippines
Hello, Last January 12, some web technology enthusiasts attend the first MediaWiki meetup / orientation in Makati City, Philippines. Here is the photo from fb: https://fbcdn-sphotos-f-a.akamaihd.net/hphotos-ak-prn1/71495_10151206726144397_1656935086_n.jpg Part of the things discussed is having a workshop for aspiring developers. Since our community is in its infancy and there is scarcity of subject matter experts, may we ask your assistance in planning and developing this outreach workshop. Part of the assistance include: 1. Having a resource speaker / guru to train and assist our future local tech trainers 2. Creation of a workshop module that include exercises and practice tests Depending on the outcome of our plan, we are targeting to have this started this April in time on our Summer break. Summer in the Philippines coincides with Spring in other places in the northern hemisphere. Thank you. -- Butch Bustria Manila, Philippines -- The information contained in this message is privileged and intended only for the recipients named. If the reader is not a representative of the intended recipient, any review, dissemination or copying of this message or the information it contains is prohibited. If you have received this message in error, please immediately notify the sender, and delete the original message and attachments. Please consider the environment before printing this email. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] WikiVoyage image scaling (was Re: Limiting storage/generation of thumbnails without loss of functionality)
On 01/23/2013 12:45 PM, Jon Robson wrote: It would be great if someone in the analytics team could give an idea of the most commonly requested thumbnails and we could use this as the basis for a new conversation. Serendipitously, about the same time you mentioned most commonly requested thumbnails, User:Nicholasjf21 showed up at the MW Support Desk asking for help with the following problem: We're currently trying to brighten our Main Page with some large images, but could do with them scaling automatically according to the user's screen resolution. Is there any way of doing this? -- http://hexm.de/or I pointed to this discussion, but it seems like this would be the perfect time to get some statistics on image scaling. If this sort of scaling became more common, I could see it resulting in a large number of awkward resolution thumbnails that are only rarely used. Mark. -- http://hexmode.com/ Language will always shift from day to day. It is the wind blowing through our mouths. -- http://hexm.de/np ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Limiting storage/generation of thumbnails without loss of functionality
On 01/24/2013 04:28 AM, Georgiy Tugai wrote: Also, a lightbox feature may help - expand the image to the full size (as sent by the server) on click, then link to the file page upon a second click (hide the lightbox upon a click outside of the image borders). I am unsure how difficult this feature would be to add -- I have not dug around in MediaWiki's code before. Can someone point me in the right direction? It shouldn't be too difficult. You could start with a gadget (https://www.mediawiki.org/wiki/Gadget), then if it gets popular, try to move it to core. I might be able to help if you have questions. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] switched planet to new software (finally)
Hi, last night i finally made the switch to the new planet software. http://wikitech.wikimedia.org/view/Planet.wikimedia.org == What is planet? == An RSS feed aggregator. See [[meta:Planet_Wikimedia]] for details. == How do i access it? == http://en.planet.wikimedia.org/ and several other languages, *.planet.wikimedia.org. == New planet (planet-venus) == On Jan,23rd 2013 we switched from the [http://wikitech.wikimedia.org/index.php?title=Planet.wikimedia.orgoldid=25640 old planet] (http://www.planetplanet.org/) to the new planet-venus (http://www.intertwingly.net/code/venus/) === What's better about the new planet? === #It's packaged in Ubuntu. ([http://packages.ubuntu.com/km/lucid/python/planet-venus planet-venus]), the old planet was not packaged. #It's fully [https://gerrit.wikimedia.org/r/#/q/project:operations/puppet+topic:planet+status:merged,n,z puppetized], the old planet was all manual. #It uses [[git]]. People adding feed URLs can just send [[Gerrit]] patchsets. The old planet used SVN. #It's a complete rewrite of the old code in Python. It uses more modern technology like html5lib, Atom, XSLT and templates. #.. == What may not be better about the new planet (yet)? == #The gmq planet, which is a combo of Scandinavian languages does not have separate index pages in each language yet. #Some CSS/layout/design issues, like localized logo in Arabic or right-to-left alignment of thumbnails. (Arabic does already use a separate CSS file though and has the sidebar on the right hand side) #It does not include iframes (this might be considered a good thing though) == Where should i report issues? == On Bugzilla. == Where does it run? == On [[zirconium]] in [[eqiad]]. The old planet was on [[singer]]. == Where's the code? == In git, in the operations/puppet repo: #./manifests/role/planet.pp #./manifests/misc/planet.pp and #git clone https://github.com/rubys/venus.git == How do i add/remove feed URLs? == #[https://labsconsole.wikimedia.org/wiki/Git#Git.2FGerrit_and_the_repositories Clone] the operations/puppet git repository. #go to ./puppet/templates/planet/ and edit one of the language_config.erb files #submit to gerrit and have somebody merge it == How do i change HTML of the index pages? == #see above, edit ./puppet/templates/planet/index.html.tmpl.erb == How do i add/change translations in the index pages or add a new language? == #see above, edit ./puppet/manifests/role/planet.pp (find $planet_languages=...) == How do i request changes if i can't or don't want to submit a change set myself? == Ask on [[meta:Planet_Wikimedia#Requests_for_Update_or_Removal]] == Are there more general docs on planet-venus and it's architecture? == Sure, see [http://www.intertwingly.net/code/venus/docs/index.html docs] and [http://www.intertwingly.net/code/venus/docs/venus.svg venus.svg]. -- Daniel Zahn dz...@wikimedia.org Operations Engineer ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
