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
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! :)
Hi everyone,
I want to notify you that I have, on behalf of the WikiTeq company, made a
task https://phabricator.wikimedia.org/T298277 for requesting repository
ownership for the Lingo extension.
In case that you have any kind of questions, please let me know. :)
Best regards,
Zoran
TLDR: Tech leads please review Best practices for extensions <https://www.mediawiki.org/wiki/Best_practices_for_extensions> on mediawiki.org.
Hi all,
You may be familiar with the Best practices for extensions <https://www.mediawiki.org/wiki/Best_practices_for_extensions> page on mediawiki.org. It has been marked as a draft since 2017.
I'd like to polish this page and get it to a state where it would be uncontroversial to label it as "Development guideline <https://www.mediawiki.org/wiki/Development_guidelines>". This would not make it a hard policy. Neither does it imply that it covers all practices in all situations.
Rather, it would mean that the items that are there now are indeed a part of our current best practices. We would keep it alive through bold <https://en.wikipedia.org/wiki/Wikipedia:Be_bold> edits and talk page conversations, similar to our Coding conventions <https://www.mediawiki.org/wiki/Manual:Coding_conventions/PHP> and other such guidelines that we maintain peer to peer and through consensus.
The reason I've not simply labelled it as such already is because before today I found the document to be out of sync with our actual practices. I have made a number of changes with descriptive edit summaries to bring it in sync with what I percieve to be our best practices; based on how myself and other maintainers perform code review at large, and how we review new extensions prior to deployment.
All are welcome to fix mistakes, raise questions/concerns on the talk page, on this thread. You're also welcome to message me directly anytime if you prefer.
If you consider yourself familiar with our practices and/or lead and mentor other engineers, please take a minute to review the page and consider whether the items reflect your current understanding and judgement.
--
Timo Tijhof,
Principal Engineer,
Wikimedia Performance Team.
Hello everyone,
TLDR; Wikimedia will soon be applying as a mentoring organization to Google
Summer of Code 2022 <https://summerofcode.withgoogle.com> [1] and Outreachy
Round 24 <https://www.outreachy.org/> [2]. We are currently working on a
list of interesting project ideas to include in the application. If you
have some ideas for coding or non-coding (design, documentation,
translation, outreach, research) projects, share them here: <
https://phabricator.wikimedia.org/T299453> [3].
*Timeline*
As a mentor, you will engage potential candidates in the application period
for both programs between March and April. You will help candidates make
small contributions to your project and answer any project-related queries
during this time. You will work more closely with the accepted candidates
during the coding period between May and August.
*New changes are coming to GSoC*
GSoC has exciting changes this year, including:
* Eligibility criteria redefined–the program is now open to all open-source
newcomers 18 years and older. It will no longer be solely focused on
university students or recent graduates.
* Multiple sizes of projects supported–ranging from ~175 to ~350 hr long.
* Increased flexibility in project timing–project deadline can be extended
to up to 22 weeks.
*Tips for proposing projects*
* Follow this task description template when you propose a project in
Phabricator: <
https://phabricator.wikimedia.org/tag/outreach-programs-projects> [4]. Add
#Google- Summer-of-Code (2022) or #Outreachy (Round 24) tag.
* Project should require an experienced developer ~15 days and a newcomer
~3 months to complete.
* Each project should have at least two mentors, and one of them should
hold a technical background.
* Ideally, the project has no tight deadlines, a moderate learning curve,
and fewer dependencies on Wikimedia's core infrastructure. Projects
addressing the needs of a language community are most welcome!
* If you don't have an idea in mind and would like to pick one from an
existing list, check out these projects: <
https://phabricator.wikimedia.org/tag/outreach-programs-projects/> [4]
* To learn more about the roles and responsibilities of mentors, visit our
resources on MediaWiki.org: <
https://www.mediawiki.org/wiki/Outreachy/Mentors> [5], <
https://www.mediawiki.org/wiki/Google_Summer_of_Code/Mentors> [6].
Cheers,
Srishti
[1] https://summerofcode.withgoogle.com
[2] https://www.outreachy.org/
[3] https://phabricator.wikimedia.org/T299453
[4] https://phabricator.wikimedia.org/tag/outreach-programs-projects/
[5] https://www.mediawiki.org/wiki/Outreachy/Mentors
[6] https://www.mediawiki.org/wiki/Google_Summer_of_Code/Mentors
*Srishti Sethi*
Senior Developer Advocate
Wikimedia Foundation <https://wikimediafoundation.org/>
The Search Platform Team
<https://www.mediawiki.org/wiki/Wikimedia_Search_Platform> usually holds an
open meeting on the first Wednesday of each month. Come talk to us about
anything related to Wikimedia search, Wikidata Query Service, Wikimedia
Commons Query Service, etc.!
Feel free to add your items to the Etherpad Agenda for the next meeting.
Details for our next meeting:
Date: Wednesday, February 2nd, 2022
Time: 16:00-17:00 GMT / 08:00-09:00 PST / 11:00-12:00 EST / 17:00-18:00 CET
& WAT
Etherpad: https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours
Google Meet link: https://meet.google.com/vgj-bbeb-uyi
Join by phone: https://tel.meet/vgj-bbeb-uyi?pin=8118110806927
Hope to talk to you next week!
—Trey
Trey Jones
Staff Computational Linguist, Search Platform
Wikimedia Foundation
UTC–5 / EST
This email is a summary of the Wikimedia production deployment of
1.38.0-wmf.19
* Conductor: Brennen Bearnes
* Backup Conductor: Jeena Huneidi
* Blocker Task: T293960 <https://phabricator.wikimedia.org/T293960>
* Current Status <https://versions.toolforge.org>: Stable on all wikis.
📈 By the Numbers
Sparklines comparing with the last 5 trains.
* 319 Patches ▆▁▇▇█
* 1 Rollback ▄▁█▁▂
* 1 Day of delay ▂▂█▁▂
* 18 Blockers ▂▁▂▆█
🌈 Trainbow Love 😻
Thanks to folks who reported or resolved blockers:
* Amir Sarabadani
* Taavi Väänänen
* Zabe
* Legoktm
* Umherirrender
* Bartosz Dziewoński
* Jon Robson
* Urbanecm
* Tyler Cipriani
* Ammarpad
* Lucas Werkmeister (WMDE)
Others no doubt contributed, but there'd be a rather long list of
blockers to parse to figure out who I'm missing.
Additionally, a special thanks to everyone who helped debug T300214 -
'No such file or directory' CI failures in multiple repos
<https://phabricator.wikimedia.org/T300214> in #wikimedia-releng:
* Zabe
* hashar
* bd8080
* James_F
* dancy
* thcipriani
* Amir1
* andrewbogott
* TimStarling
...and anyone else I'm more than likely missing in scrollback.
--
Brennen Bearnes
Release Engineering
Wikimedia Foundation
Hi everyone,
We’re happy to announce the January 2022 edition of the Technical Community
Newsletter <
https://www.mediawiki.org/wiki/Technical_Community_Newsletter/2022/January>.
The newsletter is compiled by the Wikimedia Developer Advocacy Team. It
aims to share highlights, news, and information of interest from and about
the Wikimedia technical community.
The Wikimedia Technical Community is large and diverse, and we know we
can't capture everything perfectly. We would love to hear your ideas for
future newsletters. Let us know what you would like to see or highlights
you would like us to include.
Subscribe to the Technical Community Newsletter
<https://www.mediawiki.org/wiki/Newsletter:Technical_Community_Newsletter>,
if you'd like to keep up with essential updates and information.
Thanks,
Melinda
--
Melinda Seckington
Developer Advocacy Manager
Wikimedia Foundation <https://wikimediafoundation.org/>