Auto-update Tech namespace pages 2024-09-17 01:48:56.104915

content/tech-docs/Tech:Compromised_Handling.md

@@ -29,7 +29,7 @@ If you add something to private git which is not covered above, please ensure yo
 
 ## Who to notify if something is compromised? 
 
-In general, an email to sre `{{ {{@}} }}`miraheze.org should always be sent if any data (or suspicion of data) is compromised. Specific services will have specific additional people to contact or people who should be notified to assess the situation (the person who is most knowledgeable about the component - see list of [Site Reliability Engineering](https://meta.miraheze.org/wiki/Tech:SRE_Volunteers) team members).
+In general, an email to tech `{{ {{@}} }}`miraheze.org should always be sent if any data (or suspicion of data) is compromised. Specific services will have specific additional people to contact or people who should be notified to assess the situation (the person who is most knowledgeable about the component - see list of [Technology team members](/tech-docs/techvolunteers)).
 
 We operate as an open project, therefore any security incident (no matter how small) will result in a community notification through an incident report. An incident report should always be submitted for security incidents as they're far more damaging in the long run than a 10-minute service outage, and is our way of showing progress and work towards providing a more secure platform. Reports should be drafted and approved by an Engineering Manager first as the consequences of a poor or unsatisfactorily complete report can be unpredictable.
 
@@ -44,7 +44,7 @@ Once someone is aware that a server has been compromised, their ability to handl
 * Ensure no one can gain access to the system after the issue has been discovered. Be it stopping the ssh server, shutting it down (or a reboot to close connections), blocking all ports etc. just ensure no one can get into the system.
 * Begin to get a handle on how access may have been gained - through software? an SSH account? Compromised SSH key? If it can be tied to a certain and definitive SSH account - remove said account from all servers and check the rest for safety.
 * Evaluate how the hole can be closed, if a key was compromised - ensure it is gone and force a regeneration, if a service/software allowed access - was it a security issue upstream? Were we running old software? Could it be how we're using it? Thoroughly investigate this question and follow solutions up.
-* Discuss findings with others or send findings to sre `{{ {{@}} }}`miraheze.org to get more eyes on it.
+* Discuss findings with others or send findings to tech `{{ {{@}} }}`miraheze.org to get more eyes on it.
 
 The above is a basic plan to follow. Certain situations require more in-depth investigations, they can take minutes to hours to days to even weeks.
 

content/tech-docs/Tech:Experimental_Wikis.md

@@ -6,7 +6,7 @@ Experimental wikis are active wikis with experienced contributors that have agre
 
 To have the flag enabled in ManageWiki (by a Steward), the following criteria must be met:
 * The wiki must be active and used regularly.
-* The wiki must be public.
+*  The wiki must be public.
 * Users on the wiki should be technically competent and polite.
 * The wiki should have a variety of extensions installed (especially Cargo/Social Profile/FlaggedRev/DPL/Complex ones).
 * The wiki should use gadgets or user scripts.

content/tech-docs/Tech:GitHub.md

@@ -4,7 +4,7 @@ title: Tech:GitHub
 
 [GitHub](https://meta.miraheze.org/wiki/github:) is the service we use to host our open-source repositories. They can be found [here](https://meta.miraheze.org/wiki/github:miraheze).
 
-Push access to the repositories is limited to [system administrators](https://meta.miraheze.org/wiki/Tech:SRE_Volunteers), but any user can make a pull request. [Puppet](/tech-docs/techpuppet) runs every 30 minutes (except MediaWiki extensions or skins) and can be run manually on each server by a [system administrator](https://meta.miraheze.org/wiki/Tech:SRE_Volunteers). It is recommended to read the "README.md" file for a repository before contributing to it.
+Push access to the repositories is limited to [system administrators](/tech-docs/techvolunteers), but any user can make a pull request. [Puppet](/tech-docs/techpuppet) runs every 30 minutes (except MediaWiki extensions or skins) and can be run manually on each server by a [system administrator](/tech-docs/techvolunteers). It is recommended to read the "README.md" file for a repository before contributing to it.
 
 ## Production repositories 
 

content/tech-docs/Tech:Goals.md

@@ -4,20 +4,16 @@ title: Tech:Goals
 
 Goal Periods at Miraheze are biannual periods of time when certain tasks (called Goals) are given extra focus and resources to be resolved.
 
-Goals are split into two categories:
-* MediaWiki
-* Site Reliability Engineering
-
 Tasks must meet one of the following criteria to be considered as a goal:
 * A long-term project that can realistically be finished before the end of goal period,
 * A development project that will have a positive impact on Miraheze communities,
-* An objective for Site Reliability Engineering (infrastructure, introducing a new service, major work etc.).
+* An objective for the Technology team (infrastructure, introducing a new service, major work etc.).
 
 MediaWiki tasks being considered for a goal must have:
 * Someone willing and committed to work on the task; or
 * Have such a massive positive impact or overwhelming support by the wider community, that the completion of the task in said goal period will bring improvements to that service.
 
-Site Reliability Engineering tasks being considered for a goal are left at the discretion of [the SRE team](https://meta.miraheze.org/wiki/Tech:Organisation#Team:_Infrastructure,_Site_Reliability_Engineering).
+Tasks being considered for a goal are left at the discretion of [the Technology team](/tech-docs/techorganization#infrastructure-specialist).
 
 ## Review of Past Goals 
 

content/tech-docs/Tech:Inactivity_policy.md

@@ -4,7 +4,7 @@ title: Tech:Inactivity policy
 
 `{{ {{Outdated}} }}`
 
-**System administrators** are responsible for making sure that things run smoothly, and that the different issues and tasks on Phorge are completed in a timely and effective manner (see [Tech:SRE Volunteers](https://meta.miraheze.org/wiki/Tech:SRE_Volunteers) and [Tech:Organization](/tech-docs/techorganization) for details). While we are all volunteers here and all have real life responsibilities, activity is nevertheless important for any sysadmin, and a prolonged period of inactivity may provoke security concerns.
+**System administrators** are responsible for making sure that things run smoothly, and that the different issues and tasks on Phorge are completed in a timely and effective manner (see [Tech:Volunteers](/tech-docs/techvolunteers) and [Tech:Organization](/tech-docs/techorganization) for details). While we are all volunteers here and all have real life responsibilities, activity is nevertheless important for any sysadmin, and a prolonged period of inactivity may provoke security concerns.
 The purpose of this policy is to ensure that people are aware whenever a sysadmin knows that they will be inactive, as well as to have a criteria for when someone is inactive and do not notify their absence.
 
 ## Notification 

content/tech-docs/Tech:Organization-Site_Reliability_Engineering.md

@@ -2,7 +2,7 @@
 title: Tech:Organization/Site Reliability Engineering
 ---
 
-This is a guide for all Miraheze Site Reliability Engineers. They have access to Miraheze servers and to Miraheze GitHub repositories (see [Tech:SRE Volunteers](https://meta.miraheze.org/wiki/Tech:SRE_Volunteers)), and they are responsible for maintaining all Miraheze servers and making sure they function smoothly.
+This is a guide for all Miraheze Site Reliability Engineers. They have access to Miraheze servers and to Miraheze GitHub repositories (see [Tech:Volunteers](/tech-docs/techvolunteers)), and they are responsible for maintaining all Miraheze servers and making sure they function smoothly.
 
 ## Rules 
 

content/tech-docs/Tech:Projects-Automation_of_SSL_requests.md

@@ -2,11 +2,11 @@
 title: Tech:Projects/Automation of SSL requests
 ---
 
-This is a project proposal for implementing a system where on request, users can generate a Lets Encrypt certificate which is then deployed to GitHub and to MediaWiki via $wgServer (after being approved by an SRE member).
+This is a project proposal for implementing a system where on request, users can generate a Lets Encrypt certificate which is then deployed to GitHub and to MediaWiki via $wgServer (after being approved by a Technology team member).
 
 ## Background 
 
-Currently, for users to have a domain apart from a Miraheze subdomain (i.e., example.miraheze.org) they must file a request on Phorge. Thereafter, an SRE member must generate an SSL certificate with a script on a server (puppet181), commit the SSL certificate and config on GitHub, and then complete $wgServer via Special:ManageWiki.
+Currently, for users to have a domain apart from a Miraheze subdomain (i.e., example.miraheze.org) they must file a request on Phorge. Thereafter, a Technology team member must generate an SSL certificate with a script on a server (puppet181), commit the SSL certificate and config on GitHub, and then complete $wgServer via Special:ManageWiki.
 
 ## Plan 
 
@@ -32,13 +32,13 @@ The current system will have to be completely redesigned and the server where pr
 
 ## Outcome Steps 
 
-* A web form that allows users to create requests for custom domains (and by definition SSL certificates) which then can be approved or declined by SRE members. Approval would entail the automatic creation and deployment of the SSL certificate and configuration of the custom domain.
+* A web form that allows users to create requests for custom domains (and by definition SSL certificates) which then can be approved or declined by Technology team members. Approval would entail the automatic creation and deployment of the SSL certificate and configuration of the custom domain.
 
 ## Getting Started 
 
 Anyone interested in starting this project should:
 * Get familiar with how our SSL process currently operates (see [Tech:SSL certificates](/tech-docs/techssl_certificates)) for more details.
-* Get in touch with an [SRE](https://meta.miraheze.org/wiki/Tech:Organisation#Team:_MediaWiki,_Site_Reliability_Engineering) member to discuss how to proceed.
+* Get in touch with a [Technology team member](/tech-docs/techvolunteers) to discuss how to proceed.
 
 ----
 **[Go to Source →](https://meta.miraheze.org/wiki/Tech:Projects/Automation_of_SSL_requests)**

content/tech-docs/Tech:Projects-CreateWiki_AI_improvement.md

@@ -30,7 +30,7 @@ There are no external requirements and no blockers requiring additional help.
 
 Anyone interested in starting this project should:
 * get familiar with how the current CreateWiki AI works (see [the CreateWiki repo](https://github.com/miraheze/CreateWiki) for more details.
-* get in touch with an [SRE](https://meta.miraheze.org/wiki/Tech:Organisation#Team:_MediaWiki,_Site_Reliability_Engineering) member to discuss how to proceed.
+* get in touch with a [Technology team member](/tech-docs/techvolunteers) to discuss how to proceed.
 
 ----
 **[Go to Source →](https://meta.miraheze.org/wiki/Tech:Projects/CreateWiki_AI_improvement)**

content/tech-docs/Tech:Projects-Miraheze_Wiki_List.md

@@ -51,8 +51,8 @@ There are no external requirements and no blockers requiring additional help.
 ## Getting Started 
 
 Anyone interested in this project should:
-* register their interest at the [phabricator ticket](https://meta.miraheze.org/wiki/phabricator:T218),
-* discuss a possible timeline/integration plan with a [mw-admin](https://meta.miraheze.org/wiki/Tech:Organisation#Team:_MediaWiki,_Site_Reliability_Engineering) or [operations](https://meta.miraheze.org/wiki/Tech:Organisation#Team:_Infrastructure,_Site_Reliability_Engineering) member.
+* register their interest at the [phorge ticket](https://meta.miraheze.org/wiki/phorge:T218),
+* discuss a possible timeline/integration plan with a [mw-admin](/tech-docs/techorganization#mediawiki-specialist) or [operations](/tech-docs/techorganization#infrastructure-specialist) member.
 
 ----
 **[Go to Source →](https://meta.miraheze.org/wiki/Tech:Projects/Miraheze_Wiki_List)**

content/tech-docs/Tech:Projects-Multiversion.md

@@ -40,7 +40,7 @@ There are no external requirements and no blockers requiring additional help.
 
 Anyone interested in starting this project should:
 * get familiar with how we currently do MediaWiki updates
-* get in touch with an [SRE](https://meta.miraheze.org/wiki/Tech:Organisation#Team:_MediaWiki,_Site_Reliability_Engineering) member to discuss how to proceed
+* get in touch with a [Technology team member](/tech-docs/techvolunteers) to discuss how to proceed
 
 ----
 **[Go to Source →](https://meta.miraheze.org/wiki/Tech:Projects/Multiversion)**

content/tech-docs/Tech:Projects-Proper_CI_for_Miraheze_extensions.md

@@ -23,7 +23,7 @@ There are no external requirements and no blockers requiring additional help.
 ## Getting Started 
 
 Anyone interested in starting this project should:
-* Get in touch with an [SRE](https://meta.miraheze.org/wiki/Tech:Organisation#Team:_MediaWiki,_Site_Reliability_Engineering) member to discuss how to proceed.
+* Get in touch with a [Technology team member](/tech-docs/techvolunteers) to discuss how to proceed.
 
 ----
 **[Go to Source →](https://meta.miraheze.org/wiki/Tech:Projects/Proper_CI_for_Miraheze_extensions)**

content/tech-docs/Tech:Projects-Wiki_Statistics_Special_Page.md

@@ -8,7 +8,7 @@ This is a project proposal for adding a statistics page on all Miraheze wikis wh
 
 Currently, Miraheze provides no analytical information to users about how many times a wiki is viewed, how many unique visitors there are to the wiki or what pages are considered popular based on viewing statistics. However, Miraheze does track (to a degree, inline with the [Privacy Policy](https://meta.miraheze.org/wiki/Privacy_Policy) and respecting DNT headers) which pages are read by users, how long for, which wiki, how they got there, and browsing/OS information. This is all collected by using [Piwik](https://meta.miraheze.org/wiki/Tech:Piwik) ([link](https://piwik.miraheze.org)) which is restricted to system administrators only.
 
-It has been a [common theme among the community](https://meta.miraheze.org/wiki/phabricator:T680) that there needs to be some form of analytical information available on wikis and there is a shared opinion among system administrators that the information should be derived from Piwik.
+It has been a [common theme among the community](https://meta.miraheze.org/wiki/phorge:T680) that there needs to be some form of analytical information available on wikis and there is a shared opinion among system administrators that the information should be derived from Piwik.
 
 ## Plan 
 
@@ -40,7 +40,7 @@ As Piwik is currently a restricted service, access, and testing requires someone
 
 Anyone interested in starting this project should:
 * Get familiar with how Piwik works and how its API can be used to collect views per page / views across a whole site.
-* Get in touch with an [operations](https://meta.miraheze.org/wiki/Tech:Organisation#Team:_MediaWiki,_Site_Reliability_Engineering) member to discuss next steps for integrating with the current Piwik install.
+* Get in touch with an [operations](/tech-docs/techorganization#infrastructure-specialist) member to discuss next steps for integrating with the current Piwik install.
 
 ----
 **[Go to Source →](https://meta.miraheze.org/wiki/Tech:Projects/Wiki_Statistics_Special_Page)**

content/tech-docs/Tech:Removing_an_extension.md

@@ -2,7 +2,7 @@
 title: Tech:Removing an extension
 ---
 
-If a decision has been made to remove an extension from Miraheze for whatever reason (i.e., it's unmaintained, it isn't compatible with the current version of MediaWiki, etc.) the following procedure should be followed when removing an extension. Any user can create a pull request to remove an extension, but it has to be merged and deployed by a [system administrator](https://meta.miraheze.org/wiki/Tech:SRE_Volunteers).
+If a decision has been made to remove an extension from Miraheze for whatever reason (i.e., it's unmaintained, it isn't compatible with the current version of MediaWiki, etc.) the following procedure should be followed when removing an extension. Any user can create a pull request to remove an extension, but it has to be merged and deployed by a [system administrator](/tech-docs/techvolunteers).
 
 The steps below must be done in this order: