Hi,
I would like to uhhh... start the discussion? ask for opinions? about the
future of UploadWizard.
It is a rather special extension, that was from the start made mostly for
Commons' very specific needs and getting it to work anywhere else presents
some challenges (some of which I attempt to tackle here
<https://phabricator.wikimedia.org/T256616>). Interestingly, it still is
used by many third-party wikis
<https://wikiapiary.com/wiki/Extension:Upload_Wizard> and although some of
them don't need its full set of capabilities related to describing
licenses, authors and sources, there are wikis that do need that. The wiki
I maintain, Nonsensopedia, has a Commons-like file description system based
on Semantic MediaWiki (see example here
<https://nonsa.pl/wiki/Plik:Creative_Commons_evolution.jpg>) and
UploadWizard has been a *blessing* for us, greatly simplifying the task of
file moderation.
Opinion time: Wikis should be *encouraged* to properly describe the
authorship of files that they use, to meet the licensing requirements. IMO
Wikimedia Foundation as the maintainer of MediaWiki and a foundation
dedicated to dissemination of free culture should provide a usable tool for
properly describing free multimedia. UploadWizard could be just that.
At the same time, the extension has been basically unmaintained
<https://phabricator.wikimedia.org/T261589#6674315> since the Multimedia
team was dissolved and I've been rather surprised to discover that patches
improving third-party support were met with uhm... very limited enthusiasm?
<https://phabricator.wikimedia.org/T256616#6264584> There are a few obvious
features lacking like mobile support (seriously, try opening
https://commons.wikimedia.org/wiki/Special:UploadWizard on a narrow screen
device, it's been like this since.. always) and configurability (you have
to jump through some serious hoops
<https://www.mediawiki.org/wiki/Topic:V2at02b7oxy5pkwl> to just add a
license; customizing the tutorial is similarly hard).
I've been thinking of what to do with the above and I really wouldn't want
to embark on something that will be rendered redundant or obsolete in a
year, so my question is: are there any plans for UploadWizard? What makes
me suspect that things may change is primarily Structured Data on Wikimedia
Commons, which in the future will maybe (?) supersede the description
system around the {{Information}} template. Are there any rough roadmaps or
outlines of anything resembling a plan for that? If Commons was to
implement full, structured file descriptions in the upload tool, that code
would be probably hardly usable outside Commons, given that Wikibase is not
something easy to install or maintain, it is also awfully overkill for the
vast majority of applications. In such a situation, would it make sense to
consider completely separating the "Wikimedia Commons Shiny Upload Tool"
from a more general extension that would be usable for third
parties, stripped of any Commons-specific code? A lot of things could be
much simplified if the extension was to target just the needs of third
parties and not Commons.
I ask about this because I really don't see any sort of interest of the
extension's *de facto* owner (and that is WMF) in developing it, there are
also no public plans for it, as far as I know. Yes, I can make a fork
anytime, but first I'd prefer to know if I'm not missing something. Well,
actually, I already did make a fork of UW
<https://gitlab.com/nonsensopedia/extension-forks/uploadwizard-nonsa> over
a year ago, but this particular version of it is tailored for a wiki I
manage, making it useless for others. At the time that was the only
reasonable way we could get a good upload tool that was capable of properly
describing licensing information. I probably don't have to tell seasoned
open-source developers why this type of approach is not optimal for the
future of the project. :)
Any opinions on the topic are very welcome.
--
Ostrzyciel (he/him)
How’d we do in our strive for operational excellence last month? Read on to
find out!
Read on Phabricator at https://phabricator.wikimedia.org/phame/post/view/227
📈 Incidents
1 documented incident last month. That's the third month in a row that we
are at or near zero major incidents – not bad! [1] [2]
Learn about recent incidents at Incident status
<https://wikitech.wikimedia.org/wiki/Incident_status> on Wikitech, or
Preventive
measures <https://phabricator.wikimedia.org/project/view/4758/> in Phabric
ator.
💡 *Did you know: Our Incident status
<https://wikitech.wikimedia.org/wiki/Incident_status> page provides a
green-yellow status reflection over the past ten days, with a link to the
most recent incident doc if there was any during that time.*
-------
📊 Trends
This January saw a small recovery in our otherwise negative upward trend.
For the first time in twelve month more reports were closed than new
reports having outlived the previous month without resolution. What
happened twelve months ago? That January 2020, which also saw a small
recovery during the otherwise upward trend before and after it.
Perhaps its something about the post-December holidays that temporarily
improves the quality and/or reduces the quantity — of code changes. Only
time will tell if this is the start of a new trend, or merely a
post-holiday dip. [3]
While our month-to-month trend might not (yet) be improving, we do see
persistent improvements in our overall backlog of pre-2019 reports. This is
in part because generally don't file new reports there, so it makes sense
that it doesn't go up, but it's still good to see downward progress every
month, unlike with reports from more recent months which often see no
change month-to-month (see "Outstanding errors" below, for example).
This positive trend on our "Old" backlog started in October 2020 and has
consistently progressed every month since then (refer to the "Old" numbers
in red on the below chart, or the same column in the spreadsheet
<https://docs.google.com/spreadsheets/d/1tRCh8aB0UYyLlhftvcHvhWH4-e7cF5V01Xv…>.
[3][4]
Figure 1, Figure 2: Unresolved error reports stacked by month.
<https://phabricator.wikimedia.org/phame/post/view/227/production_excellence…>
-------
📖 Outstanding errors
Summary over recent months:
- ⚠️ July 2019 (2 of 18 issues left): *no change*.
- ⚠️ August 2019 (1 of 14 issues): *no change*.
- ✅ September 2019 (0 of 12 issues): Last two tasks were resolved (-2).
- ⚠️ October 2019 (4 of 12 issues): One task resolved (-1).
- ⚠️ November 2019 (1 of 5 issues): *no change*.
- ⚠️ December 2019 (2 of 9 issues), Two tasks resolved (-2).
- ⚠️ January 2020 (2 of 7 issues), no change.
- ⚠️ February 2020 (1 of 7 issues left), One task resolved (-1).
- March 2020 (2 of 2 issues left), no change.
- April 2020 (9 of 14 issues left): *no change*.
- May 2020 (6 of 14 issues left): One task resolved (-1).
- June 2020 (7 of 14 issues left): *no change*.
- July 2020 (9 of 24 new issues
<https://phabricator.wikimedia.org/maniphest/query/s__D8Kd0xuQH/#R>): *no
change*.
- August 2020 (22 of 53 new issues
<https://phabricator.wikimedia.org/maniphest/query/hu1yhWu4sXkP/#R>):
One task resolved (-1).
- September 2020 (13 of 33 new issues
<https://phabricator.wikimedia.org/maniphest/query/CGFQViLShnOY/#R>):
One task resolved (-1).
- October 2020 (31 of 69 new issues
<https://phabricator.wikimedia.org/maniphest/query/MYnnBybPTYpd/#R>):
Four tasks fixed (-4).
- November 2020 (14 of 38 new issues
<https://phabricator.wikimedia.org/maniphest/query/CkC_VqQq5VC0/#R>): *no
change*.
- December 2020 (19 of 33 new issues
<https://phabricator.wikimedia.org/maniphest/query/10NQy74iKaZJ/#R>)
Three tasks resolved (-3)
- *January 2021*: 7 of 50 new issues
<https://phabricator.wikimedia.org/maniphest/query/WIP9W8q54HB6/#R>
survived the month and remained unresolved (+50; -43)
Recent tally
160 issues open, as of Excellence #27
<https://phabricator.wikimedia.org/phame/post/view/219/production_excellence…>
(4 Feb 2021).
-15 issues closed since, of the previous 160 open issues.
+7 new issues that survived January 2021.
152 issues open, as of today (16 Feb 2021).
January saw +50 new production errors reported in a single month, which is
an unfortunate all-time high. However, we've also done remarkably well on
addressing 43 of them within a month, when the potential root cause and
diagnostics data are still fresh in our minds. Well done!
For the on-going month of February, there have been 16 new issues
<https://phabricator.wikimedia.org/maniphest/query/xjFr73QLJYlE/#R>
reported so far.
Take a look at the workboard
<https://phabricator.wikimedia.org/tag/wikimedia-production-error/> and
look for tasks that could use your help!
-------
🎉 Thanks!
Thank you to everyone else who helped by reporting, investigating, or
resolving problems in Wikimedia production. Thanks!
Until next time,
– Timo Tijhof
-------
Footnotes:
[1] Incident status Wikitech
<https://wikitech.wikimedia.org/wiki/Incident_status>.
[2] Wikimedia incident stats by Krinkle, CodePen
<https://codepen.io/Krinkle/full/wbYMZK>.
[3] Month-over-month, Production Excellence spreadsheet
<https://docs.google.com/spreadsheets/d/1tRCh8aB0UYyLlhftvcHvhWH4-e7cF5V01Xv…>
.
[4] Open tasks, Wikimedia-prod-error, Phabricator
<https://phabricator.wikimedia.org/maniphest/query/Fw3RdXt1Sdxp/#R>.
https://www.mediawiki.org/wiki/Scrum_of_scrums/2021-02-17
=2021-02-17=
== Callouts ==
* RelEng: Longer-term train disruption calendar (caveats apply)
https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar
=== No updates ===
AHT, Library
=== '''No notes provided''' ===
Web, Prod Infrastructure, Parsing, Language, Inuka, Analytics, Cloud
Services, Platform, Quality & Test, Security
== SoS Meeting Bookkeeping ==
*Updates:
** from retro ideas to try:
*** Bolding items to read aloud +JF +TC
*** relaxing the start time
*** Template
**** Perhaps add a contact point (email, url, office hours, whatever) for
easy reaching out to teams when a bullet point seems interesting. +GG +JF
+TC
**** Adding a section where teams can add Gerrit patches or GitHub Pull
Requests to request reviews or feedback. +GG +TC [DONE]
**** Adding a "thanks" section +GG +JF +TC+AP [DONE]
== Product ==
=== Community Tech ===
* Blocked by:
* Blocking:
* Updates:
** We are now preparing for our next project (OCR Improvements) while
wrapping up our work on WS-Export improvements
***
https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2020/Wikisource/N…
***
https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Wikisource/I…
=== Editing ===
* Blocked by:
* Blocking:
* Updates:
** Releasing new topic tool as a Beta Feature on three Wikipedias (ar/cs/hu)
=== Growth ===
* Blocked by:
* Blocking:
* Updates:
** working on Add Link https://wikitech.wikimedia.org/wiki/Add_Link
** working on improvements in configuration (for more scalable deployments)
and mentorship
=== iOS native app ===
* Blocked by: None
* Blocking: I hope none.
* Updates: Finishing touches on Chinese varient work, bunches of other
small things.
=== Android native app ===
* Blocked by: None
* Blocking: I hope none.
* Updates: Refining watchlist and talk pages, moving to releasing every 2
weeks.
=== Structured Data ===
* Blocked by:
* Blocking:
* Updates:
** MediaSearch: splitting off frontend into separate extension
** Image recommendations: started working on scripts to evaluate POC
results (T273882, T273062) & tweak search profile based on analysis from
Research team (T271799)
** Continuing SDAW architecture discussions
=== Abstract Wikipedia ===
* Blocked by:
** None
* Blocking:
** None
* Updates:
** Continuing on phase gamma:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Phases
*** First route for back-end executor service has landed.
*** Looking at re-using firejail for isolation of run-times within executor
service.
** Thanks to Dave Pifke and Timo Tijhof from Performance for their support
and advice.
** Final week for community suggestions for the logo concept for
Wikifunctions:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Wikifunctions_logo_conce…
=== Vue.js ===
* Blocked by: Performance (Timo), review of
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/657953
* Blocking:
* Updates:
** WVUI v0.1.0 merged into core, yay! Thank you to Jon R, Jan D, Nick R,
Sam S, Mark H (Web team), Scott B (Security), and Timo T (Performance)
** Patch for ES6-only module support in ResourceLoader awaiting review
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/657953
** New patch up (as of last night) adding ES6 support to JavaScriptMinifier
https://gerrit.wikimedia.org/r/c/mediawiki/libs/Minify/+/664700
*** Thanks to Timo for setting up the mediawiki/libs/Minify repo
== Technology ==
=== Fundraising Tech ===
* Blocked by:
* Blocking:
* Updates:
** Working on donor email preference center (
https://phabricator.wikimedia.org/T268495,
https://phabricator.wikimedia.org/T268497)
** Annual PCI paperwork to keep accepting credit cards
** Trying to get Latin American spanish (es-419) working as a variant
throughout donation pipeline, falling back to Castillian Spanish (
https://phabricator.wikimedia.org/T199682,
https://phabricator.wikimedia.org/T199733)
** More fixes for our docker setup (
https://phabricator.wikimedia.org/T274943,
https://phabricator.wikimedia.org/T268683) (will need +2s from RelEng
eventually)
=== Engineering Productivity ===
==== Performance ====
* Blocked by:
* Blocking:
* Updates:
** Second frontend web perf training session budget approved, will be at
EMEA-friendly times. Provisional dates April 19 - 23
==== Release Engineering ====
* Blocked by:
** ServiceOps: [https://phabricator.wikimedia.org/T274459 VM requests for
GitLab]
* Blocking:
** Hopefully no longer blocking fundraising
* Updates:
** [All] Deployments/Covid-19
https://wikitech.wikimedia.org/wiki/Deployments/Covid-19
** Longer-term train calendar
https://wikitech.wikimedia.org/wiki/Deployments/Yearly_calendar
** Train Health
*** Last week: 1.36.0-wmf.30 [[phab:T271343]] <!--
https://phabricator.wikimedia.org/T271344 -->
*** This week: 1.36.0-wmf.31 [[phab:T271344]] <!--
https://phabricator.wikimedia.org/T271345 -->
*** Next week: 1.36.0-wmf.32 [[phab:T274936]] <!--
https://phabricator.wikimedia.org/T274936 -->
== Thanks ==
* Serviceops: [https://phabricator.wikimedia.org/T274306 docker-pkg help]!
* Everyone who helped us get the train unstuck over the past few weeks <3
=== Search Platform ===
* Blocked by:
* Updates:
** Outdated data still present in WCQS a month after statement update -
https://phabricator.wikimedia.org/T267825
** Resolve WDQS changelog situation -
https://phabricator.wikimedia.org/T272265
** Reduce default page weighting on wikitech and mediawikiwiki for pages
with "Historical" or "Archive"templates -
https://phabricator.wikimedia.org/T274082
=== Site Reliability Engineering ===
* Blocked by:
** None
* Blocking:
** None
* Updates:
** Working with Product Infra on maps
** Having some issues with upload edge caches recently
** Some SREs alongside Chris Albon made it to mainstream news for
https://phabricator.wikimedia.org/T273741
== WMDE ==
=== Technical Wishes ===
* Updates:
** Finishing a round of intensive analytics work, thanks for all the review
and support.
** Planning many changes in the Visual Editor template dialog.
== Cross-cutting ==
* Blocked by:
** Search Platform: PHP 8.0 work is long-term blocked on the migration to
ElasticSearch 7.0 https://phabricator.wikimedia.org/T263142
* Blocking:
** None
* Updates:
** No major changes.
** On PHP 8.0 work, we're now looking to enable PHP 8.0 as voting on the
REL1_35 branch for MediaWiki itself and as a gradual opt-in for extensions.
https://phabricator.wikimedia.org/T274965
** CI tools' upgrade status is adequate:
https://libraryupgrader2.wmcloud.org/status?branch=master
** Particular thanks this week to Umherirrender for their work on the
backlog of jsonlint -> eslint replacements
https://phabricator.wikimedia.org/T220036
Thad,
Thank you for the information about schema.org with respect to ClaimReview<https://schema.org/ClaimReview>.
A point of disagreement with that schema.org model is the ratings system concept (x out of N). Instead, for discussion, I prefer a more annotational approach for fact checking with typed annotations produced and consumed by both humans and software tools. That is, I prefer the concept of an informational message, warning, error system for fact checking resembling software IDE’s. Such a model is intuitive, can be readily formalized, made machine-utilizable, and typed annotations – informational messages, warnings, and errors – can be merged from multiple sources or service providers.
Best regards,
Adam
P.S.: As interesting, a new W3C Community Group is launching on the topic of document services. The group intends to discuss and make new architecture and API to facilitate: spellchecking, grammar checking, proofreading, fact checking, mathematical proof checking, reasoning checking, argumentation checking, and narrative checking. If the group interests you, please do feel free to support the creation of the group: https://www.w3.org/community/groups/proposed/#services .
From: Thad Guidry<mailto:thadguidry@gmail.com>
Sent: Friday, February 5, 2021 3:12 PM
To: Discussion list for the Wikidata project<mailto:wikidata@lists.wikimedia.org>
Cc: wikitech-l(a)lists.wikimedia.org<mailto:wikitech-l@lists.wikimedia.org>; Wikispore experimental project<mailto:wikispore@lists.wikimedia.org>
Subject: Re: [Wikidata] [Wikimedia-l] Idea of a new project: Wikifacts ?
Oops, the better link for the Schema.org work to support fact checking (some even still in progress after 3 years) probably should have been this: http://blog.schema.org/2017/08/schemaorg-33-news-fact-checking.html
Thad
https://www.linkedin.com/in/thadguidry/https://calendly.com/thadguidry/
Hi everyone,
We are starting a user group for people interested in spreading the
adoption of the Rust programming language[1] in the Wikimedia movement.
If you're not familiar with it, Rust is a systems programming language
that aims to provide the trifecta of safety, concurrency and speed. It's
very fun to use (rated #1 favorite language in Stack Overflow's survey 5
years and counting) and has fantastic tooling.
https://meta.wikimedia.org/wiki/Wikimedia_Rust_developers_user_group
If you're already using Rust or looking to get started - please sign up!
The current proposed goals of the user group are:
* Develop a rich toolkit of Rust libraries and applications for working
with Wikimedia and MediaWiki projects and APIs
* Make Rust a first-class language in Wikimedia infrastructure like
Toolforge
* Encourage the usage of Rust where appropriate to build safer and
better tools
* Assist others who end up encountering Rust and need help (e.g. when
upstreams adopt Rust)
* Mentor new developers who are interested in contributing technically
to the Wikimedia movement, including through programs like GSoC and
Outreachy
Have other ideas of what we could do? Please suggest them on the talk page!
[1] https://www.wikidata.org/wiki/Q575650
[2]
https://meta.wikimedia.org/wiki/Talk:Wikimedia_Rust_developers_user_group
-- Legoktm
Hiya all
tl;dr:
help us fix (or convince us not to care about):
* No atomic section is open (got LocalFile::lockingTransaction)[0]
Longer:
We've been on 1.36.0-wmf.27 for two weeks which is 1,038 changes behind
1.36.0-wmf.30 (the latest branch).
The remaining issue is: "No atomic section is open (got
LocalFile::lockingTransaction)"[0]
We're not sure about the impact of this log message. Holding the train is
our most effective tool to ensure that the log messages that we see don't
hurt users.
We need to solve this by Monday or we will remain on wmf.27 for another
week.
Any help you can provide is sincerely appreciated. Any feedback on how to
communicate about log messages more clearly so they get the attention they
need in a timely manner is also appreciated!
<3
-- Tyler
0: <https://phabricator.wikimedia.org/T274589>
Hello,
On Monday 02/15 I will start upgrading Quibble on the CI jobs to version
0.0.46. The notable changes for CI are:
* Run phpunit-unit stage before MediaWiki installation.
T266441 Kosta Harlan
* Fix regression which made us run linters for repositories besides
MediaWiki extensions or skins (eg: mediawiki/services/parsoid).
T263500 Antoine Musso
* Mute zuul.CloneMapper logging when running browser tests.
Antoine Musso
It opens the way to use Apache instead of the php built-in webserver.
That would make the Selenium tests slightly faster, but we have to add
Apache to the images, that will be done later.
The full changelog is:
https://doc.wikimedia.org/quibble/changelog.html
The task tracking the upgrade is:
https://phabricator.wikimedia.org/T274590
cheers,
--
Antoine Musso
(feel free to forward the message as is to your friends, family members &
colleagues)
Hello folks,
We would like to invite you to apply to the Outreachy and Google Summer of
Code program with the Wikimedia Foundation (a non-profit organization
behind Wikipedia)!
About the Outreachy program
Wikimedia will be mentoring ~3 projects in the Outreachy program in the May
to August 2021 round. The initial applications are due February 22nd at 4
pm UTC.
Apply today: https://www.outreachy.org/apply/ [1]
Outreachy offers three-month internships to work remotely in Free and Open
Source Software (FOSS) projects with experienced mentors. The internships
may include programming, user experience, documentation, illustration, and
graphic design, or data science.
Outreachy internships run twice a year – from May to August and December to
March. Interns are paid a stipend of $5,500 USD for the three months of
work. They also have a $500 USD stipend to travel to conferences and
events. Interns often find employment after their internship with Outreachy
sponsors or in jobs that use the skills they learned during their
internship.
Outreachy 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 is
invited to apply.
- Residents and nationals of the United States of any gender who are
Black/African American, Hispanic/Latin@, Native American/American
Indian, Alaska Native, Native Hawaiian, or Pacific Islander.
About the Google Summer of Code program
Wikimedia is planning to mentor 8-10 projects in 2021’s Google Summer of
Code (GSoC) program. Beginning March 9th, pending Wikimedia’s acceptance as
a mentoring organization, applicants can begin discussing ideas with the
mentors!
The student application will be due on April 13, 2021:
https://summerofcode.withgoogle.com/ [2]
Google Summer of Code, now in its 17th year, is Google's summer program for
candidates participating in any academic programs who want to get involved
in open-source software. Over 6,626 students from 121 countries have
already participated in the last year’s round i.e 2020 <
https://opensource.googleblog.com/2020/06/google-summer-of-code-2020-statis…>
[3]. Google Summer of Code is a unique program that pairs students with
mentors who introduce them to the open-source community and provide
guidance while they work on real-world open-source projects during their
summer break from university.
This year there are some new breaking changes in the GSoC program,
including:
- Smaller project size ~175 hr project (previously 350 hr)
- Shortened coding period ~10 weeks long (previously 3 months)
- Eligibility criteria redefined; the program is now open to candidates
participating in a variety of academic programs (previously accredited
university programs only)
Projects cover a wide range of fields including Cloud, Operating Systems,
Graphics, Medicine, Programming Languages, Robotics, Science, Security and
many more. It's a highly competitive program (and this year is expected to
be even bigger than last year), so don't wait until the last minute to
prepare!
About the Wikimedia Foundation
The Wikimedia Foundation is the nonprofit organization that hosts and
operates Wikipedia and the other Wikimedia free knowledge projects. Our
vision is a world in which every single human can freely share in the sum
of all knowledge. We believe that everyone has the potential to contribute
something to our shared knowledge and that everyone should be able to
access that knowledge, free of interference. We host the Wikimedia
projects, build software experiences for reading, contributing, and sharing
Wikimedia content, support the volunteer communities and partners who make
Wikimedia possible, and advocate for policies that enable Wikimedia and
free knowledge to thrive.
Resources
* Browse through the participants’ guides, to learn more about the
application process steps:
<https://www.mediawiki.org/wiki/Outreachy/Participants> [4]
<https://www.mediawiki.org/wiki/Google_Summer_of_Code/Participants> [5]
* All the projects will be showcased here:
<https://www.outreachy.org/communities/cfp/wikimedia/> [6]
<https://www.mediawiki.org/wiki/Google_Summer_of_Code/2021> [7]
We hope you will help us spread the word about Wikimedia’s participation in
these programs (by sharing this email)
Looking forward to your participation!
Cheers,
Gopa, Srishti, Pavithra, Ankit & Mahveotm (Wikimedia organization
administrators for GSoC & Outreachy)
[1] https://www.outreachy.org/apply/
[2] https://summerofcode.withgoogle.com/
[3]
https://opensource.googleblog.com/2020/06/google-summer-of-code-2020-statis…
[4] https://www.mediawiki.org/wiki/Outreachy/Participants
[5] https://www.mediawiki.org/wiki/Google_Summer_of_Code/Participants
[6] https://www.outreachy.org/communities/cfp/wikimedia/
[7] https://www.mediawiki.org/wiki/Google_Summer_of_Code/2021
--
Regards
Gopa Vasanth <https://www.mediawiki.org/wiki/User:Gopavasanth>
Amrita Vishwa Vidyapeetham <http://www.amrita.edu/> | Blog
<https://gopavasanth.wordpress.com/>
amFOSS <https://amfoss.in/@gopavasanth> | GitHub
<https://github.com/gopavasanth> | Gerrit
<https://gerrit.wikimedia.org/r/#/q/gopavasanth>
“Yesterday is not ours to recover, but tomorrow is ours to win or lose.”
