Wikimedia CH/Information Technology Strategy/Fields of Actions

This page is a STUB. Not approved. Feel free to edit! Thank you!

This page is a sub-page of the Wikimedia CH/Information Technology Strategy.

Fields of Action

The following are concrete Fields of Action respecting the general Directions of this Strategy.

This information is the result of the daily work of the technical department of Wikimedia CH, following the considerations and the concerns from the interviews with the staff.

Important: Recall that this is still a draft. Not approved.

Continuous First Level Assistance to Staff

Staff during various interviews repeatedly made explicit the need of more assistance. Often this kind of assistance was done by willing and helpful staff members, but it cannot be enough. Staff deserves a form of professional 1st level assistance, so, to have a single point of contact to receive general problems, also about a specific personal computer.

This means this kind of assistance should have advanced communication skills, to be able to communicate with people with different skills (not necessarily technical skills), and be able to help these people to triage a potential technical issue, to file and follow-up the most specific bug request, or feature request in the most appropriate area (some time related to a fundraising supplier, some time related to the supplier of personal computers for the staff, some time in charge of the webmaster, some time in charge of a volunteer, etc.). It must also be able to recognize what is neither a bug nor a feature, and is simply a misuse of a tool, to still find an human safe space for personal training, decreasing technological frustrations.

Example goals:

being able to receive technological issues (but not necessarily technical) from staff members, for example related to working devices (e.g. working laptop, etc.) or generic software in use by staff for working reasons
being able to collect and process generic problem reports and enrich them with technical details, in order to be able to escalate the problem to the most appropriate technical software manager (e.g. reaching 2nd or even 3rd level of support)
being able to have a support that (even if it cannot solve problems directly) it can help to describe what the real root problem is, in order to still allow advancements and enable a potential resolution

Example use cases:

a Staff member today has a problem with WordPress https://wikimedia.ch/ not printing a specific article from the administration panel. A central 1st Level Technical Support can be contacted, to figure out whether it is a problem with the computer, the printer, or WordPress. After the root problem is identified, in case the problem is with the website the Tech Support can describe a technically appropriate report suitable for the attention of the webmaster; in case the problem is with the printer, the Tech Support can help the user directly with drivers; or can help the user to contact whoever should be in charge for possible replacement of office hardware equipment. Etc.

Fortunately this is a frequent enterprise need and there are vendors who provide 1 Level Assistance on end users' computers, on a wide range of operating systems between Linux, Microsoft Windows or macOS. Often, these interventions are paid in packages of hours per month. So the organization's leaders can collect some estimates and allocate a budget.

Notes on conflicts of interest:^[1]

There are no conflicts of interests in this suggestion since, for example, Valerio Bozzolan is not the right person to do personal assistance on Microsoft Windows, macOS, etc.

Internal Trainings

It is not trivial for any general person to fully understand complex topics like:

security practices
copyright and licensing
GDPR and data protection
Wikimedia project internals
software and hardware ethics

Each one of these areas deserve internal training for the staff, but also to volunteers - including but not limiting to like board members.

This is a non-exclusive list of concrete and already-existing certification programs that can be evaluated for recommendation / offering at least to the staff and board members:

International Computer Driving Licence
Creative Commons Certificate for Open Culture/ GLAM
Goal: learning technical details of Creative Commons licenses for GLAMs
feel free to suggest more useful certifications!

Notes on conflicts of interest:^[1]

There are no known conflicts of interest on proposing these certifications. For example, Creative Commons is a non-profit like-minded organization, independent from Wikimedia CH. Their certification is not targeted to Wikimedia CH but to the wide public.

Continuous Support for the Infrastructure

As already mentioned, Wikimedia CH handles a lot of services and some of these are in-house, delivered from servers in Switzerland. This is an highly privacy friendly situation for our Switzerland communities, users and stakeholders.

The challenge is, Wikimedia CH is expanding and is trying to provide various more-or-less internal utility tools, and, is also trying to help various communities such as Wikimini or DicoAdo, in reducing their economic expenses by internalizing their tools.

The problem that is arising, is the risk of not being able to keep up with all the potential technical problems, including ordinary maintenance and security updates.

Wikimedia Foundation has multiple internal staffs to cover these needs. Wikimedia CH currently has no member in charge of this on an ongoing basis. Most of this technical work is done professionally sporadically, and also sporadically on a voluntary basis, and this situation is not ideal.

This is an indicative non-exhaustive list of fields that surely deserve a continuation in Technical Assistance.

There was an attempt to describe the following practical information:

