On 22 Jul 2019, 12:24 +0100, Daniel Comnea <comnea dani gmail com>, wrote:
I totally agree with that but let's do a quick reality check taking example some IRC channels, shall we?
- ansible IRC channel doesn't log the conversation - does the comments  and  resonate with you? It does for me and that is a huge -1 from my side.
Yes that’s most unfortunate for #ansible.
- centos-devel/ centos channels doesn't log the conversation. Saying that for the centos meetings (i.e PaaS SIG) it get logged and is per SIG. That in itself is very useful however as a guy who was consuming the output for the last year as PaaS SIG chair/ member i will say is not appealing to go over the output if a meeting had high traffic (same way if you have a 6 hour meeting recording, will you watch it from A to Z ? ;) )
- fedora-coreos it does log  but if i'll turn every morning and see what has been discussed you see a lot of noise caused by who join/leave
#centos and #fedora could most certainly do better. We’re getting on to three months after RHEL8 release and no hint of CentOS8.
- openshift/ openshift-dev channels had something on  but does it still works ?
This is one point of my complaint.
All i'm trying to say with the above is:
Should we go with IRC as a form of communication we should then be ready to have bodies lined up to:
- look after and admin the IRC channels.
- enable the IRC log channels and also filter out the noise to be consumable (not just stream the logs somewhere and tick the box)
Easy enough. It’s been done time and again. Let’s give it a whirl. Since I’m the one complaining perhaps I can put my name in for consideration.
In addition to the channel logs, my main requirement is to access the IRC channels from any device and not lose track of what has been discussed.
A respected gentlemen involved in various opensource projects once wrote  and so with that i'd say:
- who will take on board the setup so everyone can benefit from it?
Again some options here, but most certainly doable with a little effort. #openshift-dev is advertised all over the place. https://www.okd.io/#contribute
If you swing to slack, i'd say:
- K8s slack is free in that neither you nor i/ others pay for it and everyone can join there
- OpenShift Common slack channel is also free, RH is paying the bill (another investment from their side) however as said Diane setup up that place initially with a different scope.
- once you logged in you can scroll back many months in the past
- you get ability to share code snippet -> in IRC you don't. You could argue that folks can use github gist or any pastebin service however the content can be deleted/ expired and so we go back to square one
Slack logs are not indexed by search engines. This prevents me from supporting it in its entirety. People have been sharing code snippets for decades on IRC. And, it’s worked fantastic. Just from my personal experience of Slack absorbing or repelling so much energy and collaboration from the community — of which no one can explain really — I don’t see it as a viable option given we have the numbers in front of us from this very project which undeniably shows it doesn’t work.
you also saying
- Slack with three threads per week
How is the traffic on fedora-coreos OR centos-devel channels going? Have you seen high volume ?
Why do you mention other projects and their traffic? #openshift-dev had incredible amounts of traffic which helped make it a success. Different channels have different attendance depending on a tremendous amount of factors. But, just when OCP emerged a champion of Kubernetes mindshare toward end of 2017 things went blank.
I think is unfair to say that, in reality even on the mentioned IRC channels we don't see much traffic. #ansible is an exception but that is because ansible core (no idea how many are RH employees vs the rest) devs do hang around there.
No reason #openshift-dev shouldn’t be the same. It once was.
At the end i think we need to take a step back and ask ourselves:
- who is involved in OKD?
- who is contributing - with tests, integration, docs, logistics etc etc (if i can use an analogy - help producing the wine)
- who is consuming it (the analogy - consuming/ drinking the wine)
- what is the scope of OKD based on the resources available ?
- does OKD afford/ have capacity for an Infra team to look after tools? any volunteers? :)
- is OKD community only on the consuming fence providing a bit of feedback to RH?
- where are the RH OpenShift devs hanging around? is OKD something which does appeal them and if so what is their main comms tool for OCP v4?
- the entry barrier should be as friction-less as possible otherwise no OpenShift developer will be active on slack and on IRC unless they are dedicated for community project.
- where is the place from where OKD community can recruit/ encourage / welcome / attract new folks to help out?
- is it IRC or is it Slack?
- is it dev mailer or is it something else?
- is the entry bar too high for folks to stay around and help ?
I completely agree. A lot of these things were not once easy to find, and aren’t still. There are bits and pieces around, and if you have nothing better to do than read the code — as if. If OKD made it easy to on board as a contributor, people would.
Many, many software projects began and became successful with IRC. I’ve personally seen Slack begin with the best of intentions at different places of business and end up being a regret.
Synchronous comms should be over IRC logged and indexed with asynchronous over mailing lists. This option has been repeatedly proven for many years and works.
Being truly transparent and following my PaaS SIG experience:
- when i took the baton to keep releasing the openshift-ansible/ origin rpms on CentOS repos we had 6+ folks, after 4 weeks we ended up with 3 guys hanging around.
- when we released 3.11 i've kept everyone up to date and informed, even asked for help with testing out the new rpms - silence, nobody showed on PaaS SIG meetings nor jumped on improving the CI but then on Github issues appeared - consuming vs contributing ;)
Note, i'm not saying all the above to take any credit (no need for that honestly!) just because i care, hence a serious assessment is needed to see what we have followed by a laser commitment to get OKD v4 out. Yes RH needs to drive because a) they will benefit from it IF there is a real community behind with useful feedback loop; b) in v4 the skill set required is no longer around ansible - is the MCO/ operating system; c) all the knowledge/ design docs created over the last 1y+ is on their side of the fence .. and through Clayton's voice they said they are doing .. but they are calling for help.
They key question is:
how many companies are willing to throw resources @OKD community ? time will tell ….
It’s really hard to judge companies participation — especially when there’s nothing for them to come to grips with. Many large companies which pony up the rich dosh for OCP don’t allow employees to contribute and/or pay for RH professional services to implement. Most small businesses or emerging tech companies are consuming AWS/Azure/GCP services as they are easy to consume, i.e. don’t require expensive engineers to build something that “works". Then, they come to realise server sprawl and incredible amount of over provisioning, and etc. Perhaps that is why IBM wanted Red Hat. They are implementing OpenShift in IBM Cloud.
Even so, I do provide services to very large organisations and well-funded startups that do have the resources and/or learned the lessons and are on the road to recovery. They are willing to allow their engineers to contribute as well as provide support for the project. But, the ability to enter takes too much and with a little effort can lowered well within reason. They are just one Google away from the community advertised on okd.io.
A lot of points we are discussing here I believe are quite obvious. You can easily look around and see there are many Slack regrets. It does have its place, but for the amount of information and culture we’ve come to expect with free software, it’s really just good for chit chat over coffee.