Life Stream is on.
So yours everybody, welcome, Dhanu Benjamin.
Hello everyone.
Hello.
This is my first FOSSTEM.
I have wanted to come to FOSSTEM for so long and I've come from all the way on the other
side of the planet.
Is there anyone in the room right now from New Zealand?
Because if you're from New Zealand you've come further than me and if you're not from
New Zealand then I probably have travelled the furthest to be here today.
I'm from Melbourne, Melbourne, Australia.
My name is Donna Benjamin.
I'm the product owner and maintainer of the Open Practice Library.
So I'm very proud to be emblazoned and being a public billboard today.
And the stickers that I've just passed your way are the very simplest and easiest way
of contributing to my project is to spread the word.
Wear your sticker with pride somewhere and help tell the world about the Open Practice
Library.
But wait, I hear you say.
Why would I want to tell the world about the Open Practice Library?
Well my answer is, well why wouldn't you?
Well let me tell you why I think it's awesome.
Way back in, well over a decade ago now, for a little while I was a born again agilist.
I did a scrum master course and I thought wow this is amazing and I became like a scrum
padawan learning everything about scrum and thinking it was awesome.
I'd been involved in the open source community for a long time before that and I felt like
there was all this like similarities between like open source and the agile stuff and I'd
been to lots of open source events and I went to some agile events and whilst we were all
talking about software, none of the agile people were talking about open source and
none of the open source people were talking about agile.
It's almost like they were on different planets and there were a few people who were familiar
with both worlds but not many.
And then I came across the Open Practice Library.
Thank you Leslie Hawthorne who sadly isn't with us but is one of the organisers of this
Dev Room who introduced me to the Open Practice Library and I went oh my goodness this is
the first time I've seen open and agile together and for me that was like
because it made so much sense to me.
I'd always wondered why they weren't together.
I still don't know why they're not together.
I have theories but no hard evidence shall we say.
Okay so as you can tell I'm not doing slides.
If you've bothered to read the little description of this talk then you may have some idea but
in practice I know most people don't bother reading the abstracts they just kind of end
up in a room at a conference so that's okay no judgement right no judgement.
But what I wanted to do was to introduce this idea of open practices for open projects.
So hands up if you're involved in an open source project.
Okay hands up if you in that involvement have come across various needs, challenges, things
that need doing.
I think that's everyone.
Was there anyone who didn't put up their hand?
Did I miss you?
No good.
So the thing about the open practice library is that last word library.
I like to think of a library as two things.
Obviously it's a collection of stuff like usually books but other stuff.
But libraries are often the hub at the centre of their community and so I think that's a
really nice kind of thing to think about in the community developer room at Foster, right?
We're talking about a hub of a community and the people in that community are and again
the clue is in the word practitioners.
They practice things and those things are practices and the kinds of practices in the
library are organised around the Mobius loop.
The Mobius loop is an outcome based delivery framework developed by Gabrielle Benfield
and it starts with a discovery.
It continues with a decision making kind of chunk and then there's delivery and then
you cycle back through your options and decisions perhaps back to discovery or perhaps continuing
to deliver based on what you've learned.
In the open practice library we took Gabby's stuff because it was Creative Commons and we
added a foundation underneath it.
I think of that foundation as a bit more like a seesaw because we're trying to keep
in balance cultural practices and technology practices.
So on the cultural side we'll have things like a social contract or a team API or a
manual of me.
I think someone I think lovely Scottish chap this morning earlier.
Mike talked about having a manual of me or some kind of personal API.
That's a practice in the open practice library as well.
But those cultural or social practices are also balanced by technical practices, stuff
like CI CD pipelines, canary releases, observability.
They're the underpinning platforms and I say it's a seesaw because you've got to have
both.
You've got to have those things in balance.
And that foundation underpins the kind of work that you do to discover.
Like we talked yesterday we heard a bit about product management and I think a lot of the
product management practices fit in that discover phase of really understanding who this thing
is for, why it exists, why they need it.
And the delivery side once you've built something you need to be able to measure and learn.
So that gives you kind of high level idea of the practice library.
What I want to do now and this is the worst room to try and do this is actually have you
talk to each other for a little bit.
Sorry, live stream this is not going to be much fun for you.
Maybe you could jot down some thoughts on pen and paper or just have a think while we
have this little section.
Okay, yeah, good.
Awesome.
You guys rock.
Okay, so you who are here, I know it's tricky.
So what I want you to try and do is kind of look around you, who's sitting beside you
or maybe behind you and just huddle a little bit.
That question I asked you before, you're involved in an open source project, tick, and you have
some stuff that needs doing or thinking about or changing whatever.
And I want you to just have a chat about that stuff.
What are the things you want to tackle?
Do you need to imagine something new or new set of features?
Do you need to tackle a thoughty community problem as Angie and I have done on the odd
occasion?
Whatever it is, whatever the stuff is, no judgment, could be technical, could be social,
could be infrastructure, could be finance, whatever it is.
I just want you to have a little huddle and talk about the stuff.
And I'm going to give you three minutes if I can count based on this clock.
Your time starts now.
Let's count it down.
So I'm going to count 13.
OK.
Hello.
Hello.
Okay, hello!
Hello!
You got to be...
Oh!
Ooh! Nice!
Sorry to rudely interrupt your conversations.
It was kind of fascinating watching from down here,
because some of you were like, into it.
So you're like...
And that's fine.
So I'm hoping that you stimulated a few ideas,
exchanged some maybe commonalities, maybe contrasts.
What I'd love to do now, and I don't know that...
I'm not going to try and make you run with the mics
to try and get to everybody.
I'll repeat.
So what I'd love to do now is hear a little bit.
What happened to my bit of chalk?
Some different strategies.
Sorry, not strategies.
Different challenges and stuff.
Thank you, Mike.
Can we go to the box and show Karen the table?
All good.
All right, so I'm going to write down here.
You're not all going to be able to see it, but I can reach it.
Practical, right?
Practices, practical.
So who would like to start the bidding with a challenge for me?
Getting developers to document.
Getting developers to document.
We just had this fabulous talk about that as well, right?
Getting developers to document.
And I think one of the things I really heard Erin say
is around prioritisation.
How do you prioritise things?
And there are, in the Open Practice Library,
a couple of different practices, actually probably more than a couple,
focusing on prioritisation activities that you can do.
Some of the famous ones, it's called the Eisenhower Matrix,
or how now, wow.
So document prioritisation is a good one.
For which we have practices.
Awesome, thank you.
Next.
Overcoming single-maintainership.
Sorry?
Overcoming single-person maintenance.
Overcoming single-person maintenance.
Ooh, that's a good one.
I don't know if I've got a single practice for that,
but I think that's about creating a space that invites collaboration.
And a lot of our practices are designed to be collaborative
and have people come together.
So I guess it may even be part of this starting with docs
and putting the call out.
And one of our other speakers this morning
around communication strategies, right?
How do you get people to come on board and help?
So I can't answer that one. I like it.
So let me put single-maintainer challenge.
All right, my writing is terrible.
Don't judge. Yes.
Getting your technical leads to write down a roadmap.
Getting your technical leads to write down a roadmap.
Getting your technical leads to write down a roadmap.
Cat, I'm not sure that's a practice.
But, bragging. Yeah.
But I think it's a good one, though.
Does anyone want to shout out some strategies for that?
How do you get stuff out of people's head and onto the page?
Document a prioritise.
Document a prioritise.
Gold star.
Brainstorming.
Brainstorming.
Start with a wrong answer.
Oh, that's a brilliant one.
Start with the wrong answer.
And someone will correct it.
Yes, indeed. Yes, indeed. Yes.
I listen to them.
Listen to them.
What if they're not talking?
Yeah, they are.
They don't want to write it down.
They don't want to write it down.
But maybe they don't need to write it down.
This is where the collaboration piece comes in, right?
A lot of the practices in the library are about helping teams do their stuff.
Collaborate, either how to make sure they're building the right thing
and building the thing right.
But not everyone is a writer.
And not everyone is a coder or a community manager.
So what you want is this diverse perspectives and skills
and for someone to work with the tech lead to at least talk about what is in their heads.
And then maybe someone else can write it down.
Good one.
Right. Another. Sage.
Finding and encouraging and nurturing mentors.
Finding, encouraging and nurturing mentors.
Awesome.
Do we have a practice for that?
No, but I think outreach he does and Patch is welcome.
Yes.
How do you create a welcoming space for other types of contributions to community?
Like documentation.
How do you create a welcoming space for other types of contributions to come in?
Like documentation, like community management, like social media.
Great question.
Again, I'm not sure we've got specific practice for that.
From community involvement at various times,
be welcoming is like the first step.
Be surprised how often and how unwelcoming so many open projects have been traditionally.
I think it's actually changed.
I've got grey hairs now.
I'm beginning to sort of see a then and now.
But being welcoming and making that an explicit value is probably the first step.
And having consequences for behaviour that turns people away is probably the second.
Really nice, nice point.
I like that one. Thank you.
Yes.
A moderator is usually also a good mentor.
Nice.
That you have to train the moderator.
A moderator is also usually a good mentor, but you also have to train the moderator.
But some moderators, I agree with you, but I also disagree because some moderators can turn people away by saying,
no, that's not welcome here.
But then again, it's always, it's never simple, right?
Sometimes you need to actively turn people away to ensure you have a welcoming project.
Tricky to balance.
That seesaw again. Yes.
How to do the right things and do things right and convince your leadership that this is the right thing?
Good one.
How to do the right things and do things right and, because that wasn't enough,
convince your leadership that that's the way it should be.
Okay. So this one, I think we've got a good answer for, and that's the Mobius Loop at the heart of the Open Practice Library,
Gabby's outcome-based model, is really my, really, it really pauses to say,
we need to understand the who and the why,
and we need to be clear on what we're trying to achieve.
So our target outcomes.
Too often in software development, sort of in agencies or in companies,
probably less in the open source world, we're basically given some spec
and then told to just go build it.
And we've had no involvement in the design, the ideation, the who, the what, the why part of it.
It's just just build this thing.
And you could go build this thing real fast, but if it's the wrong thing,
how much effort has been wasted, right?
So I think this discover phase is really, really important.
Actually, I'm not allowed to call it phase, Gabby told me not.
It's more like a part.
So the discover part of the whole picture, understanding who, understanding why,
being really clear on what you're trying to achieve,
and how you're going to measure if you've achieved it,
you've got to get that clear before you rush into building.
So once you've got that stuff clear, you're going to have a whole bunch of ideas of how to go about it, right?
So you've got to go to options phase.
You've got to develop, create, ideate, get those ideas up, and then sort them.
You can't do everything.
You have to prioritize.
And that's your options phase.
You'll decide, discover, decide.
Before you go on to deliver the right thing, hopefully has been,
you now know you're building the right thing,
and you can focus on that technical excellence,
bringing in those technical practices to ensure you're building it right.
One more. Yes.
I love everything you just said, and I'm not going to be able to say it back for the live stream perfectly,
but it was building on the welcoming thing that we mentioned a bit before.
How do you create a culture of gratitude?
How do you create a space where it's safe to experiment?
And there was a last little bit which I didn't catch.
It's about personal development.
Personal development.
We're working in the project.
And how do you create space for personal development and growing in the project?
Beautiful.
Okay, so the welcoming space, I think making a culture of gratitude is really important.
The fact that someone has stepped into your project and offered a contribution.
And I do this with the Open Practice Library.
I get first contributors and I go,
thank you so much for contributing to the Open Practice Library.
It is the first thing I say.
Even if the contribution is not particularly right or perfect for now,
the fact that they made the effort to contribute is just awesome.
And I am always overwhelmed with joy.
So that's one way.
In a physical space, we've done things like having a kudos wall or where you get sticky notes.
If you're having regular team meetings, you can start with gratitude.
What are we thankful for?
There's lots of ways.
And I think it's a really beautiful practice.
And there is something in the Open Practice Library about it, thank you all.
So yeah, that's lovely.
The personal development piece.
I don't think I've got something explicit about that,
but I kind of seem to think that almost every step you take together as a community
is an opportunity for personal growth.
But it's not always sunshine and roses.
Sometimes the personal growth comes out of quite hard work,
emotional work and disappointments.
And I think that's one of the biggest things that we can learn as a community
is to not shy away from the stinky, hard messiness,
because that's really human.
We talk a lot about code and technical excellence,
but really we're human beings,
and it's not always right, it's not always perfect,
and it's often very much the opposite.
So I think they're real opportunities for personal growth as well.
And then I've forgotten the middle bit again.
Too many things for me to think about at once.
Will that do?
Thank you.
Awesome.
All right, I think we're just about out of time.
One more?
Two minutes.
Two minutes, because we're doing the questions as well.
Oh, then I can have more.
Ha ha ha!
In that case, question?
Wait, you've had a lot of go's.
Wait, wait, wait, wait.
Anyone else?
Yes?
A team that feels overwhelmed by too many things to do.
A team that feels overwhelmed by too many things to do?
Our prioritization friend again.
But one of the things that I like to do,
and I think we've played with this,
is just start with a list.
Actually, just get it all out of people's heads and fears and worries.
And get it down.
And then you can say, okay, let's sort this.
Let's come up with some criteria for how we want to sort it.
Are we optimizing for impact, as some people say?
Are we looking for low-hanging fruits so we can get some quick wins?
Are we looking to tackle something really, really challenging,
because we want to strive together?
So I think getting it out of people's heads,
because sometimes I think the overwhelm is just,
it hasn't been quantified.
But once you get it down into a list,
you can say, hey, this stuff matters.
And actually, if we never get round to this stuff down here,
does it matter?
Maybe we can lighten our load and just say,
no, we're not doing those things.
Anything else?
Any questions, folks?
So one thing I want to kind of add into this is,
I was cheeky at the start and I passed around
my Open Practice Library stickers.
Did you all get one?
So that's one way of contributing,
of sharing the fact that the Open Practice Library exists.
Another way of contributing, and we've heard it today,
Open Collective, so Funding Open Practice Library.
I've put us on opencollective.com.
slash openpractice.library.
Buy us a coffee a month.
That's another way of contributing.
But also some of the ideas that you've had,
or perhaps practices that you're using,
scan the Open Practice Library,
and maybe your favorite practice isn't there.
Maybe we could, you could add it.
And we've got a really low barrier to entry.
We'll accept most things before they're perfect,
because hey, it can always be improved.
It can always be iterated upon.
So I very much want to invite every single one of you
to think of yourselves as contributors to the Open Practice Library
as being welcome at our community hub.
Feel free to use the practices.
There's absolutely no nothing stopping you.
Feel free to raise issues if something's a bit clunky.
And hey, feel free to make a pull request.
Add a new practice.
Help us fix our website, or all of the above.
Thank you so much.
Thank you. Just check any of the questions.
Yeah, and now any standard questions?
You don't have to follow my script.
No?
Hold on, hold on, hold on.
You should know this by now.
Thank you.
It's more about what you find as a practice
and what is not a practice,
so that we know what to put there and what not to put there.
Thank you.
Excellent question.
What's a practice and what's not a practice,
and how do you know the difference?
On the website, there's a menu,
and there's a contributors guide.
We've got editorial guidelines there,
and a little bit of an outline of what we think a practice is.
But that said, if it's not a practice,
we can talk about it in the pull request and go,
this isn't quite right.
So don't let that stop you.
Great question. Anyone else?
All the way over there, Laura, run.
You're off the pizza now.
One moment, please.
Here we go.
No, I just want to express my gratitude
and acknowledge how brave you are
to come to this conference with a full room
and to not use a slideshow
and to really tap deep into the collective intelligence.
It's really, it's very much appreciated.
Thank you.
Thank you.
That is very kind and also very validating
because I was like, I'm not going to do slides.
I'm just not going to do slides.
So thank you very much. Thank you.
Well, unless there's anything else,
I am going to express my gratitude again
to all of you for coming and sitting through this,
but also for having that conversation in the middle there
and sharing with each other.
I wish we had a bit more of that here, to be honest.
But hey, I'm new, so forgive me.
Thank you.
Thank you very much.