Current Situation: even if for obvious reason most technical problems are not predictable - therefore it is to be understood as a row recent average
Survival Mode: minimal situation expressed as "minimum time needed to avoid probable major regressions"
Evolve Mode: optimal situation expressed as "minimum time needed to evolve this project in a more professional quality for the organization"

Project and info	Main needs	Situation average current situation	Survival Mode minimum suggested time	Evolve Mode suggested professional time
Main website https://wikimedia.ch/ Skills: WordPress	error reporting to upstream support	to be clarified (complete support already covered)	to be clarified	to be clarified
Fundraising Tools/Members Database	developments to be agreed upon better integrations error reporting to upstream support	to be clarified (support already covered)	to be clarified	to be clarified
Matomo privacy-friendly surveys Skills: PHP, Linux	apply security updates verify backups	0-2 minutes /week	15 minutes /week	1 hour /week
LimeSurvey privacy-friendly tool for surveys Skills: PHP, Linux	apply security updates verify backups	2 minutes /week	30 minutes /week	1 hour /week
Zabbix monitoring Internal health checker	monitor issues adjust alarms	0-1 hour /week	1 hour /week	2 hours /week
Argo Wikimetrics	routine maintenance improve documentation	0-1 hour /week	30 minutes /week	2 hours /week
Cronos Calendar Skills: Lua, PHP	present to the community hand over to the community follow community requests	0-20 minutes /week	1 hours /week	4 hours /week
Servers management Skills: Linux	rationalize services apply security updates proactively take care (e.g. thanks to Zabbix alarms) improve documentation	0-2 hours /week	4 hours /week	2 days /week
Dicoado Skills: MediaWiki, Linux	assure migration completion apply security updates (keeping MW and server up to date) bug fixes enabling multilingual possibility	0-15 minutes /week	0-4 hours /week	1 day /week
Wikimini Skills: MediaWiki, Linux	handle known security issues upgrade to stable hardening skin fix	0-4 hours /week	1 day /week	2 days /week
Cassandra	project handover documentation fix	0-1 hours / week	1 hour /week	2 hours /week
Spot Activities Skills: full-stack	last minute problems sysadmin fixes to our general infrastructure	2-4 hours /week	4 hours /week	8 hours /week
Tech Strategy (example of Spot Activity)	produce the document	0-4 hours /week	1 days /week	2 days /week
Overhead Time not invested in a concrete technical area. It is better if it is little But if it is not foreseen, it leads to burnout.	work organization / planning meetings / calls / mails switch from one task to another unexpected troubleshootings	0-1 hour /week	1.5 hours /week	2.5 hours /week

Context

The current professional technical operators mainly involved in the above elements are:

for WordPress: there is an external consultant (note that the time needed is not expressed here since this is a topic already covered continuously - but feel free to edit this document to share some info)
for Fundraising Tools / Database: there service provider itself is the only entity who can give assistance and follow our developments. But it's unclear whether they can implement our development requests with our current contract (note that the time needed is not expressed here since this is a topic already covered continuously)
for the rest of the hardware sysadmin activities: we have a Switzerland provider who very thoroughly and competently takes care of hardware things and problems. We have minimum response times per contract (note that the time needed is not expressed here since this is a topic already covered continuously)
for the rest of the services and in-server software sysadmin activities: Valerio Bozzolan (working for an external company)

Challenge

We do not have enough human working hours to cover these needs. Note that since 2023 Valerio B. was also allocated on the Technological Strategy but the company he works for does not authorize allocating to WMCH for more than 12 hours a week (at best of company emergencies and other factors that reduce this time budget).

Concerns:

There is currently not enough human working time to pursue such intensive one-shot projects such as a Technological Strategy, as well as keeping up and running the Wikimedia CH infrastructure, with concrete impact on the continuity of communities like DicoAdo and Wikimini. So there is great margin for improvement to cover all technical needs, known and unexpected.

Potential solutions include:

Find an extra part-time sysadmin consultant (taking into consideration training, handover, ...); somehow convert an already existing part-time sysadmin resource to full-time; etc. or more destructive solutions, such as suppressing projects to balance workload (probably easier but not suggested).

Notes on conflicts of interest:^[1]

In the current situation (without changing anything) there are no known conflicts of interest. When Wikimedia CH activates for example Valerio Bozzolan (the person who wrote the majority of this section), he has a fixed salary not tied to Wikimedia CH and he has no financial benefit from increasing or continuing this collaboration. The company he works for has a totally separated core business (software house in the food sector).

