hpr-knowledge-base/hpr_transcripts/hpr2230.txt

Episode: 2230
Title: HPR2230: linux.conf.au 2017: Donna Benjamin
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr2230/hpr2230.mp3
Transcribed: 2025-10-18 16:16:11

---

This is HBR episode 2,230 entitled, Linux.com.0 2017, Non-Avengerment, and is part of the series,
Interviews.
It is hosted by Clinton Roy and is about 33 minutes long, and Karima Cleanflag.
The summary is, Clinton Interviews speaker, and previously Linux.com.0 organizer Non-Avengerment.
This episode of HBR is brought to you by an honesthost.com.
At 15% discount on all shared hosting with the offer code, HBR15, that's HBR15.
Better web hosting that's honest and fair at an honesthost.com.
Here we are on day 3 of Linux.com for you down in Hobart.
I am here with my friend, Donna Benjamin.
In the past, Donna has helped run a number of mini-cops and a number of tutorials.
I went all I know about Inkscape from a couple of the sessions that Donna has run on teaching Inkscape,
which have subsequently been very useful because I've ended up...
When you're organizing a conference, you end up doing 1,000 things that you've not actually expert at,
and designing graphics and stuff for things is one of those.
That was very useful.
I think it was last year.
You ran the leadership community leadership summit.
Community leadership summit X.
That's like a hangover from Ozcon or Ozcon or something.
The community leadership summit was founded by John O'Bacon,
and he runs it each year before Ozcon in the United States.
A couple of years back, he said that this could be distributed,
and he sort of copied the TEDx model.
We had TED talks, and then increasingly they were TEDx talks happening all around the world.
John O'Bacon invited other people to run community leadership summits in their part of the world.
I saw this call go out, and I thought, well, a mini-conf at Linuxconfay,
you would be a perfect place for such a CLSX event.
So, you know, and foolishly tweeted that and someone sort of...
Thanks for volunteering, though.
Yes, effectively.
So then I kind of cursed myself and agreed to run CLSX LCA.
Two years ago, I think now it was the first one in Auckland,
and again, last year.
And this year, I handed the baton to the fabulous VM,
who ran it on Monday.
So, oh, no, on Tuesday.
So, yeah, and I think it went well. I was quite sorry I wasn't there.
Oh, okay, right.
Yeah, I think it clashed with the hardware mini-conference,
and I paid to put a board together.
Yes.
It was not something I could mess unfortunately with.
And it also clashed with the free software law and policy mini-conference
that I was also assisting Deb Nicholson to run.
Yeah, I think I got a lot out of the leadership one,
but I think it's one of those things where...
Like, in all of these soft, squishy things,
I consider myself an engineer.
You know, I'm not an engineer because I do software.
I'm a pretend engineer.
And it's really easy when you're doing these things just to come up...
If you're solving a problem, you just come up with a list of pros and cons
and then you just sort of count.
And it's like, you know, which one is easy,
and if there's a decision to be made,
if there's a way to make that decision really easy to make,
or reversible, just do that one.
If only life was so easily reductive.
But the rest of life.
Yeah, when you're running a community group,
you can't, you know, oh, he's a decision point
where if I take one decision, it's going to impact this person.
If I take the other one, it's going to impact this person.
Which person do I like least?
And I'll make that decision.
That is not a good way of building a community.
So I think also, in those sort of things,
I sort of feel very comfortable being the icebreaker.
And so whenever there's a group discussion on,
and it's like, discuss the topic, who?
I'm more than happy to jump in
and do a random of what I'm feeling about that sort of thing.
The other side of it that I do really poorly, of course,
is actually listening to everyone else.
The listening part is really useful.
I went to a session today by Elizabeth Joseph,
who was talking about global communities.
And that was one of the things that she talked about
was the importance of listening,
and listening to people who are not like you.
People who are outside of your group,
particularly the users that she was working with,
they wanted to transition one piece of stuff there
while using for another one.
Well, this is just, this is what people will do.
And basically, that group of users sort of had a mutiny
and said, no, this won't do.
It's nowhere near good now.
And it won't help us do what we need to do.
So was that user group around that particular bit of software?
Or was it like they were just using that?
They were users of it.
So the context was that it was an open source project
and a host and it had a, you know, as a service component.
And the as a service component stopped being open source.
So this project, which was open source,
was community using open source software and set OK.
So we'll have to stop using that now.
And then the community around that,
who were using it as a tool to accomplish something particular,
well, none of these things that you're saying
you can use work the way we work, do what we need them to do,
et cetera, et cetera.
And so they had a really kind of, you know,
Frankenfields kind of series of conversations.
At some, it's getting fed together face to face
and really listening and understanding what those needs were.
And it ended up being a great outcome
because they did find another software project.
And then that project actually was able to listen to these
particular users needs.
And here the features that they needed to accomplish their work
had them added.
And then, you know, it became one of those awesome sorts of results.
But, like, just the effective communicating clearly
actually made the problem sort of much shallower
than it otherwise was.
Well, it resolved the problem from start, you know.
Whereas before it was an edict issued from an infrastructure team
saying, no, you just have to use the software.
And that was based on a principle of where an open source group
we should be using open source stuff.
It's perfectly logical ladder of steps to get to that conclusion.
Yep.
It's just that you had to throw people off the ladder
at every step to reach the top of it.
Something like that.
Something like that.
And so, yeah, that, you know, the squishy stuff,
I actually have a real, I'm increasingly having a visceral
revulsion to the term soft skills
because there's nothing soft or easy
about the human side of what we do.
I have said for a long time that the technical challenges
can usually be solved.
We may not have other resources that we need to solve them,
but there is usually some path forward.
The human challenges are often much more challenging
because sometimes they are intractable
and the solutions are not halitable.
Yeah, there's a talk this afternoon.
I think that I'm looking forward to handle conflict
like a box.
Oh, yes.
Deb Nicholson, who ran the free software law in policy,
will come for you.
Yeah, yeah.
And I think my sort of approach
is to pretty much what she's describing
is that if I see a bunch of little issues
in a group, I'll just sort of let them slide.
And you're not actually dealing,
like there is a conflict there.
Only one side of it knows that there's a conflict.
And then, you know, six, 12 months on,
all these things sort of bubble up and call us
and you have an explosion.
Yes.
And I think that talk will be very useful for someone like me.
Yeah, and I've seen a different version of that talk from Deb.
So I would highly, highly recommend going
because she's a great presenter and she knows her stuff.
And yeah, I've given a talk about conflict
at DrupalCon actually.
And one of the things I sort of say is
I think we need to rethink how we generally approach conflict.
There's generally, you know, terrible generalizations
but people will avoid conflict as a kind of default natural response
and do anything they can to avoid conflict.
It's trying to be polite.
It's trying to be polite.
And what I kind of want to say is let's embrace conflict
and talk about constructive conflict resolution.
And I say that if there is something
which is causing conflict,
it's actually an opportunity to make something a whole lot better.
If we think about conflicts as kind of the early warning stages
of a good bug report,
then we might be able to really change the way
that we tackle conflict to our communities.
It's like if there's something that's wrong
and we've basically created an environment
where we're not willing to accept a bug report,
we're never going to get the opportunity to fix what's wrong.
On the other hand, if we can address those small,
niggling, you know, splinters and paper cuts
and any irritations,
then we're more likely to be able to fix things
before they develop into kind of thermonuclear global health.
Yep, yep, yep.
And I think, like I think things like that,
it's not like it's useful at work,
it's useful in the open source crowd.
And I think, you know, there are situations where,
like if I'm at work and there's a little niggling thing,
you know, I've had a good night's sleep,
I've come into work fresh.
If I can't deal with it then,
how the heck am I going to deal with it after hours
where I've been at work for eight hours
and then I've gone home and I'm tired
and I'm trying to do open source stuff
on my own time,
all of my social capital,
I'm not quite using the right terms here,
but like, you know,
there's only so much crap you can take in a day
and that normally is used up
by like 10 through the morning.
So it's that, it's the cognitive load,
and cognitive calories in a way.
Kathy Sierra has lots of great stuff on this
and her recent book she talks about it.
There's a study that was done about giving a dog
an instruction to stay
and having the same dog be in a cage.
The dog that was in a cage
didn't need to use any cognitive resources
to stay where it was,
but the dog that was told to sit and stay
and wait used cognitive resources just to do that.
And, you know, there are other ones about how
when you give humans, you know,
this half of your audience two numbers to memorize
and this half of the audience five numbers to memorize
and then send them out to morning team
let them choose cake or fruit.
The people who only had to memorize two numbers
chose fruit more often
and the people who had to choose five numbers chose cake
because they will power their cognitive load
and have been eroded by having to do more work.
Now this, there's lots of science out there on this now
but we don't use this knowledge very often.
But what you're describing is, you know,
you're on your best behavior all day at work,
you've been dealing with issues,
you've been doing problem solving,
you've been, you know, doing all the awesome stuff
and then you get home and you're like,
ugh, and now you just like,
you don't hold back when you want us, you know,
spit at your, you know, housemate or, you know, etc.
and you're more likely to kind of let rip and not use
sort of social graces shall we say
and it's just cognitive load
and we have that in all sorts of other things.
And when we make our users just work harder than they need to
to accomplish their tasks,
they're likelihood of being frustrated
and not getting done what they want to get done
goes up because we're making them waste
cognitive resource on stuff that doesn't matter
as opposed to focus their cognitive resource
and the stuff that does.
Yeah.
How enough on a really crazy tangent there?
No, no, no, no.
I think that's perfectly reasonable.
I think it's, it's, it's understanding
and realising that we might be producing code
and programs and documentations of the day
like there might be real things that we can point at
and play with and use,
but the journey to get there
it's, it's all people,
it's all brains
and we, you know,
except for a few people on the very fringes,
we all intrinsically have
a lot of stuff wrapped up in our rational brains.
We never just use our rational brains.
Every decision we make, there's biases,
there's history, there's energy levels,
there's emotions,
all the way through.
And some people say
we actually post-rationalise
what are much more lizard brain responses
and reactions to things than we,
the many of us care to admit.
Yeah, definitely, definitely a thing.
Definitely a thing.
You know, I am talking tomorrow
on a sort of similar topic in a way.
My talk title is,
I am your user.
Why do you hate me?
And this comes from my experience
like being an absolute passionate advocate
for open source software.
It's awesome, it's wonderful.
But it's also a little bit rough
around the edges at times.
And I've found myself bumping my head
against things, not being able to figure something out.
And, you know, I'm sure people will say,
well, don't know, that's because, you know,
you're deficient in some way.
I'm not hardcore enough.
I'm not hardcore enough.
But I'm sort of increasingly of the case.
Well, actually, I am pretty good.
When there is a way, I will often find it.
I have to be tenacious sometimes,
and you know, try things in a different kind of way.
But it gets really hard.
And then I spent some time working
for some other organisations,
which weren't, you know,
drinking the freezer for a cool aid.
And found things were just very strangely easy.
Smooth, simple.
I didn't have to think about how to use it
or where to start.
And just found that the guide rails
and pathways were smooth.
And, you know, the design lines
are taking me where I wanted to go,
as opposed to somewhere else.
And then I've come back to free software
and gone, kept bumping my head against these again.
And this is where, you know,
my kind of long-running private rant
with Leslie Hawthorne of IAMU user,
why do you hate me?
Really came back to the fore.
It's like, why is this so hard?
It shouldn't be.
It doesn't need to be.
Why is it that proprietary software and solutions
can make it really easy for me to focus on
the thing I want to do
as opposed to focusing on the technology
to enable the thing that I want to do?
There has to be something here
we need to pay more attention to.
And I feel like, in some ways,
I have enormous privilege in this community
and the open source community
to be able to stand up and be prepared
to look and feel stupid
and say, hey, it's just not good enough.
And it's not good enough for us to turn around
and say it's the user's fault.
So, like, I'm hearing,
I think I'm hearing user interface.
It is for user experience,
site is for documentation,
installation side of things,
is there any other components
that I'm sort of missing?
Even data flows.
The connections between things.
And, you know, it's a big, complex,
hairy area in that, you know,
some of the providers of these
kinds of tools in the proprietary space
are only ecosystem.
So, it's definitely a lot easier
to make things seamless.
But the problem is that we,
as our reaction is generally
to go back and blame the user.
And my talk goes into, you know,
the number of stupid users,
not just in open source,
but in lots of technology,
we talk about users as stupid.
We assume that it's their deficiency,
that's the problem,
and not our product,
or our solution, or our software.
We also, when we talk about users,
when we go back
to a very fundamental definition,
we talk about it being
their lack of expertise,
which defines them.
And, you know,
this is kind of part of the problem,
I think.
And I say, I think here,
because I don't know,
I feel like I'm beginning
to poke out a problem,
and I haven't really
completely understood it yet,
and that's why I want to talk about it.
And why I want to talk about it
at a place like Linux,
come for you,
and say, we really need to get
to the heart of what it is
that we're doing here.
Is it a fundamental disrespect
for the user,
as in this faceless kind of entity,
or is it something that,
where we're not being able to,
kind of, wear someone else's shoes
and understand what's going on?
So, the example that, you know,
Elizabeth was talking about earlier
in her global communities talk,
was a really good example of it,
where we stopped being asked
and started listening to them,
and then became, you know,
became a whole,
became a wee.
So you actually, like,
invite your users into your community?
Yes.
Very much so.
And Genevieve Bell,
who, you know,
I keynoteed at LCA a few years ago,
it's done lots of awesome research
on the users of technology,
and I have this sneaking suspicion,
and I don't know if this was my idea
or I've read it somewhere else,
but if we were to actually acknowledge
and engage with the users of our software
as first class citizens in our community,
we would have a very different issue
with diversity than we do now,
because the users of a pro,
there were more of them for stocks
than the developers
and creators of things,
and they will also have real life feedback
and real life use cases.
And, you know, when we talk about, you know,
it's really healthy open source communities,
they talk about contributors rather than just,
just privileging to developers, for instance,
and anyone can contribute,
whether it's a bug report,
and it goes back to what we're talking about conflict,
that you have this moment where,
okay, there's something not quite right here,
it's an opportunity to make it better to smooth that down.
Maybe a nice analogy would be,
okay, here's a rough edge,
let's just get a little bit of sandpaper on that,
and bring our craftsmans skills to hone and smooth and perfect,
rather than necessarily,
oh, look, you've just got a splinter,
and that's your fault.
And I think, I mean,
like the other side of the coin is that, like,
you know, one of the reasons that you could suggest
is that the cause of open source software
being a bit crap when it comes to the user experience side of things,
is because most people are doing it as a part-time thing,
and, you know, they're not doing it for money.
They see a need for a feature,
they add the feature,
and they can get it to work,
and then they go to bed.
And getting people to,
getting people to treat the user interface side of things,
and the ease of use side of things.
And I think that's a phrase that's sort of torn out of popularity,
I'm not a big follower on all these things.
But getting people to treat that as work,
and not just,
we'll fix that up in the documentation.
I think that would require a real mindset to change.
But yeah, it's definitely a thing.
And I mean, I sort of see it at different levels,
because,
so I'm, you know,
I'm someone who's interested at the lower layers of things,
like I'm kernel and 2 or 3 layers above that.
And over the last three or four years,
three or four five years, actually,
we've seen a number of lower-order systems
get swapped around and changed around.
And for a lot of people,
they're only sort of realizing this now with system D
being put in place,
and that being a big thing.
And there's a lot of layers underneath that
that have changed dramatically.
And because they were backwards compatible,
most people didn't really see the changes being made.
And now that system D is exposing some of these issues,
people are having to go in and try to understand
how these small components work,
like login D, for example,
which when you log in,
it tracks,
tracks if you're a local user,
or a user logged in,
and you get different permissions based on that.
And you're not going to be able to come up with
physical devices locally attached,
or remotely attached.
And none of that stuff is really well documented at all.
And because it worked so well when we were installing it
in the background two or three years ago,
no one really cared.
But now that where system D is sort of exposing
some of the issues that some of this software has,
we're all screwed.
And everyone's just jumping up and down,
because nobody knows how many of this stuff works.
And it's exactly the same sort of stuff.
The only documentation for this stuff
is a couple of skimpy little man pages.
You read those,
and you don't have any idea what they're doing,
because they're using these completely fine concepts
that you've never actually had a look at before.
And, you know, if I go and use,
like Inkscape is a good example,
if I don't go and use Inkscape every six months or so,
everything that I've ever learned to do,
I completely forget about.
And, you know, I end up having to go to YouTube videos.
So, you know, I need to, you know,
I've got a JPEG,
and I want to convert it to a bitmap or something like that,
so I can do some nice scaling.
Like I've hand-drawn a logo,
and I want to vectorize it.
I end up having to go and do YouTube searches
for all of these things.
Because you look through the menus,
you look through the help system,
I don't even know what terms to search for.
And, you know, you spend a half a day just figuring out with Google
what the heck you're actually trying to say to people.
So, it's not like, like,
I think what I'm trying to say there is that
developers are users as well.
All of our computers are laid in such a way
that we are users of another layer on the map.
And even the kernel guys, you know,
they're still using an interface
that the hardware is providing.
So, we're all users of software and hardware at some point in time.
And if the developers of software can sort of
think back in time a little bit to the last time that they were frustrated
by how a bit of hardware or software worked,
they might be able to reflect on that
and try to provide a better experience to their own users.
Couldn't agree more, couldn't agree more.
And I think that's the key is really understanding that we are all users.
We do all use technology.
We don't create all the technology that we're using,
unless we're particularly genius human beings.
But, you know, also it comes back to
we focus a lot on the technology and things like this.
But we create technology for people,
even if it's just ourselves and the scratching your own itch analogy.
And it's people who create it.
And I would really like us to get away from two things.
One is talking about soft skills.
And the other is talking about users.
I'd really like us to be talking about people
and human skills or communication skills or management skills
or whatever, rather than kind of devaluing
what's involved in that skill set by saying
this is soft and this is hard.
Yeah, yeah, yeah.
It's a different skill set.
And it's this interesting thing where
because I don't have people skills,
I feel it's okay to put people skills down.
And like I've sort of grown up quite early on
sort of being rubbed up the wrong way with teaching.
Teaching in my lifetime,
I've come across a number of people saying things like
people who can do stuff do stuff and people who can't teach.
And that has never made any sense to me.
Like from grades like eight or nine
because I've always been pretty good at maths.
I would always get dragged along to help the kids
that were having trouble with maths.
And it is one thing to be good at something and be able to do it.
It is completely another thing to be able to take a concept in your mind.
It's been at 180 and explain it to somebody else in their terms.
And I get constantly frustrated at people who
denigrate teachers and teaching just because it's a skill set that they don't have.
And it's the same thing with design.
And there are aspects of design I don't like.
Like there's the whole color scheme thing.
It's almost a fashion thing these days where
every couple of years it's like, you know,
shades are in or pastels are in.
And it's like, you know, every new web framework,
they have to have a color set.
And unfortunately, it doesn't mean anything.
But that is the, because we're visual creatures,
that is what everyone sort of comes in around.
And it's the lack of,
I think it's that difference of
that inability to be able to build on top of a previous toolkit
and to improve it incrementally.
That doesn't seem to happen.
All I ever see is like, this is a completely new toolkit.
It's better than all the other toolkits because we've built it from the ground up.
And it's, you know, things like the Google toolkit,
which is not just a graphical toolkit,
but it's a whole material design.
Yeah, it's a whole process.
Like if your application, if you're trying to get your user
to select multiple things from a list,
this is the entire approach that you should take.
So that all of the apps on the phone are exactly the same.
And I'm all for that sort of thing.
But in another two or three years time,
there'll be another toolkit.
Well, I'm seeing the other end of that at the moment
with the Yahoo user interface widgets and tools
that were available years ago for the web.
There's still being used in some parts of the smoodle.
Moodle have recently decided to re-factor and use Bootstrap.
And it's yet another one.
But you can still still see why you are in the source code
of Moodle theme stuff all over the place.
And it's kind of this thing.
So there's different frameworks come along
and you adopt them and you build on it.
And then at some point in time,
it kind of either do it as a way or what have you
and that something else comes along.
So yeah, very much agree with you that it would be so much nicer
if we could.
I mean, I don't think we're ever going to completely undo that.
And you've got to have some space for innovation
and a new crazy way of doing things.
But it would be great if we could do more evolution
rather than revolution with these things.
And do more building and more can before.
To some extent, we probably use ideas,
even if we're building from scratch.
We're using ideas where we've learned that,
hey, that wasn't a great way to do it.
But yeah, there's a lot of obsolete stuff
which still runs alone.
Like as a developer,
something like material design,
like if I'm doing who this is how you do food.
And I would love that just to be true.
But I know in three or four years time,
there'll be a different approach
that is thought of as besting fast.
Yes.
And so because I know that the thing I'm learning today
won't be the thing that I need tomorrow.
I just won't bother learning that thing that I need to do the day.
Yeah.
Which is really quite sad.
But also just human.
It's just the reality of it.
We make choices all the time about where we invest our energy,
our time, our resources.
And it comes back to that cognitive resource as well.
So this is going to take me time to learn to do it this proper way
or I could do this quick dirty hack
and get to where I'm actually trying to go today.
We make those trade-offs all the time.
I think the kind of different use cases are important there.
There's been a debate in the Drupal community around Bootstrap.
Which is a really good example.
So Bootstrap I think was developed originally by Twitter.
It's kind of become almost ubiquitous
as a kind of quick and dirty way of getting stuff on the web.
And someone basically took the Bootstrap framework
and turned it into a Drupal-based theme.
And there's a conversation going on in the Drupal community
about hey, it's probably time that we got a new thing for Drupal Core
and how should we go about that?
Is it about shiny design to show what Drupal is capable of?
Is it about creating guidelines and handrails
for helping people to do their first theme and learn how to theme?
Or is it about having something out of the box
so people who just want to get content online
using the content management system as quickly as possible
and have it look okay?
Very, very different use cases for all three of those things.
And so the debate is kind of wild.
And I think Mark Carver, who is the maintainer of Bootstrap in Drupal
sort of said, well, his vision for what the Bootstrap theme is
is to allow people to use Drupal and get stuff online.
If they want to start making it look different,
they should do a sub theme and they're going to take that
in an entirely different direction.
And his view is that trying to make a pretty thing
shouldn't try to be a framework either.
But it's like, there are really some of these ideas are competing.
And at some point it's going to have to put that stake in the sand
and say, this is what we're doing with this initiative.
We can't do all of those different use cases.
So also, I was in Russell Keith McGee's session
on the Stranger and Strangerland.
And he was talking about PIBware and creating Python
so that it can be used on mobile devices and all sorts of devices.
We also talked about how Python is being used in the scientific community.
These are people who are not software developers by trade.
These are people who are scientists trying to wrangle data
and they're kind of programming because it helps them get to where they need to go.
And that was like this little moment where it went team in my head
because it's also the way I talk about the people who use our software
instead of talking about them as users.
They're not users of our software.
Our software is irrelevant to them.
They're trying to accomplish some task or goal.
Let it see themselves as that.
You know, I'm an inkscape user.
No, I'm a designer or I'm a...
I'm using a hammer and I'm using a drill.
Correct, right?
And I think we suffer from forgetting that too often.
And Cathy Sierra, I've got a call out to Cathy Sierra in my talk tomorrow.
People don't want to be awesome users of our tool.
They want to be awesome at the thing the tool allows them to do.
And we forget that.
And when we reduce humans to being users, we obliterate that reality.
So I don't know what we do about that, but I want to start calling it out.
I want us to start thinking about breezing the wheels, smoothing the vanisters,
making it as easy as possible to do the thing that they can to do,
and stop effectively abusing them for not being as smart as we are.
Right, so I mean, we've got a pedestal there,
and we've put the thing that we've spent our time and hard and sweat and tears.
We've put the software on the pedestal.
And we should be putting our users on the pedestal,
and our software should just be the thing that's making the pedestal tool.
Yes, I agree with the sentiment that you've expressed there,
but I don't want us putting users on pedestals.
I want us embracing users as part of our community as us, not as them.
Okay, cool.
Is there anything else you would like to discuss?
I think I've kept you for about half an hour now.
I think I've probably said as many obscene and offensive things as I can.
I hope that when you give your talk,
that you can put as much vehemence into your talk
and convince as much of the audience you've been able to convince me.
Thank you, Clintus.
Thank you very much, Donna.
You've been listening to Hacker Public Radio at HackerPublicRadio.org.
We are a community podcast network that releases shows every weekday,
Monday through Friday.
Today's show, like all our shows,
was contributed by an HPR listener like yourself.
If you ever thought of recording a podcast,
then click on our contributing to find out how easy it really is.
HackerPublic Radio was founded by the Digital Dove Pound
and the Infonomicon Computer Club,
and is part of the binary revolution at binrev.com.
If you have comments on today's show,
please email the host directly,
leave a comment on the website
or record a follow-up episode yourself.
Unless otherwise stated,
today's show is released on the creative comments,
attribution, share a like,
3.0 license.