Hi all!
If you've never created a repo or fork on the Wikimedia GitHub
organization you can skip this email.
I know that some repos are developed on our GitHub org for reasons.
What is developed on our GitHub org? How many things are actively
being developed on GitHub org? I have no idea :)
I recently realized that there's not a great way to figure this
out[0], but I've been able to narrow the scope a bit. Now I have a
list of repos that are (a) in our GitHub org and (b) not in our Gerrit
that I could use some help sorting through[1].
== Help, please ==
* Look through repos on The List™[1]
If your repos are on the list, for each of your repos either:
* Archive or Delete it if it's no longer maintained or empty/useless,
respectively (and remove them from the list on mw.org)[2]
Or:
* put a "{{tick}}" in the "Active" column on the list on mw.org
== Why==
In a more perfect future we could add the "mirror"[3] tag to repos on
GitHub that are mirrored from Gerrit (with a link to their canonical
repo locations; for example, gnome-deskop has this[4] and I'm very
jealous).
Hopefully, this will help folks wanting to contribute -- either a
Wikimedia GitHub repo is a mirror (in which case there's a link to
Gerrit in the description) or it's actively being developed on GitHub.
<3
-- Tyler
[0]: <https://phabricator.wikimedia.org/T237470#6407509>
[1]: <https://www.mediawiki.org/wiki/Gerrit/GitHub#Projects_on_GitHub>
[2]: <https://docs.github.com/en/github/creating-cloning-and-archiving-repositori…>
[3]: <https://docs.github.com/en/github/getting-started-with-github/finding-ways-…>
[4]: <https://github.com/GNOME/gnome-desktop>
This is a request for granting merge privileges on the mediawiki group
(MediaWiki core and all extensions) per the gerrit privilege policy.
You can find the relevant ticket at <https://phabricator.wikimedia.org/T261656>.
Martin Urbanec is a long term contributor, both on the wikis and to the code
base. As a Steward, he has the trust of the community. His contributions in code
include improvements to extensions like OATHAuth and CentralAuth. He is also
helping with decoupling classes in core to improve code health, and provides
configuration patches on behalf of the community.
Martin has been particularly helpful in investigating and fixing a recent
security issue (T260485). Working with him on that, I was surprised to find out
that he doesn't have +2 rights. From what I have seen, it seems empowering him
to merge patches is long overdue.
Gerrit: https://gerrit.wikimedia.org/r/q/owner:martin.urbanec%2540wikimedia.cz
Wikipiedia: https://cs.wikipedia.org/wiki/Wikipedista:Martin_Urbanec
--
Daniel Kinzler
Principal Software Engineer, Core Platform
Wikimedia Foundation
Hi all!
This is the weekly TechCom board review in preparation of our meeting on
Wednesday. If there are additional topics for TechCom to review, please let us
know by replying to this email. However, please keep discussion about individual
RFCs to to the phabricator tickets.
Activity since Monday 2020-08-26 on the following boards:
https://phabricator.wikimedia.org/tag/techcom/https://phabricator.wikimedia.org/tag/techcom-rfc/
Committee inbox: none
Committee board activity:
* Added "Parsoid Extension API" (T260714), see below.
New RFCs: none
Phase progression: none
IRC meeting request: none
Other RFC activity:
* Drop support for database upgrade older than two LTS releases:
<https://phabricator.wikimedia.org/T259771>
- Leaderboard suggests to support 3 LTS releases
- Bawolff says that upgrades from versions as old as 1.16 are common enough,
but that we should drop support for anything older than 1.6.
* Parsoid Extension API:
<https://phabricator.wikimedia.org/T260714>
- Subbu wrote in response to las week's digest email that they are looking for
feedback "not from users, but TechCom" and "if TechCom is happy with it, it
can go to Last Call."
- DISCUSS: should we move this to last call?
--
Daniel Kinzler
Principal Software Engineer, Core Platform
Wikimedia Foundation
Hi everyone,
do you usually find all the technical documentation you are looking
for? Yes? Great! For everyone else, this email is an early heads-up
announcement about the idea to create a Wikimedia Developer Portal. :P
For more info (that's currently only the problem definition, goal,
scope, and past research, hence "idea" and not yet "plan"):
https://www.mediawiki.org/wiki/Developer_Advocacy/Developer_Portal
If you have thoughts and opinions, please share them on the wiki
discussion page! Please focus comments on the current sections on the
page, as it is not the time yet to discuss content categorization or
implementation details - that will happen later in the process.
More info to come when things are a bit more worked out.
Thanks & Cheers,
andre
--
Andre Klapper (he/him) | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/
Dear Wikitech-l,
As TechCom (Wikimedia Technical Committee) we triage and review our Phabricator
boards, #techcom and #techcom-rfc, for activity. We also have a weekly meeting
in which the board triage and other topics are discussed. A short summary of
this meeting is published to mediawiki.org and on Wikitech-l, as part TechCom Radar.
In an effort to encourage wider and less formal participation through Wikitech-l
(and to make our process more asynchronous) we'll also write to Wikitech-l as
part of the board triage going forward. You may already have seen the first
board grooming mail here a couple of days ago. We are also expanding the TechCom
Radar to (once again) include our meeting minutes. Please feel free to join the
conversation!
Here are the minutes from our meeting on Wednesday:
Present: Daniel K, Tim S, Giuseppe L, Timo T, Dan A, Roan K.
== New link service ==
*
https://www.mediawiki.org/wiki/Growth/Personalized_first_day/Structured_tas…
* Guiseppe: Showing suggested links for editors using ML. How do we store ML
models in production, update them?
* Dan: isn’t this the purview of Chris’s ML infrastructure team?
* Giuseppe: long-term, yes, but not directly their responsibility right now. The
general architectural issue is: we want a sustainable way to generate ML
models, and ship them to applications using them. This process should be
streamlined - the current pattern of slapping the models in git-lfs is not
sustainable long-term.
* Roan: explains about the project, a collaboration with Research to suggest
links to add to articles. Docs/write-ups are emerging (and more focused on
UX)
* Daniel: Create an RFC?
== Upcoming datacenter switchover ==
* https://wikitech.wikimedia.org/wiki/Switch_Datacenter
* Next week, Tue 1 Sept, 14:00 UTC.
== RFC: New API for Parsoid extensions ==
* https://phabricator.wikimedia.org/T260714
* Daniel: Should it go on last call?
* Tim: no urgency to closing this. The review they’re asking for hasn’t been
done yet.
* Timo: They’ve done a fair bit of research and outreach offline prior to the
RFC. They’re looking for explicit approval from would-be users of their new
API for parser extensions. Once that completes, they should ask for Last Call.
== Shell execute microservice ==
* https://phabricator.wikimedia.org/T260330
* Tim: New initiative being started by Platform Engineering.
Will turn into an RFC.
* Tim: Affects every shell execution, can be used in small/medium wiki instances
that aren’t hosted by WMF, seems cross-cutting, affects over 30 extensions.
You can also find our meeting minutes at
<https://www.mediawiki.org/wiki/Wikimedia_Technical_Committee/Minutes>
If you prefer you can subscribe to our newsletter here
<https://www.mediawiki.org/wiki/Newsletter:TechCom_Radar>
--
Daniel Kinzler
Principal Software Engineer, Core Platform
Wikimedia Foundation
Hello all,
I hope that this is the right list to ask about Mailman's admin options, if
not, let me know where I should ask :)
I'm looking for someone to help me with the config of a mailing-list, to
reactivate the semi-automated spam filter.
I'm one of the admins on the Wikidata mailing-list. A while ago, to prevent
my newsletter to be considered as spam because it included too many links,
I changed something in the config of the mailing-list, I don't remember
exactly what, but it was about not filtering spam for the admins anymore,
and sending each single spam email (or emails from non-registered users) to
the ML owners. Since then we end up with tons of emails in our mailboxes
everyday. I tried to reactivate this "pre-filter" feature, but I can't
remember where it is and how to do it right.
Does anyone have a clue about how to fix this? Thanks in advance :)
--
Léa Lacroix
Project Manager Community Communication for Wikidata
Wikimedia Deutschland e.V.
Tempelhofer Ufer 23-24
10963 Berlin
www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
Hello everyone,
Wikimedia is participating in the winter edition of this year's Outreachy <
https://www.outreachy.org/> [1] (December 2020–February 2021) and plans to
mentor ~6 interns! The deadline to submit projects on the Outreachy website
is September 24th, 2020.
This round will be a bit different for Wikimedia–we are considering keeping
the focus of projects on data science and engineering. We hope that with a
particular theme, interns will have more opportunities to interact with and
support each other, and in turn, they will have a more fulfilling
experience! For example, a project could be to analyze publicly available
Wikimedia datasets to create valuable tools that can help perform vital
tasks or generate insights that help make data-informed decisions. A
project's nature could be coding or non-coding (documentation, design,
research, outreach, translation, etc.). Though we plan to prefer the
projects related to the theme, we still encourage you to reach out if you
have other ideas.
If you would like to share an idea for a project that you would like to
mentor or you are not familiar with the program and want to learn anything
more about it, feel free to reply to this email or leave a note on <
https://phabricator.wikimedia.org/T258524> [2].
About the Outreachy program:
Outreachy offers three-month internships to work remotely in Free and Open
Source Software (FOSS), coding and non-coding projects with experienced
mentors. These internships run twice a year–from May to August and December
to March. Interns are paid a stipend of USD 5,500 for the three months of
work. They also have a USD 500 stipend to travel to conferences and events.
Interns often find employment after their internship with Outreachy
sponsors or jobs that use the skills they learned during their internship.
This program is open to both students and non-students. Outreachy expressly
invites the following people to apply:
- Women (both cis and trans), trans men, and genderqueer people.
- Anyone who faces under-representation, systematic bias, or
discrimination in the technology industry in their country of residence.
- Residents and nationals of the United States of any gender who are
Black/African American, Hispanic/Latinx, Native American/American Indian,
Alaska Native, Native Hawaiian, or Pacific Islander.
See a blog post highlighting one of our intern's experience participating
in Outreachy program with Wikimedia <
https://techblog.wikimedia.org/2020/08/26/lalithas-story-an-outreachy-inter…>
[3]
Some tips for mentors 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 #Outreachy (Round 21) tag to it.
- Remember, the project should require an experienced developer ~15 days
to complete and a newcomer ~3 months.
- Each project should have at least two mentors, and one of them should
hold a technical background.
- When it comes to picking a project, you could propose one that is:
- Relevant for your language community or brings impact to the
Wikimedia ecosystem in the future.
- Welcoming and newcomer-friendly and has a moderate learning curve.
- A new idea you are passionate about, there are no deadlines
attached to it; you always wanted to see it happen but couldn't
due to lack
of resources help!
- About developing a standalone tool (possibly hosted on Wikimedia
Toolforge), with fewer dependencies on Wikimedia's core
infrastructure, it
doesn't necessarily require a specific programming language.
- See roles and responsibilities of an Outreachy mentor <
https://www.mediawiki.org/wiki/Outreachy/Mentors> [5].
We look forward to your participation!
Cheers,
Wikimedia organization admins for Outreachy
(Pavithra, Gopa, and Srishti)
[1] https://www.outreachy.org/
[2] https://phabricator.wikimedia.org/T258524
[3]
https://techblog.wikimedia.org/2020/08/26/lalithas-story-an-outreachy-inter…
[4] https://phabricator.wikimedia.org/tag/outreach-programs-projects/
[5] https://www.mediawiki.org/wiki/Outreachy/Mentors
*Srishti Sethi*
Senior Developer Advocate
Wikimedia Foundation <https://wikimediafoundation.org/>
Hello,
This email contains updates for August 26th, 2020, for the HTML version,
see: https://www.mediawiki.org/wiki/Scrum_of_scrums/2020-08-26
Cheers,
Deb
------------------------
*= 2020-08-26 =*
== Callouts ==
* '''Data Centre Switch''' The Wikimedia Foundation will be testing its
secondary data centre. This will make sure that Wikipedia and the other
Wikimedia wikis can stay online even after a disaster. To make sure
everything is working, the Wikimedia Technology department needs to do a
planned test. This test will show if they can reliably switch from one
datacenter to the other. It requires many teams to prepare for the test and
to be available to fix any unexpected problems. They will switch all
traffic to the secondary data centre on Tuesday, September 1st 2020. More
information:
https://lists.wikimedia.org/pipermail/wikitech-ambassadors/2020-August/0023…
* '''No train next week''' There is a planned switchover to our secondary
datacenter scheduled for Tuesday, September 2nd 2020. To avoid creating
problems for our SREs we'll be skipping the train for next week -- the week
of 2020-08-31 -- and not doing any deployments the day of the switchover --
2020-09-01.
* '''scap sync now called scap sync-world''' There is a new release of Scap
(3.15.0), which will be installed on the various servers next week. More
information:
https://lists.wikimedia.org/pipermail/wikitech-l/2020-August/093749.html.
== Technology ==
==== Release Engineering ====
* Blocked by:
** none
* Blocking:
** none
* Updates:
** [All] Deployments/Covid-19
https://wikitech.wikimedia.org/wiki/Deployments/Covid-19
** Train Health
*** Last week: 1.36.0-wmf.5 - [[phab:T257973]]
*** This week: 1.36.0-wmf.6 - [[phab:T257974]]
*** Next week: No Train
** [All] Review guidance at
https://wikitech.wikimedia.org/wiki/Deployments/Covid-19 and Code
Deployment Office Hour at 17:00UTC in #wikimedia-office
** "scap sync" will be renamed to "scap sync-world" in the next release. If
you use "scap sync" non-interactively, please add a note to:
https://phabricator.wikimedia.org/T250302 (and also, explain why you're
using it)
** scap sync now has option --canary-wait-time;
https://phabricator.wikimedia.org/T217924
** No train week of 2020-08-31; no deploys 2020-09-01 (mentioned in
callouts as well)
--
deb tankersley (she/her)
sr program manager, engineering
Wikimedia Foundation