Hello, Am Dienstag, 19. Juli 2016, 21:22:58 CEST schrieb Sarah-Julia Kriesch:
Christian is bringing all to the point. Admins in Provo have been the problem and not you, Lars. We can fix a small part with the new hardware, but not all. You'll need them for different issues in the future. And that was the reason, why I said they need new admin policys, too. You can think about adding that to the blog article or not. Speaking every Monday about issues and only doing that isn't a good workflow for such admins... I recommend agile System Administration with Daily SCRUM in such a situation. Sysadmins, who don't know what to do, "have to" ask their team for coming to the next task or they blame themselves... What you need is a Team Member (with Sysadmin knowledge) who wants to play the SCRUM Master every day. :-) I had a Sysadmin without passion in the last company and at first he didn't do his tasks. I introduced Daily SCRUM and he saw the feature that he "has to" ask questions and all task come to an end. After 1 week he wanted to have it all the time and all Team Members had fun. I was in the first Sysadmin Team with SCRUM at 1&1 and all teams in our department copied that... Last week I read an article aabout that and that Google is using it in their best teams with the name "High Performers".
Wow. Until now, my opinion about SCRUM (and similar methods) was that it's "just" a different method to organize the work, but without serious benefit. Well, except "we use an (over?)hyped method" and "our workflow wins every buzzword bingo" ;-)) Oh, and http://www.commitstrip.com/en/2016/01/29/the-daily-stand-up/ ;-) You managed to completely surprise me :-) and I'll have to change my opinion about SCRUM.
You can think about that and the situation in Provo. Any time that will fall back again and it is the right time for doing changes...
Indeed. I'm _very sure_ that at least one admin [1] is open to improvements. IMPORTANT: Make sure to have enough popcorn ready before reading the next paragraphs! Popcorn ready? OK, here we go. Right now, M. is working on restoring the lost images [2] and had quite some "fun" while digging for those needles in a big haystack of deleted spam files. To make things more interesting, MediaWiki renames deleted files to a nearly-random name[3], so M. will need to find out the original names (based on the file timestamp and Special:Filelist), rename the files and finally re-upload them to the wiki. Funny, right? ;-) So to sum it up: The current policy in Provo means - wasting lots of time - most of the second bunch of spam could have been avoided by deploying my config fix instantly - wasting even more time (the lost images were collateral damage of deleting the spam that arrived between my config fix and getting it deployed) - reduced service quality ("temporary" data loss, and wiki pages with images missing for several days) - leaving an annoyed admin behind (I doubt M. likes searching through the haystack and re-uploading the missing files) - needless to say that I'm also not amused and needed some time to drive this - and, probably most important for the management level: wasting time also means wasting money (salery for the employees doing avoidable work) Needless to say: feel free to forward this to whoever is responsible for the workflow in the Provo admin team ;-) Regards, Christian Boltz PS: Non-random sig (in german, sorry) [1] I'm not sure if I should mention his name in public, so let's just call him "M.". (People involved in this discussion should know whom I'm talking about.) [2] https://progress.opensuse.org/issues/12694 contains more details. All Heroes should be able to read it - if not, I can CC you ;-) [3] using the sha1sum of the file content, so without knowing the file content the name is no better than random. At least the original file extension is kept... -- Die erprobte Strategie der Managementmotivation im Operating [ist] eine, die ich gerne mit "Teile die Schmerzen" beschrieben möchte. Zum Beispiel setzt man den Projekteigentümer auf dieselbe Alerting-Methode wie den Sysadmin, der am Ende Sonntag nachts um 4 Uhr wegen eines Alarms die vorbeugende Wartung durchführen muß. [...] Wenn wir nun also einen jungen Projektverantwortlichen haben, bei dem das Handy Sonntag nachts um vier die Frau und das 6 Monate alte Kind weckt, dann ist diese Person nach einigen Wochen unmittelbaren Alerting-Erlebens sehr viel zugäng- licher. [http://blog.koehntopp.de/archives/2859-Wieso-zehn-Prozent.html] -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org