Hello, Am Montag, 18. Juli 2016, 18:05:03 CEST schrieb Lars Vogdt:
I took the freedom and subscribed everyone who participated in the openSUSE Admin meeting last month to this brand new list.
:-)
While it seems like I'm not able any more to sent mails to the announce mailing list (tssss, working on it), I took the freedom to
It's always nice to find out that your own stuff is broken ;-)
start with a post on news.opensuse.org. The post is not published yet, so feel free to enhance it with comments here on this list - I will integrate them and release the post to the wild as soon as possible (maybe together with the announcement email).
In general, the article looks good. Nevertheless, I found some small bugs ;-) In the first paragraph, I'd mention Provo to avoid that the admins in Nürnberg, including you, also get blamed by people who don't read the full article. Second paragraph: ... and we_'d_ like to share some of the results here to inform everyone ____ and actively ask for help. (we -> we'd, and drop "about the results" because that repeats the first half of the sentence) If you first want to know more about the status, read on… Meeting minutes openSUSE Heroes, 2016-06-26 Participants: cboltz, orangecms, adalovelace, ganglia, wnereiz, mcaj, lrupp looks a bit too formal and might scare away readers. What about If you first want to know more about the status, read on what the openSUSE Heroes discussed in their first meeting on 2016-06-26 (Participants: cboltz, orangecms, adalovelace, ganglia, wnereiz, mcaj, lrupp) The "Topics:" overview looks superfluous to me - this is a blog post, not a book ;-) In the "lrupp offered the following" section, you should add a bullet point saying The new hardware will be hosted in the Provo data center because we have rack space and bandwidth available there. In the last item in the "Provo" section: a long term goal is to make the english openSUSE wiki usable as “commons” ___, so ... (drop the first "again" because we never had a "commons" before) Also, the headlines need some change. The easiest way is probably: - change "1. Provo" to "Current situation" or "Current situation with Provo admins" (something like that as long as it isn't only "Provo") - add another headline above "So the team wants". That headline could be "Plans, tasks and solutions" - the "Organization and Communication" headline looks good (but I'd drop the number in front of it) Oh, and you should include a direct link to the "Provo" project on progress.o.o. The tickets there are public and a nice way to show what we are doing and where help is welcome.
...and yes: someone with more design talent can sent me an updated heroes logo at any time ;-)
Your design talent looks better than mine ;-) - but I noticed some slightly wrong green left of the geeko head. It looks like you painted over something with the wrong color. Can you send me the picture in the original format (I'd guess GIMP xcf)? I can make it scalable (by converting it to SVG) so that we can use it everywhere without loosing quality. I also tend to use the Fifth Leg font [1] instead of a "normal" sans serif, but that's something we can easily change once it is a SVG. (If you insist on keeping the font, please also tell me which font you used ;-) I won't object if someone comes up with a better logo, but until then, I want to have a bug-free version of Lars' logo ;-) Regards, Christian Boltz [1] that's the font we use in the openSUSE logo -- It's too bad that the universities don't have the ability to teach common sense. :-) [Ken Schneider in opensuse-factory] -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
Hello,
Gesendet: Montag, 18. Juli 2016 um 22:56 Uhr
Von: "Christian Boltz"
I took the freedom and subscribed everyone who participated in the openSUSE Admin meeting last month to this brand new list.
:-) :.)
While it seems like I'm not able any more to sent mails to the announce mailing list (tssss, working on it), I took the freedom to
It's always nice to find out that your own stuff is broken ;-)
start with a post on news.opensuse.org. The post is not published yet, so feel free to enhance it with comments here on this list - I will integrate them and release the post to the wild as soon as possible (maybe together with the announcement email).
In general, the article looks good. Nevertheless, I found some small bugs ;-) That looks good. But our meeting is some time ago... We should tell about our status, too. In the first paragraph, I'd mention Provo to avoid that the admins in Nürnberg, including you, also get blamed by people who don't read the full article. Second paragraph: ... and we_'d_ like to share some of the results here to inform everyone ____ and actively ask for help. (we -> we'd, and drop "about the results" because that repeats the first half of the sentence) If you first want to know more about the status, read on… Meeting minutes openSUSE Heroes, 2016-06-26 Participants: cboltz, orangecms, adalovelace, ganglia, wnereiz, mcaj, lrupp looks a bit too formal and might scare away readers. What about If you first want to know more about the status, read on what the openSUSE Heroes discussed in their first meeting on 2016-06-26 (Participants: cboltz, orangecms, adalovelace, ganglia, wnereiz, mcaj, lrupp) The "Topics:" overview looks superfluous to me - this is a blog post, not a book ;-) In the "lrupp offered the following" section, you should add a bullet point saying The new hardware will be hosted in the Provo data center because we have rack space and bandwidth available there. In the last item in the "Provo" section: a long term goal is to make the english openSUSE wiki usable as “commons” ___, so ... (drop the first "again" because we never had a "commons" before) Also, the headlines need some change. The easiest way is probably: - change "1. Provo" to "Current situation" or "Current situation with Provo admins" (something like that as long as it isn't only "Provo") - add another headline above "So the team wants". That headline could be "Plans, tasks and solutions" - the "Organization and Communication" headline looks good (but I'd drop the number in front of it) Oh, and you should include a direct link to the "Provo" project on progress.o.o. The tickets there are public and a nice way to show what we are doing and where help is welcome.
...and yes: someone with more design talent can sent me an updated heroes logo at any time ;-)
Your design talent looks better than mine ;-) - but I noticed some slightly wrong green left of the geeko head. It looks like you painted over something with the wrong color. Can you send me the picture in the original format (I'd guess GIMP xcf)? I can make it scalable (by converting it to SVG) so that we can use it everywhere without loosing quality. I also tend to use the Fifth Leg font [1] instead of a "normal" sans serif, but that's something we can easily change once it is a SVG. (If you insist on keeping the font, please also tell me which font you used ;-) I won't object if someone comes up with a better logo, but until then, I want to have a bug-free version of Lars' logo ;-) Regards, Christian Boltz How about a "3. Status" with: 1. Our wiki page is updated:https://en.opensuse.org/openSUSE:Services_team 2. Our mailing list as a communication channel is created: heroes@opensuse.org 3. The offer for the hardware order will be approved now. 4. After getting the hardware we can start with the setup. Best regards, Sarah -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
I have to edit something, because we have got a new status. :-)
Gesendet: Dienstag, 19. Juli 2016 um 08:33 Uhr
Von: "Sarah-Julia Kriesch"
I took the freedom and subscribed everyone who participated in the openSUSE Admin meeting last month to this brand new list.
:-) :-)
While it seems like I'm not able any more to sent mails to the announce mailing list (tssss, working on it), I took the freedom to
It's always nice to find out that your own stuff is broken ;-)
start with a post on news.opensuse.org. The post is not published yet, so feel free to enhance it with comments here on this list - I will integrate them and release the post to the wild as soon as possible (maybe together with the announcement email).
In general, the article looks good. Nevertheless, I found some small bugs ;-) That looks good. But our meeting is some time ago... We should tell about our status, too. In the first paragraph, I'd mention Provo to avoid that the admins in Nürnberg, including you, also get blamed by people who don't read the full article. Second paragraph: ... and we_'d_ like to share some of the results here to inform everyone ____ and actively ask for help. (we -> we'd, and drop "about the results" because that repeats the first half of the sentence) If you first want to know more about the status, read on… Meeting minutes openSUSE Heroes, 2016-06-26 Participants: cboltz, orangecms, adalovelace, ganglia, wnereiz, mcaj, lrupp looks a bit too formal and might scare away readers. What about If you first want to know more about the status, read on what the openSUSE Heroes discussed in their first meeting on 2016-06-26 (Participants: cboltz, orangecms, adalovelace, ganglia, wnereiz, mcaj, lrupp) The "Topics:" overview looks superfluous to me - this is a blog post, not a book ;-) In the "lrupp offered the following" section, you should add a bullet point saying The new hardware will be hosted in the Provo data center because we have rack space and bandwidth available there. In the last item in the "Provo" section: a long term goal is to make the english openSUSE wiki usable as “commons” ___, so ... (drop the first "again" because we never had a "commons" before) Also, the headlines need some change. The easiest way is probably: - change "1. Provo" to "Current situation" or "Current situation with Provo admins" (something like that as long as it isn't only "Provo") - add another headline above "So the team wants". That headline could be "Plans, tasks and solutions" - the "Organization and Communication" headline looks good (but I'd drop the number in front of it) Oh, and you should include a direct link to the "Provo" project on progress.o.o. The tickets there are public and a nice way to show what we are doing and where help is welcome.
...and yes: someone with more design talent can sent me an updated heroes logo at any time ;-)
Your design talent looks better than mine ;-) - but I noticed some slightly wrong green left of the geeko head. It looks like you painted over something with the wrong color. Can you send me the picture in the original format (I'd guess GIMP xcf)? I can make it scalable (by converting it to SVG) so that we can use it everywhere without loosing quality. I also tend to use the Fifth Leg font [1] instead of a "normal" sans serif, but that's something we can easily change once it is a SVG. (If you insist on keeping the font, please also tell me which font you used ;-) I won't object if someone comes up with a better logo, but until then, I want to have a bug-free version of Lars' logo ;-) Regards, Christian Boltz How about a "3. Status" with: 1. Our wiki page is updated:https://en.opensuse.org/openSUSE:Services_team[https://en.opensuse.org/openSUSE:Services_team] 2. Our mailing list as a communication channel is created: heroes@opensuse.org 3. The hardware is ordered and will arrive in the first week of August 2016. 4. After getting the hardware we can start with the setup. Best regards, Sarah -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
Hi On Mon, 18 Jul 2016 22:56:36 +0200 Christian Boltz wrote:
In the first paragraph, I'd mention Provo to avoid that the admins in Nürnberg, including you, also get blamed by people who don't read the full article.
I see this a bit different - maybe because I'm working here... From my point, we are *one* team, even if we are distributed across countries and even companies. If one fails, the other ones might at the moment not be able to step in - but who from the outside cares if it's "they" or "we"? Guess someone breaks in to one of my machines. Would it be my fault? Yes. Would the community (and not only the openSUSE community) see it as "my" personal fault - or would they see it as "IT" fault in general? I'm fine with blaming inside the team, but to the outside we should become - and react - as one team. Nothing else matters ;-)
Second paragraph: ... and we_'d_ like to share some of the results here to inform everyone ____ and actively ask for help. (we -> we'd, and drop "about the results" because that repeats the first half of the sentence)
Correct, fixed.
If you first want to know more about the status, read on… Meeting minutes openSUSE Heroes, 2016-06-26 Participants: cboltz, orangecms, adalovelace, ganglia, wnereiz, mcaj, lrupp
looks a bit too formal and might scare away readers.
What about
If you first want to know more about the status, read on what the openSUSE Heroes discussed in their first meeting on 2016-06-26 (Participants: cboltz, orangecms, adalovelace, ganglia, wnereiz, mcaj, lrupp)
Good idea - done.
The "Topics:" overview looks superfluous to me - this is a blog post, not a book ;-)
removed
In the "lrupp offered the following" section, you should add a bullet point saying The new hardware will be hosted in the Provo data center because we have rack space and bandwidth available there.
done.
In the last item in the "Provo" section: a long term goal is to make the english openSUSE wiki usable as “commons” ___, so ... (drop the first "again" because we never had a "commons" before)
ok
Also, the headlines need some change. The easiest way is probably: - change "1. Provo" to "Current situation" or "Current situation with Provo admins" (something like that as long as it isn't only "Provo") - add another headline above "So the team wants". That headline could be "Plans, tasks and solutions" - the "Organization and Communication" headline looks good (but I'd drop the number in front of it)
done
Oh, and you should include a direct link to the "Provo" project on progress.o.o. The tickets there are public and a nice way to show what we are doing and where help is welcome.
done
Can you send me the picture in the original format (I'd guess GIMP xcf)? I can make it scalable (by converting it to SVG) so that we can use it everywhere without loosing quality.
might do - but I guess it's better to use git for this? Just tell me where we should host that stuff ... With kind regards, Lars -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
Hi On Tue, 19 Jul 2016 18:05:25 +0200 Sarah-Julia Kriesch wrote:
How about a "3. Status" with: 1. Our wiki page is updated:https://en.opensuse.org/openSUSE:Services_team[https://en.opensuse.org/openSUSE:Services_team] 2. Our mailing list as a communication channel is created: heroes@opensuse.org 3. The hardware is ordered and will arrive in the first week of August 2016. 4. After getting the hardware we can start with the setup.
done (as 4 looks similar like 3 to me, I took the freedom to add another point ;-) Regards, Lars -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
Hello, Am Dienstag, 19. Juli 2016, 18:14:18 CEST schrieb Lars Vogdt:
On Mon, 18 Jul 2016 22:56:36 +0200 Christian Boltz wrote:
In the first paragraph, I'd mention Provo to avoid that the admins in Nürnberg, including you, also get blamed by people who don't read the full article.
I see this a bit different - maybe because I'm working here... From my point, we are *one* team, even if we are distributed across countries and even companies. If one fails, the other ones might at the moment not be able to step in - but who from the outside cares if it's "they" or "we"?
Well, if "they" actively refused to give you access to that machine, it would be unfair to say "we" failed. My opinion would differ if the problem would be "nobody asked for access" or "this thing looks like magic, I don't understand it and therefore can't fix it". Yes, this sounds like inside view again ;-) but I'd also apply it to the outside this way. Also, I'm sure people reading the -project or -wiki mailinglist will know who to blame for the wiki problems in the last months anyway ;-)
Guess someone breaks in to one of my machines. Would it be my fault? Yes. Would the community (and not only the openSUSE community) see it as "my" personal fault - or would they see it as "IT" fault in general?
That might depend - if you did a really silly thing (let's say a passwordless root account with SSH open to the public), it could become a personal blame. But in general, yes, "IT" would be blamed.
I'm fine with blaming inside the team, but to the outside we should become - and react - as one team. Nothing else matters ;-)
I probably had (and still have) too much "fun" with the Provo admins to agree completely ;-) - but you have good arguments, so I'm fine with keeping the blaming anonymous to the outside. [snip] Thanks for updating the news article, and also thanks to Sarah. Adding the latest news is a very good idea and shows that the light at the end of the tunnel really exists ;-)
Can you send me the picture in the original format (I'd guess GIMP xcf)? I can make it scalable (by converting it to SVG) so that we can use it everywhere without loosing quality.
might do - but I guess it's better to use git for this?
If you really want your version in git (instead of a bug-free SVG version), go ahead ;-) - but since I'll probably delete the GIMP xcf file after converting it to SVG, I'd say sending it by mail is enough ;-) But well, you could always refer to my commit message in AppArmor bzr r3022 (just quoting the relevant line): - now that write_net_rules() got fixed, drop it ;-)
Just tell me where we should host that stuff ...
I'd say somewhere[tm] on github. The "somewhere" is the interesting part: - a repo for just one file looks exaggerated, which leads to the question if we'll have more files to store in the future (I'm not talking about Salt-related files etc. , they are a completely different topic.) - maybe we can find a place in the openSUSE artwork repo? - another option could be to upload it to the wiki because we'll probably need it there anyway ;-) and also get a versioned history That said: please don't wait for a decision on this before sending me the logo. Experience shows that such "simple" detail questions can take quite some time ;-) BTW: I just noticed that lists.opensuse.org doesn't have your initial "Welcome!" mail. Is there a chance to get this fixed, or would it be too much effort? Oh, and I wanted to ask about the plans for status.o.o - but then noticed that they are already documented in the HTML sources ;-) (and look good, at least on the first view) Regards, Christian Boltz -- Re: [bulk]: Re: [bulk]: Re: [bulk]: Re: [bulk]: Re: [bulk]: Re: [bulk]:
So ungefähr sieht die Betreff-Leiste Aus, wenn der Re: [bulk]: Re: [bulk]: Blödsinn noch 'ne Weile weitergeführt wird. Die Leute wollten vermutlich nur das ebenso schwachsinnige Subject "AW: AW: AW: AW: AW:" der letzten Tage uebertreffen ;-) [Martin Falley und Thomas Hertweck in suse-linux]
-- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
Hello,
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".
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...
Best regards,
Sarah
Gesendet: Dienstag, 19. Juli 2016 um 20:50 Uhr
Von: "Christian Boltz"
On Mon, 18 Jul 2016 22:56:36 +0200 Christian Boltz wrote:
In the first paragraph, I'd mention Provo to avoid that the admins in Nürnberg, including you, also get blamed by people who don't read the full article.
I see this a bit different - maybe because I'm working here... From my point, we are *one* team, even if we are distributed across countries and even companies. If one fails, the other ones might at the moment not be able to step in - but who from the outside cares if it's "they" or "we"?
Well, if "they" actively refused to give you access to that machine, it would be unfair to say "we" failed. My opinion would differ if the problem would be "nobody asked for access" or "this thing looks like magic, I don't understand it and therefore can't fix it". Yes, this sounds like inside view again ;-) but I'd also apply it to the outside this way. Also, I'm sure people reading the -project or -wiki mailinglist will know who to blame for the wiki problems in the last months anyway ;-)
Guess someone breaks in to one of my machines. Would it be my fault? Yes. Would the community (and not only the openSUSE community) see it as "my" personal fault - or would they see it as "IT" fault in general?
That might depend - if you did a really silly thing (let's say a passwordless root account with SSH open to the public), it could become a personal blame. But in general, yes, "IT" would be blamed.
I'm fine with blaming inside the team, but to the outside we should become - and react - as one team. Nothing else matters ;-)
I probably had (and still have) too much "fun" with the Provo admins to agree completely ;-) - but you have good arguments, so I'm fine with keeping the blaming anonymous to the outside. [snip] Thanks for updating the news article, and also thanks to Sarah. Adding the latest news is a very good idea and shows that the light at the end of the tunnel really exists ;-)
Can you send me the picture in the original format (I'd guess GIMP xcf)? I can make it scalable (by converting it to SVG) so that we can use it everywhere without loosing quality.
might do - but I guess it's better to use git for this?
If you really want your version in git (instead of a bug-free SVG version), go ahead ;-) - but since I'll probably delete the GIMP xcf file after converting it to SVG, I'd say sending it by mail is enough ;-) But well, you could always refer to my commit message in AppArmor bzr r3022 (just quoting the relevant line): - now that write_net_rules() got fixed, drop it ;-)
Just tell me where we should host that stuff ...
I'd say somewhere[tm] on github. The "somewhere" is the interesting part: - a repo for just one file looks exaggerated, which leads to the question if we'll have more files to store in the future (I'm not talking about Salt-related files etc. , they are a completely different topic.) - maybe we can find a place in the openSUSE artwork repo? - another option could be to upload it to the wiki because we'll probably need it there anyway ;-) and also get a versioned history That said: please don't wait for a decision on this before sending me the logo. Experience shows that such "simple" detail questions can take quite some time ;-) BTW: I just noticed that lists.opensuse.org doesn't have your initial "Welcome!" mail. Is there a chance to get this fixed, or would it be too much effort? Oh, and I wanted to ask about the plans for status.o.o - but then noticed that they are already documented in the HTML sources ;-) (and look good, at least on the first view) Regards, Christian Boltz -- Re: [bulk]: Re: [bulk]: Re: [bulk]: Re: [bulk]: Re: [bulk]: Re: [bulk]:
So ungefähr sieht die Betreff-Leiste Aus, wenn der Re: [bulk]: Re: [bulk]: Blödsinn noch 'ne Weile weitergeführt wird. Die Leute wollten vermutlich nur das ebenso schwachsinnige Subject "AW: AW: AW: AW: AW:" der letzten Tage uebertreffen ;-) [Martin Falley und Thomas Hertweck in suse-linux]
-- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
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
Gesendet: Mittwoch, 20. Juli 2016 um 14:49 Uhr
Von: "Christian Boltz"
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/ ;-) That can happen, if the SCRUM Master does a bad job... Resposibilities of a SCRUM Master in a Sysadmin Team: - priorizing the tickets ( can be done by the team lead, too) - monitoring escalations, critical tickets,... and bringing them into the Daily - motivating the SCRUM team for team work - finding solutions in problem situations (with others in the team) - looking that all are doing their job If the Daily is interesting and all team members want to do a good job (in the team!), something like that above doesn't happen. 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) I hope that's enough for Lars for bringing new admin policies for the Provo admins on the table... Needless to say: feel free to forward this to whoever is responsible for the workflow in the Provo admin team ;-) Provo admins are part of the Sysadmin team and Lars is the team lead. But they are in another country. Craig has got the best contact to the management level in Provo (and should have assigned this mailing list). He can tell us who should get it. But Lars has to say a "Yes" or "No" for changing the Admin Policies in Provo. ;-) 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[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[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 -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
Hi Sarah I'm not sure if it just affects me, but your Mailer seems not to be really "quoting friendly" - at least I can not really distinguish between your answers and the text that you quote. So sorry if I miss something. But I like to take the opportunity to start an explanation about the openSUSE infrastructure history and my role in that. So lean back and enjoy - maybe we can re-use parts of this email later somewhere ;-) On Thu, 21 Jul 2016 08:23:05 +0200 Sarah-Julia Kriesch wrote:
I hope that's enough for Lars for bringing new admin policies for the Provo admins on the table...
I'm sorry, but this is something for the openSUSE heroes and not for a single person. Even if I'm willing to distribute whatever we declare as policy and act as an benevolent dictator for the openSUSE heroes, we should discuss first if the current policy works: * https://en.opensuse.org/openSUSE:Infrastructure_policy ...or if there is something missing (or even outdated, like the use of admin@o.o). We might also discuss if WE need some team rules? From my POW we should not only discuss about the "team structure" but also about some internal rules, starting with the areas of expertise AND the area of responsibilities - including a list of services that are currently unmaintained. I know that most of this can only be delivered by me or my team, as we are the main openSUSE admins at the moment. I guess Gerhard can help here with a list of the current services running under the "openSUSE umbrella". BUT My main question/concern at the moment is where to store all the bits and pieces to make them easy to find and maintain. With hundreds of wiki pages - some of them translated, some not - it's not easy even for me to keep an overview about things going on. So if we say "put everything in the wiki", I like to get an idea about the planned wiki structure first. Or maybe we find/decide to use another place to have "our" documentation (which one?) stored? Examples: We have https://en.opensuse.org/openSUSE:Services_team which is now a mix of an old page (started in December 2010 !) together with some more up-to date content as "starting page". Thanks to Sarah for the update, btw. On the other hand, we have: https://en.opensuse.org/Category:Infrastructure containing some more or less infrastructure related pages. I like the mediawiki Categories to put different pages with different topics together under one topic to make them easily findable - but others might see it different. ...and while I'm not really sure if it's needed, https://en.opensuse.org/Portal:Infrastructure is completely missing. But I never understood the "Portal" stuff in mediawiki, so maybe I'm wrong here asking for such a page. These are just 3 examples for the English wiki. But there is more: * https://status.opensuse.org/ - should become "the" information page about (planned) outages and problems - and Gerhard is working hard to get this page up and running (what is missing from your side, btw? Maybe we should collect/document the "wish-list" somewhere?) * https://progress.opensuse.org/ - started as "project management tool" for us together with the former "boosters" team and the openSUSE board. Now openQA, the openSUSE release-managers and even the oSC 2015 team have also "their" projects there. The wiki provided in Redmine might IMHO be a good choice for "our" documentation - but on the other side this needs to be agreed inside our team and documented also in the "official wiki". * https://gitlab.opensuse.org/ is another interesting point for discussion: at the moment, the permissions are restrictive as we plan to store all the configuration stuff there (Salt). Maybe Theo can start with some descriptive text "somewhere" about our (directory) structure there, about the workflow, how to participate, ... * ... and there are probably more pages somewhere outside that are of interest *just* for potential openSUSE admins (Forums? More?). The problem is just that only a very limited subset of people know about them and even less Admins really document their work. But if we - right now - don't change that, I fear that in a few weeks everything will be as before...
Provo admins are part of the Sysadmin team and Lars is the team lead.
No. Sorry. This is wrong. I'm responsible for some (~10) people inside SUSE R&D - but SUSE itself is just one part of Micro Focus. A company with more than 4,500 employees around the world. The so called "Provo admins" are part of the Micro Focus IT, which is not only another team: it's a complete other business unit with different stakeholders and (business) interests.
But Lars has to say a "Yes" or "No" for changing the Admin Policies in Provo. ;-)
There is no "yes or no". I don't like - and must not - change any policy in Provo or anywhere else in the "MF-IT" world. Please understand that I'm "just" (as you) someone from the openSUSE community there who can ask questions and request some help. It might be that my social network there is a bit better at the moment, but that's not the point: WE are the openSUSE admins - there is no hidden amount of people working in some back office to keep all the machines, networks and storage up and running. SUSE sponsored some machines here and there - and some guys from my team volunteered to administrate some openSUSE services in the past as nobody else did. From time to time there are others who step by and offer there help - sometimes successful, sometimes not. That's one of the reasons why I want to have the openSUSE infrastructure handled in a way that allows external volunteers to join and help with the daily business of such a beast. From my past (and current) point of view, we just did not want to maintain PHP applications inside my team. That was the reason why all this stuff is currently hosted in Provo: because some (former) MF-IT admins there volunteered to help and maintain it. ...and that's how it works: if there is some volunteer who is really DOING something, he/she is the one making decisions. That's how it works inside openSUSE and many other open source projects. Our infrastructure problem is in the missing policies and documentation. So nobody really knows if something is possible or not - and if a volunteer looses interest, there is currently nobody else than people from the openSUSE heroes who step in to get the service up and running. Something I like to change ... This mail is already too long (sorry for that and thanks for reading ;-) so I like to close here and wait for your questions and discussion points... With kind regards, Lars -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
On Tue, Jul 26, 2016 at 11:53:53AM +0200, Lars Vogdt wrote:
Examples: We have https://en.opensuse.org/openSUSE:Services_team which is now a mix of an old page (started in December 2010 !) together with some more up-to date content as "starting page". Thanks to Sarah for the update, btw.
One idea would be to keep this page describing the ops-services team (with internal policies and info), and create a new page (eg openSUSE:Admininstration_team or openSUSE:Heroes) with information about the heroes team
...and while I'm not really sure if it's needed, https://en.opensuse.org/Portal:Infrastructure is completely missing. But I never understood the "Portal" stuff in mediawiki, so maybe I'm wrong here asking for such a page.
Not really needed imho
* https://gitlab.opensuse.org/ is another interesting point for discussion: at the moment, the permissions are restrictive as we plan to store all the configuration stuff there (Salt). Maybe Theo can start with some descriptive text "somewhere" about our (directory) structure there, about the workflow, how to participate, ...
The salt work hasn't started yet (any volunteers are welcome btw). But I have a
very extensive documentation about the puppet infrastructure (that is still
running unfortunately)
https://progress.opensuse.org/projects/opensuse-admin/wiki#Puppet
Keep in mind that it needs quite minor adjustments to describe the upcoming
salt infrastructure
--
Theo Chatzimichos
Hi Sarah
I'm not sure if it just affects me, but your Mailer seems not to be really "quoting friendly" - at least I can not really distinguish between your answers and the text that you quote. So sorry if I miss something. Sorry! I have found a solution.
But I like to take the opportunity to start an explanation about the openSUSE infrastructure history and my role in that. So lean back and enjoy - maybe we can re-use parts of this email later somewhere ;-)
On Thu, 21 Jul 2016 08:23:05 +0200 Sarah-Julia Kriesch wrote:
I hope that's enough for Lars for bringing new admin policies for the Provo admins on the table...
I'm sorry, but this is something for the openSUSE heroes and not for a single person. You are right. Creating the policy is the job of the team. But you are
Hi Lars, Am Dienstag, den 26.07.2016, 11:53 +0200 schrieb Lars Vogdt: the teamlead and have to approve that all.
Even if I'm willing to distribute whatever we declare as policy and act as an benevolent dictator for the openSUSE heroes, we should discuss first if the current policy works: * https://en.opensuse.org/openSUSE:Infrastructure_policy ...or if there is something missing (or even outdated, like the use of admin@o.o). We might also discuss if WE need some team rules?
From my POW we should not only discuss about the "team structure" but also about some internal rules, starting with the areas of expertise AND the area of responsibilities - including a list of services that are currently unmaintained. I know that most of this can only be delivered by me or my team, as we are the main openSUSE admins at the moment. I guess Gerhard can help here with a list of the current services running under the "openSUSE umbrella".
BUT
My main question/concern at the moment is where to store all the bits and pieces to make them easy to find and maintain. With hundreds of wiki pages - some of them translated, some not - it's not easy even for me to keep an overview about things going on. So if we say "put everything in the wiki", I like to get an idea about the planned wiki structure first. Or maybe we find/decide to use another place to have "our" documentation (which one?) stored?
Examples: We have https://en.opensuse.org/openSUSE:Services_team which is now a mix of an old page (started in December 2010 !) together with some more up-to date content as "starting page". Thanks to Sarah for the update, btw.
On the other hand, we have: https://en.opensuse.org/Category:Infrastructure containing some more or less infrastructure related pages. I like the mediawiki Categories to put different pages with different topics together under one topic to make them easily findable - but others might see it different. You are right. And that's standard to do it so...
...and while I'm not really sure if it's needed, https://en.opensuse.org/Portal:Infrastructure is completely missing. But I never understood the "Portal" stuff in mediawiki, so maybe I'm wrong here asking for such a page. You have got 2 wiki admins on this mailing list. :-) Portals are the main page for teams and openSUSE sub projects. There is a small description about it, what would be to do and there should be a
That's our main page of the team at the moment. list with all wiki pages for the special category on the right side. Most important topics are linked there, too.
These are just 3 examples for the English wiki. But there is more:
* https://status.opensuse.org/ - should become "the" information page about (planned) outages and problems - and Gerhard is working hard to get this page up and running (what is missing from your side, btw? Maybe we should collect/document the "wish-list" somewhere?)
* https://progress.opensuse.org/ - started as "project management tool" for us together with the former "boosters" team and the openSUSE board. Now openQA, the openSUSE release-managers and even the oSC 2015 team have also "their" projects there. The wiki provided in Redmine might IMHO be a good choice for "our" documentation - but on the other side this needs to be agreed inside our team and documented also in the "official wiki".
* https://gitlab.opensuse.org/ is another interesting point for discussion: at the moment, the permissions are restrictive as we plan to store all the configuration stuff there (Salt). Maybe Theo can start with some descriptive text "somewhere" about our (directory) structure there, about the workflow, how to participate, ...
* ... and there are probably more pages somewhere outside that are of interest *just* for potential openSUSE admins (Forums? More?). The problem is just that only a very limited subset of people know about them and even less Admins really document their work. But if we - right now - don't change that, I fear that in a few weeks everything will be as before...
That's the problem at the moment! We can't get the information where help will be needed (outside of SUSE) at the moment. That isn't documented anywhere... If nothing is changed in the next weeks, I can tell about the Fedora Infrastructure team and their structure. One of my last colleagues is a Member there. We can do what is working in other communitys, too. They have got weekly meetings for discussions and don't document "all" in the wiki. They tell about the first steps and what would be needed. They have got a status page with a list of all systems, too. You can't see only problems. You can see all systems there. So you can see all parts of the infrastructure. If somebody wants to join, he writes a mail and joins to the meeting where he can get tasks. The system administration is splitted into Application Management and System Administration.
Provo admins are part of the Sysadmin team and Lars is the team lead.
No. Sorry. This is wrong. I'm responsible for some (~10) people inside SUSE R&D - but SUSE itself is just one part of Micro Focus. A company with more than 4,500 employees around the world. The so called "Provo admins" are part of the Micro Focus IT, which is not only another team: it's a complete other business unit with different stakeholders and (business) interests.
On Mon, 18 Jul 2016 22:56:36 +0200 Christian Boltz wrote:> > In the first paragraph, I'd mention Provo to avoid that the admins
in> > Nürnberg, including you, also get blamed by people who don't read the> > full article.> I see this a bit different - maybe because I'm working here... From my> point, we are *one* team, even if we are distributed across countries> and even companies. If one fails, the other ones might at
Sorry for misunderstanding. But you gainsay yourselve in your last mail with: Am Dienstag, den 19.07.2016, 18:14 +0200 schrieb Lars Vogdt:> Hi> the moment
not> be able to step in - but who from the outside cares if it's "they" or> "we"?>
But Lars has to say a "Yes" or "No" for changing the Admin Policies in Provo. ;-)
There is no "yes or no". I don't like - and must not - change any policy in Provo or anywhere else in the "MF-IT" world. Please understand that I'm "just" (as you) someone from the openSUSE community there who can ask questions and request some help. It might be that my social network there is a bit better at the moment, but that's not the point:
WE are the openSUSE admins - there is no hidden amount of people working in some back office to keep all the machines, networks and storage up and running.
That's it what Christian and I weren't able to see any more and wanted to fix it... We looked after people from Provo at the oSC and asked Craig, whether he can do something there. He has got the best connections in Provo we need. We only must "want to" do it. Many people/ managers can push more than one person alone. I did that in the last company, if I wanted to change something in a workflow or in a structure, too.
SUSE sponsored some machines here and there - and some guys from my team volunteered to administrate some openSUSE services in the past as nobody else did. From time to time there are others who step by and offer there help - sometimes successful, sometimes not.
That's one of the reasons why I want to have the openSUSE infrastructure handled in a way that allows external volunteers to join and help with the daily business of such a beast. From my past (and current) point of view, we just did not want to maintain PHP applications inside my team. That was the reason why all this stuff is currently hosted in Provo: because some (former) MF-IT admins there volunteered to help and maintain it.
...and that's how it works: if there is some volunteer who is really DOING something, he/she is the one making decisions. That's how it works inside openSUSE and many other open source projects.
Our infrastructure problem is in the missing policies and documentation. So nobody really knows if something is possible or not - and if a volunteer looses interest, there is currently nobody else than people from the openSUSE heroes who step in to get the service up and running. Something I like to change ...
This mail is already too long (sorry for that and thanks for reading ;-) so I like to close here and wait for your questions and discussion points...
With kind regards, Lars That isn't too long. We are new in the team and need the information. ; -)
Best regards, Sarah -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
Am Dienstag, den 26.07.2016, 12:09 +0200 schrieb Theo Chatzimichos:
On Tue, Jul 26, 2016 at 11:53:53AM +0200, Lars Vogdt wrote:
Examples: We have https://en.opensuse.org/openSUSE:Services_team which is now a mix of an old page (started in December 2010 !) together with some more up-to date content as "starting page". Thanks to Sarah for the update, btw.
One idea would be to keep this page describing the ops-services team (with internal policies and info), and create a new page (eg openSUSE:Admininstration_team or openSUSE:Heroes) with information about the heroes team
We can do that. We have to specify the difference between both teams then.
...and while I'm not really sure if it's needed, https://en.opensuse.org/Portal:Infrastructure is completely missing. But I never understood the "Portal" stuff in mediawiki, so maybe I'm wrong here asking for such a page.
Not really needed imho
* https://gitlab.opensuse.org/ is another interesting point for discussion: at the moment, the permissions are restrictive as we plan to store all the configuration stuff there (Salt). Maybe Theo can start with some descriptive text "somewhere" about our (directory) structure there, about the workflow, how to participate, ...
The salt work hasn't started yet (any volunteers are welcome btw). But I have a very extensive documentation about the puppet infrastructure (that is still running unfortunately) https://progress.opensuse.org/projects/opensuse-admin/wiki#Puppet Keep in mind that it needs quite minor adjustments to describe the upcoming salt infrastructure
The work with Salt hasn't started yet? Why did Lars told about a wiki setup with Salt and why was told at the conference about SUSE with Salt? I have got knowledge in Puppet, ansible and fabric. Automation is my job at the moment. October I will be full time student and I don't want to leave this area. I would join you after the wiki setup. Best regards, Sarah -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
On Fri, Jul 29, 2016 at 05:56:59PM +0200, Sarah Julia Kriesch wrote:
The work with Salt hasn't started yet? Why did Lars told about a wiki setup with Salt and why was told at the conference about SUSE with Salt? I have got knowledge in Puppet, ansible and fabric. Automation is my job at the moment. October I will be full time student and I don't want to leave this area. I would join you after the wiki setup.
There is a confusion here that I need to sort out: - The SUSE R&D production servers (plus a large part of not-so-production ones) internally in SUSE are already working with salt for almost a year. The code is very mature and there is a large list of needed improvements, which means that the openSUSE salt infrastructure is not going to start from scratch. - The openSUSE infrastructure was running on puppet for a couple of years, and is slowly migrating to salt. Right now we have the basic infrastructure ready, but only two servers are attached to the master. The code is also quite hardcoded to those two minions right now. - There is only documentation for Puppet right now. While some docs are tight to puppet, some others are not, and pretty much all of it can be easily migrated to salt. - I have no idea about what wiki setup you are referring to. So, the steps that need to be done are: 1) Make gitlab.opensuse.org available to the public network. This is action item for me and darix, and the blocker we have at the moment is that the openid library is not working. Next week I'm going to have it public either way though, either with local accounts, openid or ldap authentication. 2) Announce on this list the repository of salt, the deprecated puppet one plus the documentation. Also action item for me right after (1) will happen. 3) Action item for volunteers: Read the documentation, the code, the open tasks, and start contributing to our salt code (based on what we had on Puppet so far), via gitlab merge requests. 4) Connect all the openSUSE machines to the master as minions. Action item for me and darix. We need to define which machines will go there and which ones will stay on SUSE-employee access only. But even before all these happen, people can still help with salt. We are heavy users of saltstack-formulas [1], so you can make sure that they have openSUSE Leap and SLE12 support on their map.jinja, eg [2]. Another example would be to help us on packaging, there has been a new release yesterday which is still not packaged. Or if you are already a salt user, feel free to ping me on IRC to share our codebases and brainstorm. [1] https://github.com/saltstack-formulas [2] https://github.com/saltstack-formulas/dhcpd-formula/commit/27551f5cc8b1b890b... Theo
Hi On Fri, 29 Jul 2016 18:26:53 +0200 Theo Chatzimichos wrote:
- I have no idea about what wiki setup you are referring to.
That's my "fault": as Sarah and Christian want to re-setup all the wiki machines anyway, I suggested directly to start writing Salt profiles for them, so they can easily be integrated into the infrastructure later - even if they start with their local test-setup first.
1) Make gitlab.opensuse.org available to the public network. This is action item for me and darix, and the blocker we have at the moment is that the openid library is not working. Next week I'm going to have it public either way though, either with local accounts, openid or ldap authentication.
From my personal POW: as gitlab should only host stuff that affects our infrastructure or contains other, very sensitive information, I would not mind to go with completely separate accounts for this. Most of us will probably use their ssh-keys anyway and leave the UI where it is. It might make it a bit more complicated as all who need access have to maintain another account for the "openSUSE infrastructure work", but on the other way this gives us some additional security (thinking about not working remote authentication or hacked accounts).
But even before all these happen, people can still help with salt. We are heavy users of saltstack-formulas [1], so you can make sure that they have openSUSE Leap and SLE12 support on their map.jinja, eg [2]. Another example would be to help us on packaging, there has been a new release yesterday which is still not packaged. Or if you are already a salt user, feel free to ping me on IRC to share our codebases and brainstorm.
While I read about tasks: what about starting with some junior tasks already and cleaning up the tickets in progress, anyone ? :-) I guess we can collect additional jobs like: * Docu collector/writer * mailing list admin (technical, social) * IRC admin (technical, social) * contributor to status.o.o => https://github.com/openSUSE/status.o.o * admin/contributor to planet.o.o => https://github.com/openSUSE/planet.opensuse.org ...or any other repo on github.com/openSUSE ? with kind regards, Lars -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
On Fri, Jul 29, 2016 at 06:55:22PM +0200, Lars Vogdt wrote:
From my personal POW: as gitlab should only host stuff that affects our infrastructure or contains other, very sensitive information, I would not mind to go with completely separate accounts for this. Most of us will probably use their ssh-keys anyway and leave the UI where it is. It might make it a bit more complicated as all who need access have to maintain another account for the "openSUSE infrastructure work", but on the other way this gives us some additional security (thinking about not working remote authentication or hacked accounts).
The UI is still quite important as there is no (or no good) cli command to: - view build status - file merge request But in general I agree, on Monday I'm making it public no matter what.
While I read about tasks: what about starting with some junior tasks already and cleaning up the tickets in progress, anyone ? :-)
I guess we can collect additional jobs like: * Docu collector/writer * mailing list admin (technical, social) * IRC admin (technical, social) * contributor to status.o.o => https://github.com/openSUSE/status.o.o * admin/contributor to planet.o.o => https://github.com/openSUSE/planet.opensuse.org ...or any other repo on github.com/openSUSE ?
+1, that too! We already got IonutVan on #opensuse-admin the past days doing a
lot of bugwrangling, with the amazing result of fixing all planet tickets
(finally!). I just didn't mention it before as I focused on salt tasks
--
Theo Chatzimichos
participants (5)
-
Christian Boltz -
Lars Vogdt -
Sarah Julia Kriesch -
Sarah-Julia Kriesch
-
Theo Chatzimichos