Hi! I'm thinking on writing a gadget to add inline comments to articles,
similar to how Google Docs comments work.
However, I'm sure I recently read somewhere about someone developing an
extension or something with the same goal, but now I can't find it
anywhere. Anyone knows?
Thanks!
Hello!
After our initial announcement of the Grid Engine shutdown timeline[0],
some of you raised concerns about losing your tools.
We want to address those apprehensions while hopefully providing
reassurance. No tools will be deleted until the grid engine shutdown date
on 14 February 2023. However, for tools with unreachable maintainers, an
outage will happen starting on 14 December 2023[1]. This is intended to
raise awareness for users or maintainers who have not otherwise been
reached. A list of these tools can be found here[2]. If you are a
maintainer or a user of a tool in this list, comment on the associated
phabricator ticket with migration plans or a request for more support. The
goal is to have a plan for all tools running on the grid. We want all
actively used tools to be migrated, and will help support users of critical
tools without a maintainer. Thanks for your help in identifying and
migrating those tools you maintain and depend on.
We acknowledge that the timeline might seem tight, and we want to clarify
that our approach is to make this process as seamless as possible. We have
been actively engaging with tool maintainers over the past year, and we
genuinely appreciate the efforts many of you have already made to migrate
your tools to Kubernetes.
We will continue to work closely with maintainers who might need additional
time or assistance.
If for any reason you have not received a phabricator ticket for your tool,
please reach out.
The phabricator ticket is a good place to communicate your needs and plans
for any remaining tools or jobs.
This will help us further organize and plan this process.
Our primary goal is to support you through this transition. If you have
further concerns about the deadline or if you need assistance with the
migration process, please don't hesitate to reach out to us. We are
available on IRC, Telegram, Phabricator[3], and through our other support
channels[4].
Do you still have concerns or questions? Please let us know. We want to do
this together with you, in a way which makes sense to everyone. We’re very
grateful for all the hard work you do, and our only goal here is to secure
the future of tools in the Wikimedia sphere, not to make your lives more
difficult.
Thank you!
[0]:
https://lists.wikimedia.org/hyperkitty/list/cloud-announce@lists.wikimedia.…
[1]:
https://wikitech.wikimedia.org/wiki/News/Toolforge_Grid_Engine_deprecation#…
[2]:
https://wikitech.wikimedia.org/wiki/News/Toolforge_Grid_Engine_deprecation/…
[3]: https://phabricator.wikimedia.org/project/board/6135/
[4]:
https://wikitech.wikimedia.org/wiki/Portal:Toolforge/About_Toolforge#Commun…
--
Seyram Komla Sapaty
Developer Advocate
Wikimedia Cloud Services
Recently I completed initial work to enable commit-message-validator
[0] to work with GitLab CI and GitLab merge requests. For those who
are unaware, commit-message-validator is a linter tool designed to
enforce Wikimedia's commit message guidelines. [1]
Soon after the feature was available, James Forrester added it to the
test suite for abstract-wiki/wikifunctions/function-orchestrator [2]
and found the first issue with the integration that I had not
anticipated which he helpfully filed as T351253. [3]
In my estimation, the problem comes down to a question of whether we
should prioritize reading commit message footer information nicely in
GitLab's merge request interface where they are rendered as GitLab
flavored markdown data or not. James' team has developed a convention
of appending a backslash (\) after footer lines so that they render as
individual lines when processed as markdown. This in turn leads to
commit-message-validator rejecting some footers, most obviously "Bug:
Tnnnn" footers, for having unwanted characters (the trailing " \").
Reasonable people can disagree on the "best" solution here, but I
think it is likely that as a group we can reach consensus on what the
proper behavior of the commit-message-validator tool should be. The
most obvious options are:
* Change nothing in commit-message-validator and suggest folks live
with markdown rendering artifacts in GitLab merge request
descriptions.
* Change commit-message-validator to allow trailing " \" data for
commit message footers in GitLab repos.
* Change commit-message-validator to allow users (typically a CI
process) to configure allow/disallow of trailing " \" data for commit
message footers
Adding support for per-repo rules configuration would be a first for
commit-message-validator. Until now it has provided a single
opinionated ruleset based on interpretation of the commit message
guidelines. [2]
Folks who actually care about this minutia (how git commit message
footers look in and out of GitLab markdown rendering) are encouraged
to think carefully and provide their opinions and supporting data on
T351253. [3]
[0]: https://www.mediawiki.org/wiki/Commit-message-validator
[1]: https://www.mediawiki.org/wiki/Gerrit/Commit_message_guidelines
[2]: https://gitlab.wikimedia.org/repos/abstract-wiki/wikifunctions/function-orc…
[3]: https://phabricator.wikimedia.org/T351253
Bryan
--
Bryan Davis Wikimedia Foundation
Principal Software Engineer Boise, ID USA
[[m:User:BDavis_(WMF)]] irc: bd808
Hi there,
I'm User:Diskdance, and recently I'm developing a default gadget for Chinese Wikipedia enhancing MediaWiki's variant handling logic, and under certain circumstances a prompt is shown at page load asking for a user's preferred variant. Consider it as a conditional Cookie notice, and its English screenshot can be found at https://commons.wikimedia.org/wiki/File:VariantAlly-En.png.
Iknowthis can be very disruptive on UX, so I tend to be careful about its negative impact on page views. If the gadget can collect telemetry data about the prompt's display frequency and user interactions(using e.g. WikimediaEvents), I can know about its possible impact.
Is this possible? It would be much appreciated if anybody could provide assistance.
Best wishes,Diskdance
Hello!
Please take the December 2023 Developer Satisfaction Survey!
Link: <https://wikimediafoundation.limesurvey.net/484133>
https://wikimediafoundation.limesurvey.net/796964
The survey is open until Fri, 5 January 2024—four weeks from today.
____
This survey is for members of the Wikimedia developer community and covers
the following topics:
-
Wikimedia Cloud Services
-
Development and testing environments
-
Phabricator
-
Code review
-
Continuous Integration
-
Deployment
-
Code quality
-
Technical documentation
-
Developer research needs
Please take the survey if you play a role in developing software for the
Wikimedia ecosystem and would like to share your opinions on any of the
topics listed above.
We’re soliciting your feedback to:
- Measure developer satisfaction, and
- determine where to invest resources in the future
We will anonymize, explore, and report the data we gather on mediawiki.org.
View previous years' survey results:
https://www.mediawiki.org/wiki/Developer_Satisfaction_Survey
Privacy statement: This survey will be conducted via a third-party service,
which may subject it to additional terms. For more information on privacy
and data-handling, see the privacy statement.
<https://foundation.wikimedia.org/wiki/Legal:December_2023_Developer_Satisfa…>
Thank you!
Tyler Cipriani (he/him)
Engineering Manager, Release Engineering
Wikimedia Foundation
Hi everyone,
tl;dr The tools we use to document Wikimedia JavaScript code are changing.
In the short term, you can read the complete MediaWiki core JavaScript docs
using the 1.41 version[0] while we migrate to the new system[1]. If you use
JavaScript documentation on doc.wikimedia.org, please share your feedback
on wiki[2].
Wikimedia JavaScript codebases are switching from using JSDuck[3] to
JSDoc[4] for documentation. Started in 2016, this migration is necessary
because JSDuck is currently unmaintained and does not support the ES6
standard[5]. Several Wikimedia JavaScript codebases, including Vector and
GlobalWatchlist, already use JSDoc, while several others, such as
VisualEditor and MediaWiki core, still use JSDuck.
The migration project consists of two parts: changing the codebases to
support JSDoc and improving the usability of the JSDoc WMF theme. For more
information, see phab:T138401[6].
== Migrating MediaWiki core to JSDoc ==
We are migrating MediaWiki core to JSDoc incrementally. While the migration
is in progress, the master branch docs will be incomplete, containing only
those modules that have been migrated. To read the old JSDuck docs, see the
MediaWiki 1.41 docs[0].
To help with migration, choose a module from the list in phab:T352308[7],
and follow the guide on phab:T138401[6] to translate the tags from JSDuck
to JSDoc.
== Migrating other codebases ==
You can find a list of codebases that use JSDuck on phab:T138401[6].
(Please add any that are missing.) To help migrate a codebase that uses
JSDuck, follow the instructions to set up JSDoc[8], and use the guide in
phab:T138401[6] to translate the tags from JSDuck to JSDoc.
== Improving the JSDoc WMF theme ==
One of the biggest differences between JSDuck and JSDoc is the HTML
interface for reading the docs. The WMF theme for JSDoc is not as
full-featured as the JSDuck theme, but to support this migration, the
Wikimedia Foundation Web, Design Systems, and Technical Documentation teams
are working to prioritize and complete a set of improvements to the JSDoc
theme, with the goal of releasing version 1 of jsdoc-wmf-theme in 2024.
If you use JavaScript documentation on doc.wikimedia.org, please leave a
comment on the JSDoc WMF theme talk page[2] and let us know how you use the
docs and which features of the theme are the most important to you.
Thank you for reading!
Alex, Kamil, Jon, Roan, and Anne
[0]: https://doc.wikimedia.org/mediawiki-core/REL1_41/js/
[1]: https://doc.wikimedia.org/mediawiki-core/master/js/
[2]: https://www.mediawiki.org/wiki/Talk:JSDoc_WMF_theme
[3]: https://github.com/senchalabs/jsduck
[4]: https://en.wikipedia.org/wiki/JSDoc
[5] https://en.wikipedia.org/wiki/ECMAScript
[6]: https://phabricator.wikimedia.org/T138401
[7]: https://phabricator.wikimedia.org/T352308
[8]: https://www.mediawiki.org/wiki/JSDoc
--
Alex Paskulin
Technical Writer
Wikimedia Foundation
Hello all!
The Search Platform Team 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 (WDQS), Wikimedia Commons Query
Service (WCQS), etc.!
Feel free to add your items to the Etherpad Agenda for the next meeting.
Details for our next meeting:
Date: Wednesday, December 6, 2023
Time: 16:00-17:00 UTC / 08:00 PDT / 11:00 EDT / 17:00 CEST
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
Have fun and see you soon!
Guillaume
--
*Guillaume Lederrey* (he/him)
Engineering Manager
Wikimedia Foundation <https://wikimediafoundation.org/>
Hi all,
I have asked for +2 access to the PageTriage extension
<https://mediawiki.org/wiki/Extension:PageTriage> to be able to participate
in reviewing code contributions made to the repository :) Please share any
comments at https://phabricator.wikimedia.org/T351972
Regards,
Sohom Datta
---
Open-source contributor @Wikimedia, (and sometimes @Chromium)
