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! :)
> So where is the best current place to discuss scaling Commons, and all
that entails?
My impression is that we don't have one. All we hear is "it needs to be
planned", but there is no transparency on what that planning involves or
when it actually happens.
> I'd be surprised if the bottleneck were people or budget
The main problem I see is that we end up in this kind of situation. Scaling
and bug fixing critical features should be part of the annual budget. Each
line of code deployed to production wikis should have an owner and
associated maintenance budget each year. Without this, the team will not
even commit reviews - see the thread on wikitech a few months back where a
volunteer programmer willing to work on Upload Wizard was basically told
"We will not review your code. Go fork."
> Some examples from recent discussions
Also improvements to the Upload Wizard. There are quite a few open items in
Phab on this.
I really hope you will have better luck than others with bringing this
issue up in the priority list for next year - multimedia support is growing
more outdated by the minute.
Strainu
Pe joi, 30 decembrie 2021, Samuel Klein <meta.sj(a)gmail.com> a scris:
> Separate thread. I'm not sure which list is appropriate.
> ... but not all the way to sentience.
>
> The annual community wishlist survey (implemented by a small team,
possibly in isolation?) may not be the mechanism for prioritizing large
changes, but the latter also deserves a community-curated priority queue.
To complement the staff-maintained priorities in phab ~
> For core challenges (like Commons stability and capacity), I'd be
surprised if the bottleneck were people or budget. We do need a shared
understanding of what issues are most important and most urgent, and how to
solve them. For instance, a way to turn Amir's recent email about the
problem (and related phab tickets) into a family of persistent,
implementable specs and proposals and their articulated obstacles.
> An issue tracker like phab is good for tracking the progress and
dependencies of agreed-upon tasks, but weak for discussing what is
important, what we know about it, how to address it. And weak for
discussing ecosystem-design issues that are important and need persistent
updating but don't have a simple checklist of steps.
> So where is the best current place to discuss scaling Commons, and all
that entails? Some examples from recent discussions (most from the wm-l
thread below):
> - Uploads: Support for large file uploads / Keeping bulk upload tools
online
> - Video: Debugging + rolling out the videojs player
> - Formats: Adding support for CML and dozens of other common high-demand
file formats
> - Thumbs: Updating thumbor and librsvg
> - Search: WCQS still down, noauth option wanted for tools
> - General: Finish implementing redesign of the image table
>
> SJ
> On Wed, Dec 29, 2021 at 6:26 AM Amir Sarabadani <ladsgroup(a)gmail.com>
wrote:
>>
>> I'm not debating your note. It is very valid that we lack proper support
for multimedia stack. I myself wrote a detailed rant on how broken it is
[1] but three notes:
>> - Fixing something like this takes time, you need to assign the budget
for it (which means it has to be done during the annual planning) and if
gets approved, you need to start it with the fiscal year (meaning July
2022) and then hire (meaning, write JD, do recruitment, interview lots of
people, get them hired) which can take from several months to years. Once
they are hired, you need to onboard them and let them learn about our
technical infrastructure which takes at least two good months. Software
engineering is not magic, it takes time, blood and sweat. [2]
>> - Making another team focus on multimedia requires changes in planning,
budget, OKR, etc. etc. Are we sure moving the focus of teams is a good
idea? Most teams are already focusing on vital parts of wikimedia and
changing the focus will turn this into a whack-a-mole game where we fix
multimedia but now we have critical issues in security or performance.
>> - Voting Wishlist survey is a good band-aid in the meantime. To at
least address the worst parts for now.
>>
>> I don't understand your point tbh, either you think it's a good idea to
make requests for improvements in multimedia in the wishlist survey or you
think it's not. If you think it's not, then it's offtopic to this thread.
>> [1]
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org…
>> [2] There is a classic book in this topic called "The Mythical Man-month"
>>
>> On Wed, Dec 29, 2021 at 11:41 AM Gnangarra <gnangarra(a)gmail.com> wrote:
>>>
>>> we have to vote for regular maintenance and support for
essential functions like uploading files which is the core mission of
Wikimedia Commons
I am pleased to announce that Wikimedia Enterprise's HTML dumps [1] for
October 17-18th are available for public download; see
https://dumps.wikimedia.org/other/enterprise_html/ for more information. We
expect to make updated versions of these files available around the 1st/2nd
of the month and the 20th/21st of the month, following the cadence of the
standard SQL/XML dumps.
This is still an experimental service, so there may be hiccups from time to
time. Please be patient and report issues as you find them. Thanks!
Ariel "Dumps Wrangler" Glenn
[1] See https://www.mediawiki.org/wiki/Wikimedia_Enterprise for much more
about Wikimedia Enterprise and its API.
Hello cloud-vps users,
There are still about 84 unclaimed projects at
https://wikitech.wikimedia.org/wiki/News/Cloud_VPS_2021_Purge
Please take a moment to look at that page and mark projects that you are
using.
Unclaimed projects will be in danger of shutdown on February 1st, 2022.
Thank you to those of you who have already acted on this.
Thank you!
- Komla
-------- Forwarded Message --------
Subject: Cloud VPS users, please claim your projects (and, introducing
Komla)
Date: Thu, 2 Dec 2021 14:42:08 -0600
From: Andrew Bogott <abogott(a)wikimedia.org> <abogott(a)wikimedia.org>
Reply-To: abogott(a)wikimedia.org
Organization: The Wikimedia Foundation
To: Cloud-announce(a)lists.wikimedia.org
CC: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
<wikitech-l(a)lists.wikimedia.org>
Hello cloud-vps users!
It's time for our annual cleanup of unused projects and resources. Our new
developer advocate Komla Sapaty will be guiding this process; please
respond promptly to his emails and do your best to make him feel welcome!
Every year or so the Cloud Services team tries to identify and clean up
unused projects and VMs. We do this via an opt-in process: anyone can mark
a project as 'in use,' and that project will be preserved for another year.
I've created a wiki page that lists all existing projects, here:
https://wikitech.wikimedia.org/wiki/News/Cloud_VPS_2021_Purge
If you are a VPS user, please visit that page and mark any projects that
you use as {{Used}}. Note that it's not necessary for you to be a project
admin to mark something -- if you know that you're currently using a
resource and want to keep using it, go ahead and mark it accordingly. If
you /are/ a project admin, please take a moment to mark which VMs are or
aren't used in your projects.
When February arrives, I will shut down and begin the process of reclaiming
resources from unused projects.
If you think you use a VPS project but aren't sure which, I encourage you
to poke around on https://tools.wmflabs.org/openstack-browser/ to see what
looks familiar. Worst case, just email cloud(a)lists.wikimedia.org with a
description of your use case and we'll sort it out there.
Exclusive toolforge users are free to ignore this email and future related
things.
Thank you!
-Andrew and the WMCS team
Hi, I have written a set of scripts to use MediaWiki as a static site generator and am writing this mail to inform those who are interested in it.
The tool, ThisIsNotAWiki depends on Docker and the MediaWiki's file caching.
A docker container would launch an actual MediaWiki instance, import wikitext files, and generate HTML files when ThisIsNotAWiki runs.
Unlike other static site generators that support Wikitext, ThisIsNotAWiki uses the same engine as real wikis,
therefore all syntax is available, and skins and extensions can be enabled separately as needed. [1]
The tool is currently still in its infancy and it's why I prepended PoC on the title.
You can visit the repository on Github [2] or the project site [3] which was generated by the tool itself for details.
Thanks,
Lens0021
[1]: It now only supports the bundled extensions/skins.
[2]: https://github.com/lens0021/this-is-not-a-wiki
[3]: https://lens0021.github.io/this-is-not-a-wiki/