This has been a long discussed topic, especially with @NDKilla and @Southparkfan who have given me a lot of advice and helped me have better knowledge about LAMP and MediaWiki in general. I think that now I understand the stuff needed for becoming a mw-admin. I have also read https://meta.miraheze.org/wiki/User:Southparkfan/mw-admins,other techincal pages written by SPF and done a few online courses for an even better understanding.
If I become a mw-admin, I will be way more careful than now (as you know I tend to rush a bit) and will never merge a PR until I'm very sure that it is done properly, if I'm not I will wait for someone else to check it. For installing extensions, I will not do it by myself, I will either continue making PRs or only do it step-by-step with another sysadmin.
Description
Event Timeline
I'm happy with that mw-admin page (mostly) and am overall happy with the final result of Reception123's commits. A few issues were discussed on IRC along with some possible options.
I think mw-admins with guided deployment of new extensions is a good idea.
Like I said before if it came down to "mw-admins with no restrictions" or "no access" I choose the former.
Should be discussed a lot more of course.
I agree that I should have restrictions on anything that I am not capable of doing and should only have access to the things that I know.
Although I have less than no say whatsoever (hell, this is the second day of even knowning this project existed!) in my outsider opinion, Reception123's commits show at the very least a solid technical understanding of MW's config files.
Additionally, many of the tasks listed at SPF's mw-admins page have detailed instructions which, if followed carefully and slowly, should guide Reception123 through any areas they feel less comfortable in.
If we hand out access, the following restrictions should be in place:
As long there is no MediaWiki expert (Corey, John, Labster, NDKilla, Southparkfan) online to assist, the following things should be avoided:
- Configuration changes other than changing wiki configuration (e.g. the part that reads the database lists) - this also applies to pull requests
- Maintenance scripts (excluding the manageInactiveWikis.php script)
- Running SQL queries that change the database
When deploying, Reception123 should be careful:
- Use http://phpcodechecker.com to verify the PHP syntax is correct
- If the site is nevertheless brought down, revert immediately (don't try to find out what broke it, you can do that after the site is back online) and try to avoid proceeding with your changes, until another sysadmin is online.
These restrictions are not permanent, and can be waived as needed (in the future).
If @Reception123 agrees with the restrictions, I have no objections against access.
@Southparkfan I fully agree to these restrictions, and I think it is a good idea for me to not use the things mentioned without another sysadmin to make sure I will correctly do them.
Approval by @NDKilla and @Southparkfan.
I approve, making it the first triple approval.
And to make it even more special, assigning to NDK.