In proposing to increase the current working hours for WMCH, in fact Valerio B. proposes to be hired internally - just because there is probably not another way compatible with the company in which he currently works. Changing position can become a conflict of interest if a future inter salary proposal would be higher than the past one (which for reasons of max. transparency it's declared here: ~30K EUR gross annual salary).

There are technical interests in welcoming an extra external system administrator for Wikimedia CH to better cover needed maintenance, updates, migrations, security fixes, etc. Premising that Valerio has no other person to recommend (all the people he knows well are already employed elsewhere) and so there are no known conflicts of interests in a potential review of external applications, premising that there is technical interest in being more than one technical person.

Practicals

We are not a software-oriented company, but we are actually surrounded by software, and we need more people who can have enough creative space to implement all the Wikimedia CH programs involved in the Innovation field, like:

Incubator
Pit-stop
Factory
(and Tech community)

The general field of action is: take care of new and existing software needs, so that the project can have enough creative space to evolve in a positive way, and not simply survive.

Incubator: When a new project lands the Incubator program, we can examine needed resources to cover not just the entire prototyping process, but also user documentation, technical documentation, and basic security maintenance and backup in medium-long terms.

Sufficient documentation is usually enough for taking care of a possible complete handover, but also setting aside time to tell the internal workings of the project to the technical community is very useful to actually enable any potential concrete handover. Verify that the prototype does not then require a rewrite in medium-terms, for example requiring to adopt non-esoteric technologies, and expressly under a free license to avoid copyright problems or the impossibility of independent maintenance.

Pit-stop: when an already-existing project lands, assure there are enough resources to basic maintenance in long-terms, including backup integrity checks, infrastructure documentation, team documentation (who has access to what), and assess whether there is a possibility of having an external security review.

These are definitely things that the community alone usually never achieve, in any professional level.

Factory: avoid to compete with WMF, but complete the gap.

The goal is to be able to support long-term tools for projects, at least in the scope of Switzerland. The service should be complementary to the ones offered by Wikimedia Cloud / Toolforge or other services by Wikimedia Foundation and other like-minded organizations. In order to allow collaboration and easy adoption, we should be as much transparent as possible, and better communicate what we can offer, as well as what the Factory program cannot offer.

Adopting more Open and Neutral Tools for Volunteers

Premising that many organizations have a very complex internal infrastructure which is often best not changed with a superficial intention of diminishing the negative impact of something;

First of all, it is important that what is external, and therefore what comes out of Wikimedia CH and should reach volunteers (and vice-versa), that external material should be shared with the triangle of: Open Standard, Open Format, and Open Tools.

So, it doesn't matter what internal tool Wikimedia CH currently has to collect internal documents. The technological focus of Wikimedia CH should be: work to have tools to better communicate externally in the most neutral, sustainable and ethical way possible.

Practical fields of actions:

raise awareness of Open Source tools already available in Wikimedia CH to communicate to the volunteers (WordPress; WMCH LimeSurvey instead of Google Form, WMCH Matomo instead of Google Analytics, etc.)
adopt new Open Source systems in support of the "internal" ones.
For example, adopt an Open Source Nextcloud collaborative suite, that can be also given to volunteers to collaborate in real-time on documents, or drop files, share meeting invitations, etc. as official neutral tool to communicate from volunteers to the organization and vice-versa.
For example, adopt an Open Source BigBlueButton proessional videocall instance, that can be offer for community meetings, or meetings for the members or the volunteer board members, in order to keep private communication, webcam, audio, etc., in Switzerland. So that Zoom or Microsoft or other companies located in the United States etc. are not a requirement for volunteer participation.

These and similar actions can be achieved even without impacting the internal organization of Wikimedia CH, and can be achieved without proposing tiring/risky internal migrations.

Ensure an Internal Figure for Data protection and Privacy

Wikimedia CH is already following a good precautionary direction of "minimal data management", for example not using Google Analytics but Matomo, on servers owned by Wikimedia CH, in Switzerland.

This direction often involves several working groups and cannot be followed successfully on voluntarily basis. The GDPR consultant, on the other hand, is obviously a professional, but he or she must sometimes interface with volunteers, so it must be a sufficiently continuous contact so as not to create deadlocks.

It is therefore recommended to ensure contact with a sufficiently digitized and experienced GDPR consultant in the nonprofit.

General goals:

help manage some concerns on community services
review data protection policies
review system permits and privileges
better manage data processing
learn how to handle data deletion requests properly

Notes

↑ ^a ^b ^c The people who contributed to the WMCH Strategy are encouraged to publicly post their potential conflicts of interest in this section. Thank you for your transparency.

[coi-section-1] The people who contributed to the WMCH Strategy are encouraged to publicly post their potential conflicts of interest in this section. Thank you for your transparency.

[1]