[Wikitech-l] Invitation for Localisation team development demo 2012-09-04 15:00 UTC
You are invited to the Localisation team development demo on Tuesday 4 September 2012 at 15:00 UTC (other time zones: 08:00 PDT, 17:00 CEST, 20:30 IST). This meeting will take 40 minutes at most. In this meeting the Localisation team will present its deliverables from sprint 23[1]. After about 20 minutes of presentation, the remainder of the meeting is available for discussion. We hope you can attend, and please invite any other colleagues or friends you think are interested! This meeting will be held using WebEx. Please ensure that you log in a few minutes before the meeting starts, so that you have time to install any required plug-ins or software. Connection details and a quick link to add this meeting to your calendar can be found below the signature. Slides and the video of our previous sprint demo are also available[2,3]. [1] https://mingle.corp.wikimedia.org/projects/internationalization/cards/1072 [2] https://commons.wikimedia.org/wiki/File:Wikimedia_Localisation_team_Sprint_22_demo.pdf [3] https://commons.wikimedia.org/wiki/File:Wikimedia_Localisation_team_Sprint_22_demo.ogv -- Siebrand Mazeland Product Manager Localisation Wikimedia Foundation M: +31 6 50 69 1239 Skype: siebrand Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate --- To join the online meeting (Now from mobile devices!) --- 1. Go to https://wikimedia.webex.com/wikimedia/j.php?ED=15076568&UID=41853448&RT=MiM0 2. If requested, enter your name and email address. 3. No password is required 4. Click "Join". To view in other time zones, please click the link: https://wikimedia.webex.com/wikimedia/j.php?ED=15076568&UID=41853448&ORT=MiMyMg%3D%3D To add this meeting to your calendar program, click this link: https://wikimedia.webex.com/wikimedia/j.php?ED=15076568&UID=41853448&ICS=MI&LD=1&RD=2&ST=1&SHA2=uFTn2pMnBAxcaLHkOpTnseK71m944AqUXSGYwV4PJ0M=&RT=MiM0 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] DatabseBase::select behaving broken
Hey, For some reason DatabseBase::select is returning false sometimes when it encounters a database error rather then throwing an error as you'd expect since it's documented to always return a ResultWrapper. I ran into this issue several times as getting the rather obscure error "expected ResultWrapper, got boolean" in random places using this result. Calling lastError on the DatabaseBase object clearly shows there in fact was an SQL error. I have all SQL debug settings I'm aware off on: $wgShowSQLErrors= true; $wgShowDBErrorBacktrace = true; $wgDebugDumpSql = true; Plus the usual bunch of dev settings. So this smells like a regression to me, or something that always was broken but not noticed due to people not using type hinting. Anyone an idea where this is coming from? I had a look but it's not clear to me. 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] scaled media (thumbs) as *temporary* files, not stored forever
On 31 August 2012 19:45, Isarra Yos wrote: > On 31/08/2012 08:57, Brion Vibber wrote: >> >> Heck yes. Generate some standard sizes at upload time and let the browser >> scale if a funny size is demanded. Modern browsers scale photos nicely, not >> like the nearest-neighbor ugliness from 2002. > > > As a graphist, I must say this does not seem like a good idea. Only > rendering certain sizes and having the browser then scale the weird ones > will still result in fuzzy images, because no matter how good the renderer, > every time a bitmap image is scaled down, sharpness is lost. This is part of > why there is so much emphasis placed on using vectors even in a static > environment - with those, the first scale down is also avoided, and there is > a very visible difference in clarity even there. But while only rendering > certain sizes and then having the browser scale those would defeat that > purpose, having to scale down bitmaps twice would look even worse, > regardless of subject. > > -- > -— Isarra A possible scenario where a human intervention is always needed is generating icons from svg files that draw flags or ..icons. A 16x16 pixels USA flag rendered from a SVG by some naive rescaling (mipmaping?) will look worse than wrong. Perhaps you still want to have this icon generated from or inspired by the SVG file. In videogames this sort of problems are sometimes solved by having all the scaled versions precalculated in a single file: mipmaps. http://en.wikipedia.org/wiki/Mipmap Modern videogames uses other more advanced techniques, but the beauty of mipmaps is that can be artist edited (perhaps the artist can edit the 16x16 pixels version to still make sense. -- -- ℱin del ℳensaje. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] scaled media (thumbs) as *temporary* files, not stored forever
On Mon, Sep 3, 2012 at 5:45 AM, Brion Vibber wrote: > On Sun, Sep 2, 2012 at 8:25 PM, Thomas Dalton wrote: > >> On Aug 31, 2012 11:52 PM, "Brion Vibber" wrote: >> > >> > * Definitely don't have "left" "right" or "center" options. >> >> Can you elaborate on that? The positioning of images can make a big >> difference to how a page looks. Do you really think you can automate it in >> a way that makes pages always look good? > > > Looking at say https://en.wikipedia.org/wiki/San_Francisco the positioning > of most photos to left or right floats seems fairly random; where both left > and right are used it seems to be a manual hack to keep images from > stacking on top of other images or tables, based on typical screen sizes. > > Would an automatic gallery layout look as good and be as usable? Honestly, > it might; I don't see much that's meaningful about the way these images are > laid out that would be lost by a different layout. > > Would it look the same exactly? No, but who cares? > > Should it lay out in right and left alignment? Maybe not -- maybe it should > use horizontal space and avoid floats? Maybe it should use a dedicated > right-side gutter (left on RTL)? > > Maybe we should at least think about it. > > It's also useful to be able to >> know where an image is going to be displayed so you can say thing like "as >> can be seen in the image to the right". >> > > No space to left or right on mobile; safer not to rely on such positioning > being consistently relatable. > > Consider also a hyperlink instead of a vague direction when referencing > something. :) > > Getting images to work well on phones and tablets probably requires more >> user control, not less. It would be useful to be able to specify whether an >> image is vital to the article and should always be displayed or if it is >> just there to look nice and can be skipped if there isn't much screen >> space. (Sensible defaults are a must, of course.) >> > > Indeed, distinguishing between different types of things can help -- and I > think would help far more than any manual positioning in the majority of > cases that aren't icons or otherwise explicitly inline in text or a table. > > Note that tables, infoboxes, etc have the same issues with positioning, > floating, referencing, and whatnot. And like panoramic images, they > sometimes don't fit on small screens well; that's another thing to think > about. > > -- brion > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l Illustrating the problem of manual right/left aligned thumbnails and elements by using slightly different CSS: http://toolserver.org/~magnus/redefined/?page=San%20Francisco Magnus ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Should we make parser test executions via phpunit.php behave like running them with parserTests.php ?
> I remember that some more methods could be shared if the parameter order of parserTests.php was changed Not sure whether params order has to change but yest, more code there could be shared. No idea why the localsettings are not shared for example. > That was done for creating the "articles" once, outside of the test > loop. Originally they were also created in place, but inserting all > articles for each test was really slow. Ok, here is why I want articles to be created in-between tests, within the test loop: http://pastebin.com/g694dG6L Also, I want to change the local settings before creating certain articles, to create them with lower-case characters for some tests. I would suggest taking the lost in performance into account for that, it gives more flexibility for the tests. Or do are there any other ideas? Also see my patch-set https://gerrit.wikimedia.org/r/#/c/20534/ which is blocked by this problem, here I wanted to introduce the "!!config" sections into "!!article". " !!config" is also something new I have introduced to parser tests in case you haven't seen it yet. Cheers, Daniel 2012/9/1 Platonides > On 31/08/12 12:01, Daniel Werner wrote: > > Hi everyone, > > > > Started poking on parser tests lately and found myself riddled after a > > while. > > It seems like when running parser test files with phpunit.php they follow > > different rules as when running them with parserTests.php. > > > > If I observed this correctly, phpunit.php collects all articles to be > > created with "!!article", creates them, and then it runs tests. With > > parserTests.php on the other hand everything is executed in the order it > is > > defined. In some tests it can be important whether a article already > exists > > or not. > > That was done for creating the "articles" once, outside of the test > loop. Originally they were also created in place, but inserting all > articles for each test was really slow. > > If a test relies on some articles existing, those should be defined > before it. If it's not documented, it should be. > With that rule in place, the difference on creating at the start or on > demand doesn't matter. > > (...) > > I would very much appreciate if anyone could explain to me why there are > > both of these files and why we maintain (more or less) a whole bunch of > > redundant code for those tests. > > > > Cheers, > > Daniel > > Someone did a crappy work when creating the phpunit parser tests, > duplicating a lot of code and sharing none between them. It was later > improved by several people, as years passed, I did myself several fixes > to the phpunit code. I think it is easy to compare them with a visual > diff tool. I remember that some more methods could be shared if the > parameter order of parserTests.php was changed. > > Best regards > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- Daniel Werner Software Engineer Wikimedia Deutschland e.V. | NEU: Obentrautstr. 72 | 10963 Berlin Tel. (030) 219 158 26-0 http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] DatabseBase::select behaving broken
On 3 September 2012 12:32, Jeroen De Dauw wrote: > Hey, > > For some reason DatabseBase::select is returning false sometimes when it > encounters a database error rather then throwing an error as you'd expect > since it's documented to always return a ResultWrapper. I ran into this > issue several times as getting the rather obscure error "expected > ResultWrapper, got boolean" in random places using this result. Calling > lastError on the DatabaseBase object clearly shows there in fact was an SQL > error. So what was the error? It is not unusual that SQL errors turn up in unexpected places, see for example https://bugzilla.wikimedia.org/39287 -Niklas -- Niklas Laxström ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] DatabseBase::select behaving broken
Hey, > So what was the error? Non-existing field or table. Happens because of not running update.php. Getting some weird type error at some random location does not really suggest that though, so is likely result into one wasting time trying to find the issue. 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] DatabseBase::select behaving broken
On Mon, Sep 3, 2012 at 9:50 AM, Jeroen De Dauw wrote: > > So what was the error? > Non-existing field or table. Happens because of not running update.php. > Getting some weird type error at some random location does not really > suggest that though, so is likely result into one wasting time trying to > find the issue. > Are the Database object's flags set to ignore errors? (DBO_IGNORE in the flags, or something calling $db->ignoreErrors(true)?) Otherwise, it looks like it shouldn't happen... Throw some debugging statements into Database::query and Database::reportQueryError to see if anything stands out. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] scaled media (thumbs) as *temporary* files, not stored forever
On 03/09/2012 05:33, Magnus Manske wrote: Illustrating the problem of manual right/left aligned thumbnails and elements by using slightly different CSS: http://toolserver.org/~magnus/redefined/?page=San%20Francisco Magnus That looks like as much a problem with the general design there as with the use of images on the page itself, though. -- -— Isarra ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki Foundation (was Re: CentralAuth API access)
I'll post more on the RFC, but I wonder if an entity within WMF would be more appropriate and realistic. Utilizing the existing operations structure would be far easier. Perhaps setup something like FDC to oversee priorities and funds. My hunch is WMF would be far more likely to sign off on something they retain a sense of sign-off on for the sake of maintaining the WMF projects than having to deal with an independent entity that would have the legal right to go rogue one day and not do what's in the best interest of the WMF projects. I recognize to some extent that's the point, but looking down a 5 year road of possibilities, is that something we'd ever want to happen? My feeling is no and allowing WMF to maintain some level of authority in the development of MediaWiki is in our collective best interests. From project management, fundraising, usability, system resources and paid developer support perspective. I would instead propose a MediaWiki department or collective (insert your favorite term here). -Greg aka varnent Sent from my iPhone. Apologies for any typos. A more detailed response may be sent later. On Sep 1, 2012, at 10:42 PM, MZMcBride wrote: > Daniel Friesen wrote: >> Done in true developer style "[RFC] MediaWiki Foundation": >> https://www.mediawiki.org/wiki/Requests_for_comment/MediaWiki_Foundation > > Thank you for this! This is exactly what I had in mind. > > It's interesting, with a lot of (proposed) non-profits, the biggest concerns > are engaging volunteers and generating income. With this proposed > foundation, I think most of the typical concerns aren't in play. Instead, as > Nikerabbit so deftly commented on the RFC's talk page, the big question is: > > What projects would a MediaWiki Foundation work on and how would those > projects be chosen? > > This seems to be _the_ crucial issue. Getting grants from the Wikimedia > Foundation or Wikia or others doesn't seem like it'd be very difficult. > Assuming there was broad support for the creation of such a foundation from > active MediaWiki developers (and related stakeholders), getting the > Wikimedia Foundation to release the trademark and domain also doesn't seem > like it would be very difficult. But there's a huge unresolved question > about how, out of the infinite number of project ideas, a MediaWiki > Foundation would choose which ideas to financially support. > >> As you command oh great catalyst[1]. >> [1] Hope you don't mind. I found it amusing. And it kind of fits in a >> positive way. > > Cute. :-) > > MZMcBride > > > > ___ > 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] MediaWiki Foundation (was Re: CentralAuth API access)
A number of comments: 1. The community is an a massive untapped resource for development. (They like to edit wikis, upload photos and also to code) e.g. The amount of Template Code in about 20 times the size of MediaWiki code base. 2. I would seriouly look at maximizing its potential before allocating more funds for paid devlopment. 2.1 This means making it much easier to develop/test/deploy to Live wikis. (Short Tutorials, Code Samples, Documentation) 2.2 Create a culture where new coders are assigned to work with experinced coders to fix and maintaining existing code. 2.3 Motivating paid developer to work (i.e. review and direct) the community 2.4 Team up with Wikia and WikiHow Devteams on common features and on small wiki testing. 3. Looking at the metrics - The Mediawiki team is still not setup to do developement like other leading Open Souce development communities. Git is a step in the right direction but - the agility of the teams is too low to collaborate at the levels required. to accept "AnonymousDonation" of source from the community. While I applud Sumana who does a great job with the community - this works needs to be followed though organicaly by all members of the development teams or we will continue sending the community the message - that we prefer to delay fixing bugs, pay a premiunm for new features etc ... 4. Only once such issues are adressed would it become productive to engage more developers with WMF or external funding. 5. The one point I do agree with is that features the community asks for should be given due proirity and this process should be more transparent. Oren Bochman On Mon, Sep 3, 2012 at 8:10 PM, Mr. Gregory Varnum wrote: > I'll post more on the RFC, but I wonder if an entity within WMF would be > more appropriate and realistic. Utilizing the existing operations structure > would be far easier. Perhaps setup something like FDC to oversee priorities > and funds. > > My hunch is WMF would be far more likely to sign off on something they > retain a sense of sign-off on for the sake of maintaining the WMF projects > than having to deal with an independent entity that would have the legal > right to go rogue one day and not do what's in the best interest of the WMF > projects. I recognize to some extent that's the point, but looking down a 5 > year road of possibilities, is that something we'd ever want to happen? My > feeling is no and allowing WMF to maintain some level of authority in the > development of MediaWiki is in our collective best interests. From project > management, fundraising, usability, system resources and paid developer > support perspective. > > I would instead propose a MediaWiki department or collective (insert your > favorite term here). > > -Greg aka varnent > > > Sent from my iPhone. Apologies for any typos. A more detailed response may > be sent later. > > On Sep 1, 2012, at 10:42 PM, MZMcBride wrote: > > > Daniel Friesen wrote: > >> Done in true developer style "[RFC] MediaWiki Foundation": > >> > https://www.mediawiki.org/wiki/Requests_for_comment/MediaWiki_Foundation > > > > Thank you for this! This is exactly what I had in mind. > > > > It's interesting, with a lot of (proposed) non-profits, the biggest > concerns > > are engaging volunteers and generating income. With this proposed > > foundation, I think most of the typical concerns aren't in play. > Instead, as > > Nikerabbit so deftly commented on the RFC's talk page, the big question > is: > > > > What projects would a MediaWiki Foundation work on and how would those > > projects be chosen? > > > > This seems to be _the_ crucial issue. Getting grants from the Wikimedia > > Foundation or Wikia or others doesn't seem like it'd be very difficult. > > Assuming there was broad support for the creation of such a foundation > from > > active MediaWiki developers (and related stakeholders), getting the > > Wikimedia Foundation to release the trademark and domain also doesn't > seem > > like it would be very difficult. But there's a huge unresolved question > > about how, out of the infinite number of project ideas, a MediaWiki > > Foundation would choose which ideas to financially support. > > > >> As you command oh great catalyst[1]. > >> [1] Hope you don't mind. I found it amusing. And it kind of fits in a > >> positive way. > > > > Cute. :-) > > > > MZMcBride > > > > > > > > ___ > > 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 > -- Oren Bochman Office tel. 061 4921492 Mobile +36 30 866 6706 skype id: orenbochman e-mail: o...@romai-horizon.com site http://www.riverport.hu ___ Wikitech-l mailing list Wikitech-l@lis
Re: [Wikitech-l] MediaWiki Foundation (was Re: CentralAuth API access)
As a new MediaWiki developer (8 merged commits right now, https://gerrit.wikimedia.org/r/#/dashboard/417) and an experienced template and Gadget developer on pl.wikipedia (https://pl.wikipedia.org/wiki/Wikipedysta:Matma_Rex): 2012/9/3 Oren Bochman : > 1. The community is an a massive untapped resource for development. (They > like to edit wikis, upload photos and also to code) Totally this. Don't also forget about non-English wikis; there are many JavaScript programmers and tools developers who for various reasons do not look into MediaWiki itself. (I used to be one until recently.) > 2. I would seriouly look at maximizing its potential before allocating more > funds for paid devlopment. > 2.1 This means making it much easier to develop/test/deploy to Live wikis. > (Short Tutorials, Code Samples, Documentation) > 2.2 Create a culture where new coders are assigned to work with experinced > coders to fix and maintaining existing code. > 2.4 Team up with Wikia and WikiHow Devteams on common features and on small > wiki testing. All this could be great, but for me the worst "obstacle" is the glacial pace of gerrit review. As a template/gadget developer I'm used to a quick cycle: code, preview (a template) or test in debugger (gadget), look at it for five more minutes to maybe catch some stupid mistakes, and press Save (of course, I also used dev versions of scripts or templates' sandboxes for non-trivial changes). With gerrit, I code, check, check on my testwiki, git review (and by god, is that tool a total kludge!), and then I wait for days for someone to look at my changes, or head to #mediawiki and beg for reviews (and apparently the channel is half-dead; is it supposed to be a support channel? Because sometimes I'm the only one replying to newcomers there...). It sometimes looks like all the experienced MW developers are just reviewing each other's changes. Then someone complains (sometimes about something pointless, or something they could fix themselves in thirty seconds and submit a patchset), I code again, git review again, and wait again. (I don't mean this all personally, to anyone.) > While I applud Sumana who does a great job with the community - this > works needs to be followed though organicaly by all members of the > development teams Let me just say that I basically love Sumana already, for her help and encouragement. :) Also. gerrit is absolute load of poop. The web UI kinda sucks (but we all know this already, don't we?), but my real beef is with the git-review tool. I'm semi-experienced with git, and rebases are not a scare to me; but if it keeps complaining about multiple commits to be sent when I only have a single new one, and if something as simple as creating a commit that depends on two other unmerged commits requires this much arcane magic, and if I can't post a review to go along with my patchset, and if it requires hand-applied patches (!) to work properly on Windows, then something is deeply wrong. I can only imagine what kind of torture using it must be to someone just starting out with git (or, worse, source control). -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] scaled media (thumbs) as *temporary* files, not stored forever
On 3 September 2012 17:10, Isarra Yos wrote: > On 03/09/2012 05:33, Magnus Manske wrote: >> >> Illustrating the problem of manual right/left aligned thumbnails and >> elements by using slightly different CSS: >> >> http://toolserver.org/~magnus/redefined/?page=San%20Francisco >> >> Magnus > > That looks like as much a problem with the general design there as with the > use of images on the page itself, though. I agree. The skin not wrapping text around the images isn't caused by users having a choice of what side of the page to put the image on. It's caused by the skin being badly designed... ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki Foundation (was Re: CentralAuth API access)
On Mon, 03 Sep 2012 12:59:19 -0700, Oren Bochman wrote: A number of comments: 1. The community is an a massive untapped resource for development. (They like to edit wikis, upload photos and also to code) e.g. The amount of Template Code in about 20 times the size of MediaWiki code base. 2. I would seriouly look at maximizing its potential before allocating more funds for paid devlopment. Volunteers have very little spare time, WMF employees' 20% time is also small, many of our bugs and large features are not useful to WMF's goal, and many of them are large enough simply by unavoidable fact that people avoid starting them when they only have spare time to work with. How is trying to 'maximize [the] potential' of an unrewarded group of people -- who are here on their own terms, not to be expected anything of -- going to help when many of the features we're expecting to get done are too big for someone to do in their spare time? We can try to fix the issues with getting the community involved. But I do not believe that doing that excludes also fixing the gap we have of people who have enough time to complete the large features we are missing. They are not mutually exclusive so there is nothing stopping us from doing both. 2.1 This means making it much easier to develop/test/deploy to Live wikis. (Short Tutorials, Code Samples, Documentation) 2.2 Create a culture where new coders are assigned to work with experinced coders to fix and maintaining existing code. 2.3 Motivating paid developer to work (i.e. review and direct) the community 2.4 Team up with Wikia and WikiHow Devteams on common features and on small wiki testing. Wikia has been trying to get some of their tweaks in lately. But in general they build custom stuff for anything they want. I'm not sure how much we can even collaborate with them on. 3. Looking at the metrics - The Mediawiki team is still not setup to do developement like other leading Open Souce development communities. Git is a step in the right direction but - the agility of the teams is too low to collaborate at the levels required. to accept "AnonymousDonation" of source from the community. While I applud Sumana who does a great job with the community - this works needs to be followed though organicaly by all members of the development teams or we will continue sending the community the message - that we prefer to delay fixing bugs, pay a premiunm for new features etc ... This could be aided by having a MediaWiki Foundation, rather than be a reason to not have one. If the community had an idea of what replacement for Gerrit would work the foundation could hire someone to make it into something that could replace Gerrit and improve the experience. If there were a MediaWiki Foundation and people liked my Gareth idea, I wouldn't be opposed to working semi-full-time to turn it into a ready-to-use piece of software. 4. Only once such issues are adressed would it become productive to engage more developers with WMF or external funding. 5. The one point I do agree with is that features the community asks for should be given due proirity and this process should be more transparent. Oren Bochman On Mon, Sep 3, 2012 at 8:10 PM, Mr. Gregory Varnum wrote: I'll post more on the RFC, but I wonder if an entity within WMF would be more appropriate and realistic. Utilizing the existing operations structure would be far easier. Perhaps setup something like FDC to oversee priorities and funds. My hunch is WMF would be far more likely to sign off on something they retain a sense of sign-off on for the sake of maintaining the WMF projects than having to deal with an independent entity that would have the legal right to go rogue one day and not do what's in the best interest of the WMF projects. I recognize to some extent that's the point, but looking down a 5 year road of possibilities, is that something we'd ever want to happen? My feeling is no and allowing WMF to maintain some level of authority in the development of MediaWiki is in our collective best interests. From project management, fundraising, usability, system resources and paid developer support perspective. I would instead propose a MediaWiki department or collective (insert your favorite term here). -Greg aka varnent Sent from my iPhone. Apologies for any typos. A more detailed response may be sent later. On Sep 1, 2012, at 10:42 PM, MZMcBride wrote: > Daniel Friesen wrote: >> Done in true developer style "[RFC] MediaWiki Foundation": >> https://www.mediawiki.org/wiki/Requests_for_comment/MediaWiki_Foundation > > Thank you for this! This is exactly what I had in mind. > > It's interesting, with a lot of (proposed) non-profits, the biggest concerns > are engaging volunteers and generating income. With this proposed > foundation, I think most of the typical concerns aren't in play. Instea
[Wikitech-l] Moving MediaWikiWidgets.org to Wikimedia
Hi everybody, Sumana suggested I should post to this list so you guys can help me. A few years back I saw a need in easy widget creation and too many extensions that just did that, but were not so well maintained and had a bunch of XSS holes in them and so on, that's when I came up with idea of Widgets extension: http://www.mediawiki.org/wiki/Extension:Widgets Since individual widgets were just wiki pages, I created a standalone wiki where everybody can post their widgets (in special "Widget" namespace) which will be available to everyone after basic security review (it integrates with Flagged Revisions if it's installed): http://www.mediawikiwidgets.org/ There are plenty of widgets there and quite a few people use the extension and the widgets on their wikis. That being said, I moved on to other kind of work and would be happy to give MediaWikiWidgets.org back to community instead of slowly killing it by inactivity. It would be great if Wikimedia Foundation could take this project over and host it either as standalone site or as part of mediawiki.org - I'll be happy to assist in moving the catalog and would probably still be curious enough to contribute a widget or two once in a while. Best, Sergey ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Moving MediaWikiWidgets.org to Wikimedia
On Mon, 03 Sep 2012 19:57:20 -0700, Sergey Chernyshev
wrote:
Hi everybody,
Sumana suggested I should post to this list so you guys can help me.
A few years back I saw a need in easy widget creation and too many
extensions that just did that, but were not so well maintained and had a
bunch of XSS holes in them and so on, that's when I came up with idea of
Widgets extension: http://www.mediawiki.org/wiki/Extension:Widgets
Since individual widgets were just wiki pages, I created a standalone
wiki
where everybody can post their widgets (in special "Widget" namespace)
which will be available to everyone after basic security review (it
integrates with Flagged Revisions if it's installed):
http://www.mediawikiwidgets.org/
There are plenty of widgets there and quite a few people use the
extension
and the widgets on their wikis.
That being said, I moved on to other kind of work and would be happy to
give MediaWikiWidgets.org back to community instead of slowly killing it
by
inactivity.
It would be great if Wikimedia Foundation could take this project over
and
host it either as standalone site or as part of mediawiki.org - I'll be
happy to assist in moving the catalog and would probably still be curious
enough to contribute a widget or two once in a while.
Best,
Sergey
I don't really like this idea. I'd prefer it that the Widgets extension
doesn't get any more popular than it already is.
Frankly I wish I could stick an {{XSS alert}} template on that page and be
done with it. But I haven't because the extension is only an enabler
making it trivially easy to add an XSS hole into your wiki.
The premise of the extension is flawed. If someone cannot be trusted to
securely write a widget in PHP there is no way that they can be trusted to
properly escape raw concatenated html.
It basically takes extension code; Something we can put into standard
repositories. Provide full pre-commit security review. Notify users of
security holes. And in the future incorporate systems to tell you when
there's a new version (likely with a security fix) you should upgrade to;
And puts it into raw concatenated html wiki pages -- lacking in extensive
escaping and high-level abstraction -- managed by users who do not
necessarily have any programming skills much less a proper understanding
of security. Somewhere developers naturally pay no attention to. Somewhere
with no alerts about security holes, etc... And suggests that users just
C&P the Widget (potentially with an open XSS vector) into their wiki and
never look back to see if a critical hole has been fixed.
A number of widgets inside that site have critical XSS vectors inside of
them. Every time I go back there and look at random ones it doesn't take
long to find a hole.
I would not be opposed to an extension that makes high-level validation
and construction of simple widgets as extension code easier. Or making it
easier to get into Gerrit so people can submit extension code and we can
properly review it.
But there is absolutely no way that the fundamentals the Widgets extension
are based on will provide the proper environment to create secure widgets.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
