Hi, today at the Engineering Community Team IRC meeting we had a
discussion about the Facebook Open Academy program:
https://www.mediawiki.org/wiki/Facebook_Open_Academy#Projects
See the minutes and full logs at
https://www.mediawiki.org/wiki/Engineering_Community_Team/Meetings#2014-01-…
In order to be on the same page, mentors of the different projects
please get your basic project information ready at the table in the
Facebook_Open_Academy page. Also ask your students to add themselves there.
As commented in the meeting, I'm hoping to have Flow enabled in the main
project pages, as a way to vehiculate project discussions better.
Maryana could not promise a date, but she likes the idea. I'm hoping for
early February. If the teams want to consider other options such as a
specialized existing or new mailing that is also fine.
Questions? Feedback? Be my guest. It is the first time we join this
program and there are still many question marks. It's going to be fine. :)
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
MediaWiki Bugzilla Report for February 17, 2014 - February 24, 2014
Wikimedia Bugzilla report (FAILED), DB connection failure FAILED
DB connection failure
On Tue, 25 Feb 2014, at 5:29, Mark Holmquist wrote:
> On Tue, Feb 25, 2014 at 01:35:33AM +1100, Gryllida wrote:
> > ... With this in mind I would personally encourage heavy collaboration of all teams to build a framework which lets people script the MediaWiki software including media viewer screen, log-in screens, article creation screens / wizard, an interactive thingie for working with templates [1] (taking an {{unblock}} request for example without having to memorize the template syntax).
> > [1] https://www.mediawiki.org/wiki/User:Gryllida/Templates/Interactive
>
> Just one massive framework for *all* of that? Actually, it already
> exists [7]. What we should be asking for is more use of it by core and
> extensions, but we're already working on that, too [8].
>
> [7] https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.hook
> [8] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/168
Do you find that enough for contributors to develop interactive bits of software which are easy to maintain and share code with each-other? I don't.
> -
> > >
> > > What's the Publish/Discuss/Translate/etc blocks for? They look like
> > > navigation but don't seem to go anywhere or correspond to anything.
> >
> > They attempt to summarize the best features that MediaWiki can offer.
> > Indeed, there are no detailed product descriptions to link to, but this
> > is because we don't have them. I would say this is better than nothing.
> > Currently you either know what MediaWiki plus selected extensions can
> > offer, or you guess it by becoming a Wikipedia power user, or you need
> > to connect many pages in mediawiki.org.
>
When i read that page it makes it seem like these features are available
out of the box, which is kind of misleading. In particular claiming we have
wysiwyg editing without mentioning visual editor is extremely difficult to
install doesnt seem like a good idea.
Personally i thought the translate box meant that the mediawiki interface
is translated into many languages (something we can certainly brag about).
Overall i like the idea of the redesign that you have in the uploaded file.
> > > Bugzilla should have a prominent link. Sysadmins and other users who
> > > found bugs are not necessarily looking to 'get involved'. They found
> > > bugs and want to report them or find fixes. They're looking for a bug
> > > thing. Where is that?
>
+1 bugzilla is very important for downstream users who have bugs.
> > "Support" links to https://www.mediawiki.org/wiki/Project:Support_desk ,
> > which is where many MediaWiki sysadmins go when they have/find problems.
> > Bugzilla is not visibly featured there, and it probably should be.
Getting support is different from filing bugs.
-bawolff
Hi,
Hopefully this is the right place to ask...?
I wrote a small event calendar extension¹ utilising the FullCalendar
jQuery plugin. Sometimes it happens that the display is garbled, see
attachment. My current dirty fix is to rerender the calendar after a
timeout².
My theory is that the outcome depends on the order of the JS and CSS
resources being loaded, so it depends on server and network latency. Is
this possible? Or can I be sure that all CSS is active when I init the
calendar? If not, is there a ResourceLoader hook I can use? Other ideas?
Live Demo:
https://foodhackingbase.org/wiki/Events
Sincerely,
--
Steffen Beyer <steffen(a)beyer.io>
¹ https://github.com/improper/mediawiki-extensions-yasec
²
https://github.com/improper/mediawiki-extensions-yasec/blob/master/resource…
Hi all,
Freenode IRC is experiencing some issues again, as it was a day ago. I came
to know about some servers on #freenode and they seem to be working fine. I
could remain connected while everyone else got disconnected.
You can add the following servers for Freenode to the list:
1. kornbluth.freenode.net/6667
2. leguin.freenode.net/6667
3. card.freenode.net/6667
Hope that gets you back into the chatroom. :)
--
Warm Regards,
*Pratik Lahoti*
User:BPositive <http://en.wikipedia.org/wiki/User:BPositive>
Dear all,
------------------------------
Like with all other development, I find a need in more documentation of the plans and of the currently active things.
For example, VisualEditor has nothing to help me comprehend its code-base than the source code itself; it had only been a jamesf's line at a meeting which made me aware of the fact that the cologne blue and modern skins are now only supported by community.
Now there are some really cool beta features that only work with the vector skin. To only resource to help me is the source code. There is no UML diagram, no docs explaining which part of code does what.
------------------------------
Another idea is an answer to WHY you are working on the media viewer. It is a nice experience but...
...there is a lot of pages which would make use of a do-it-without-page-reload approach, such as log-in page, edit page, history page.
...there also is a need of all sister projects in wizard tools and widgets. Currently adding an article to Wiktionary is a royal pain and I could not figure out how to add an idiom with translation, without pulling hair and spending time to find another existing Wiktionary entry which is (1) a verb, (2) an idiom, and (3) has a translation. There also are gadgets for the so-called "interactive template" use-case [1] where each developer reinvents wheel a lot and the gadgets share no code but they should.
...everything the WMF works on should have long-term impact after WMF stops working on the darn thing. The impact should be cross project.
... With this in mind I would personally encourage heavy collaboration of all teams to build a framework which lets people script the MediaWiki software including media viewer screen, log-in screens, article creation screens / wizard, an interactive thingie for working with templates [1] (taking an {{unblock}} request for example without having to memorize the template syntax).
This may need help from VisualEditor and Parsoid people; from Flow people who had spread the 'custom workflows' rumour; and YOUR help to understand that moving an interactive thingie logic from an extension onto a wiki benefits everyone, even if it makes codereview-worthy bits harder to spot (recall some people saying that none of UploadWizard's logic can sit on-wiki because of that [2])
[1] https://www.mediawiki.org/wiki/User:Gryllida/Templates/Interactive
[2] https://www.mediawiki.org/wiki/Requests_for_comment/UploadWizard:_scale_to_…
Gryllida.
On Sun, 23 Feb 2014, at 20:25, Gergo Tisza wrote:
> Hi all,
>
> the Multimedia team had some discussions recently about how to make our
> work more transparent and more open to volunteers, and we decided to try
> using an open subscription mailing list for team discussions, instead of
> the current practice of cc-ing each member manually. These discussions are
> about day-to-day details of our work; sometimes feature requirements or
> design, sometimes technical details. The volume is typically one or two new
> threads per day.
>
> We weren't sure how much members of this list would be interested in such
> conversations and didn't want to flood this list with mails that are not
> useful for most members, but we also do not want to split conversation
> channels unnecessarily. Please help us by telling whether you would be
> interested in the topics mentioned above, or would prefer if we created a
> new mailing list for them.
>
> Thanks!
> Gergő
> _______________________________________________
> Multimedia mailing list
> Multimedia(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/multimedia
Hello list,
there is a scheduled maintenance release of MediaWiki on Thursday, 27th of
February. I would like to take the opportunity to point you to the list of
known issues [1]. Maybe we can get a few of those fixed until mid of the week?
Best,
Markus
[1] http://www.mediawiki.org/wiki/MediaWiki_1.22/Known_issues
I've taken the liberty of enabling[1] lower-resolution .ogv video
transcodes, at 360p and 160p in addition to the 480p we already generated.
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=61690
These will be useful for older or slower or mobile machines which need to
use non-native software decoding fallbacks (such as the existing Java
applet, or the JavaScript or Flash alternatives I'm working on in research
time) and may not be able to decode a full 480p file made from an SD or HD
video original.
Files should gradually populate at the smaller sizes as they get referenced
and the new sizes are automatically added to the transcoding queue.
Please give a shout if there's any problems.
-- brion
Hello community,
tl;dr:
I'd love to see if there's anyone in the community that can help me take
charge of ExtensionStatus development, or take it over completely.
Longer version:
About 9 months ago, just before I started Google Summer of Code 2013, I
developed "ExtensionStatus", which checks the current status of all
extensions that are installed in the given wiki and compares them with
either their git branch info (if git is available) or scrapes data from the
gerrit website. It gives sysadmins an at-a-glance dashboard so they can see
what needs upgrading.
There was a bit of interest, so I went on and started some testing, which
seemed to go well for a while.
But then I started GSoC and the project I worked on kept me quite busy.
After the summer I went back to full-time grad school and a part-time job,
both of which took me away from working on developing the extension any
further than its extremely experimental state.
In the last couple of days I started seeing a renewed interest in the
extension, and I think it could be worth a second visit. I'd love to
continue working on it, but with grad school and work, my time is really
limited and I don't think I can take it on alone.
Considering all of that, I thought I'd officially "unlick the cookie" and
see if there is interest from the community to take it on either fully or
partially.
Here's the github repo:
https://github.com/mooeypoo/MediaWiki-ExtensionStatus
And here's the extension page:
https://www.mediawiki.org/wiki/Extension:ExtensionStatus
There's also an empty gerrit repo that is awaiting setup:
https://git.wikimedia.org/summary/mediawiki%2Fextensions%2FExtensionStatus
(I didn't really have much experience with gerrit back then to set it up
properly - and now I am not sure I'd have the time to develop, review, and
approve code on my own.)
So, does anyone want to join in and help revisit the code?
Cheers,
Moriel
(aka mooeypoo)
--
No trees were harmed in the creation of this post.
But billions of electrons, photons, and electromagnetic waves were terribly
inconvenienced during its transmission!