I know it has been annoying a couple of people other than me, so now that I've learned how to make it work I'll share the knowledge here.
tl;dr: Star the repositories. No, seriously. (And yes, you need to star each extension repo separately.)
(Is there a place on mw.org to put this tidbit on?)
------- Forwarded message -------
From: "Brian Levine" <support(a)github.com> (GitHub Staff)
To: matma.rex(a)gmail.com
Cc:
Subject: Re: Commits in mirrored repositories not showing up on my profile
Date: Tue, 09 Jul 2013 06:47:19 +0200
Hi Bartosz
In order to link your commits to your GitHub account, you need to have some association with the repository other than authoring the commit. Usually, having push access gives you that connection. In this case, you don't have push permission, so we don't link you to the commit.
The easy solution here is for you to star the repository. If you star it - along with the other repositories that are giving you this problem - we'll see that you're connected to the repository and you'll get contribution credit for those commits.
Cheers
Brian
--
Matma Rex
We just released a new version of Research:FAQ on Meta [1], significantly
expanded and updated, to make our processes at WMF more transparent and to
meet an explicit FDC request to clarify the role and responsibilities of
individual teams involved in research across the organization.
The previous version – written from the perspective of the (now inactive)
Research:Committee, and mostly obsolete since the release of WMF's open
access policy [2] – can still be found here [3].
Comments and bold edits to the new version of the document are welcome. For
any question or concern, you can drop me a line or ping my username on-wiki.
Thanks,
Dario
[1] https://meta.wikimedia.org/wiki/Research:FAQ
[2] https://wikimediafoundation.org/wiki/Open_access_policy
[3] https://meta.wikimedia.org/w/index.php?title=Research:FAQ&oldid=15176953
*Dario Taraborelli *Head of Research, Wikimedia Foundation
wikimediafoundation.org • nitens.org • @readermeter
<http://twitter.com/readermeter>
Hi,
On Tue, Mar 1, 2016 at 3:36 PM, David Strine <dstrine(a)wikimedia.org> wrote:
> We will be holding this brownbag in 25 minutes. The Bluejeans link has
> changed:
>
> https://bluejeans.com/396234560
I'm not familiar with bluejeans and maybe have missed a transition
because I wasn't paying enough attention. is this some kind of
experiment? have all meetings transitioned to this service?
anyway, my immediate question at the moment is how do you join without
sharing your microphone and camera?
am I correct thinking that this is an entirely proprietary stack
that's neither gratis nor libre and has no on-premise (not cloud)
hosting option? are we paying for this?
-Jeremy
Hello,
can someone to update list https://phabricator.wikimedia.org/P10500 which
contains repositories which haven't mediawiki/mediawiki-codesniffer.
I found in list that much repositories are empty, and repositories which
aren't available on Gerrit.
So, can someone please update this list of repositories (in
mediawiki/extensions) which haven't mediawiki/mediawiki-codesniffer, but at
least, contains one PHP file. or to provide me command with which I can
update list when I want, so I don't need to request it every time.
Best regards,
Zoran.
P. S.: Happy weekend! :)
Hello,
Recently, I stumbled upon a technical writing course which I found very
useful and I wanted to share it and thought of sending an email to
wikitech-l recommending it. Also, I've been looking for a resource about
VueJS with not much luck and wanted to send an email asking if anyone knows
any.
Instead, I have this idea to have a virtual library for developers so they
can share useful resources with each other. You go to a wiki page and see
list of courses, books, conference videos, on each topic and different
people recommanding them. You can also request a resource for a topic and
people respond to you. If the wiki page grows too big, we can split them to
sub pages based on topics, and so on.
I started the page in https://www.mediawiki.org/wiki/User:Ladsgroup/Library
but I'm planning to move it to the main namespace if no one objects. Please
take a look, add more recommandations, co-sign, request for a resource,
respond to a request for a resource, etc.
What do you think? Please let me know if you think it's a horrible idea or
you have feedback on details (mediawiki.org? maybe we should move it to
wikitech.wikimedia.org?)
Hope that'd be useful.
Best
--
Amir (he/him)
It does the same as the @ operator, except that it takes care to prevent a
very bad bug that existed before PHP 7. Details at
https://phabricator.wikimedia.org/T253461
If there are other issues or benefits, please write them on the task. The
overhead of AtEase is prerty minor, so really any benefit at all is likely
to tip the balance toward keeping it. But, in the event that there isn't
any, then perhaps we should slowly phase it out.
Best,
-- Timo
Hello,
The current logo of MediaWiki was adapted slightly more than fifteen years
ago and hasn’t changed since. This logo despite having the nice concept of
sunflower, is old. The sunflower represents the diversity, the constant
growth and also the wildness.
Among its biggest issues I can point out that it’s a bitmap picture so it’s
unusable in large sizes (like large posters) and it’s too realistic making
it unusable in small sizes.
Most, virtually all, software products use a simpler and more abstract
form. For example, docker, kubernetes, Ubuntu, VueJs, React, Apache Kafka,
and many more. It’s a good time for MediaWiki to follow suit.
My request is for changing the logo of MediaWiki and I have no plans or
interest in changing logo of any other project.
Please show your support, oppose or your comments in the discussion page.
You can also add more suggestions.
The discussion page:
https://www.mediawiki.org/wiki/Project:Proposal_for_changing_logo_of_mediaw…
Best
--
Amir (he/him)
Phabricator users,
this is to let you know that the "aphlict" service has been disabled on
Phabricator (for now) because it caused stability issues.
This means you will not get realtime (pop-up) notifications on Phabricator.
(If you had those enabled in the first place).
Regular notifications (that do not pop-up) and emails are not affected by
this.
https://phabricator.wikimedia.org/T238593
--
Daniel Zahn <dzahn(a)wikimedia.org>
Operations Engineer
Hi Everyone,
Mark your calendars! Wikimedia Tech Talks 2020 Episode 6 will take
place on Wednesday
on 12 August 2020 at 17:00 UTC.
Title: Retargeting extensions to work with Parsoid
Speaker: Subramanya Sastry
Summary:
The Parsing team is aiming to replace the core wikitext parser with Parsoid
for Wikimedia wikis sometime late next year. Parsoid models and processes
wikitext quite differently from the core parser (all that Parsoid
guarantees is that the rendering is largely identical, not the specific
process of generating the rendering). So, that does mean that extensions
that extend the behavior of the parser will need to adapt to work with
Parsoid instead to provide similar functionality [1]. With that in mind, we
have been working to more clearly specify how extensions need to adapt to
the Parsoid regime.
At a high level, here are the questions we needed to answer:
1) How do extensions "hook" into Parsoid?
2) When the registered hook listeners are invoked by Parsoid, how do they
process any wikitext they need to process?
3) How is the extension's output assimilated into the page output?
Broadly, the (highly simplified) answers are as follows:
1) Extensions now need to think in terms of transformations (convert this
to that) instead of events (at this point in the pipeline, call this
listener). So, more transformation hooks, and less parsing-event hooks.
2) Parsoid provides all registered listeners with a ParsoidExtensionAPI
object to interact with it which extensions can use to process wikitext.
3) The output is treated as a "fully-processed" page/DOM fragment. It is
appropriately decorated with additional markup and slotted into place into
the page. Extensions need not make any special efforts (aka strip state) to
protect it from the parsing pipeline.
In this talk, we will go over the draft Parsoid API for extensions [2] and
the kind of changes that would need to be made. While in this initial
stage, we are primarily targeting extensions that are deployed on the
Wikimedia wikis, eventually, all MediaWiki extensions that use parser hooks
or use the "parser API" to process wikitext will need to change. We hope to
use this talk to reach out to MediaWiki extension developers and get
feedback about the draft API so we can refine it appropriately.
[1] https://phabricator.wikimedia.org/T258838
[2] https://www.mediawiki.org/wiki/Parsoid/Extension_API
The link to the Youtube Livestream can be found here:
<https://www.youtube.com/watch?v=jNNy8ALGjaE>
https://www.youtube.com/watch?v=lS1xPkERWCM
During the live talk, you are invited to join the discussion on IRC at
#wikimedia-office
You can browse past Tech Talks here:
https://www.mediawiki.org/wiki/Tech_talks
If you are interested in giving your own tech talk, you can learn more here:
https://www.mediawiki.org/wiki/Project:Calendar/How_to_schedule_an_event#Te…
Kindly,
Sarah R. Rodlund
Senior Technical Writer, Developer Advocacy
<https://meta.wikimedia.org/wiki/Developer_Advocacy>
srodlund(a)wikimedia.org