Okay, great.
Yeah, after the last speaker, I think my sticker game isn't quite up to standard.
But I'm Jim, I'm a research software engineer at the Alling-Turian Institute
and a volunteer core member of the Turingway team.
The title I submitted was Bridging Contributors' Knowledge and the Technology of the Turingway
and Open Guide for Data Science.
And I thought that was a bit long and vague and maybe I'd have another go
and I came to a personal perspective on the interface of infrastructure and people
which is at least shorter, but I'm not sure if it's much better.
But I'm going to be talking about getting the people who contribute to your project
with the infrastructure, which does mean the technology,
but also means the processes and people who control what gets into the project
and how decisions are made.
So the way I like to pitch it is we all contribute to projects for a reason.
We're making something for a purpose and there's different ways we can measure that
and you might think about a number of contributors or stars or downloads
or engagement or something.
But the common thing between all of these is we need the contributions.
So that's how we make progress.
And so maybe what I'm going to suggest is maybe the important thing,
the most important thing that you should be thinking about and measuring yourself against
is how well do you facilitate people who are contributing to your project.
So a bit of scene setting for the Turingway.
The Turingway is a handbook for reproducible, ethical and collaborative data science.
It's developed completely in the open on GitHub
and is open to the licensed creative commons.
And there's quite a large number of contributors.
The last time I looked it was a bit over 470 contributors in total.
When I work on the book, that's what my screen looks like.
My background, I have a chemistry degree in PhD and during that
I was exposed to Linux and open source software through computational chemistry
and became really passionate about that.
And now I work as a research software engineer.
So I'm not really a chemist, but I'm not quite a computer scientist
and I'm somewhere floating in the middle.
And the Turingway is a big project where I work.
And I started off just making a few tiny contributions, fixing typos
and links and things.
And late last year I became one of the co-leads of the new infrastructure working group
and we think a lot about the CI and automation
and how we help people get stuff into the book.
So what's the actual problem I'm talking about and trying to think about?
So if you're a maintainer of a project, one of your key tasks is maintaining quality
and to a certain extent that means putting up a bit of a barrier to contribution.
You need to have some standard, you need to keep standard,
you don't want to break things.
And that can be a bit tricky because that involves a bit of pushing back against people,
maybe giving critical feedback or maybe not accepting certain changes
and you need to kind of strike a balance there of encouraging people
and then getting stuff in particularly when your contributors...
I always say non-technical, which really means not software engineers, I suppose.
Your contributors may come from many different backgrounds
and have different amounts of experience.
So some might be more or less into tech
and that can also create problems
because you can't assume that every contributor is going to be the same
and they might need different levels of assistance
and that might make sense to one, might not make sense to others.
In the Turingway in particular, the community is incredibly diverse
in terms of their educational and professional background,
the language they speak, time zones where they work, where they live, their lived experience.
And most of the contributions, most of the data that's actually in the project
is pros and not software.
They're contributing their ideas and their knowledge in the form of text
rather than working on the code.
And so also the people are generally not software engineers,
which means there's quite a lot of additional support
in terms of, you know, YAML format,
why does Markdown work and why doesn't CI pass.
But I think the important thing there is that all of the people that contributes
make valuable and important contributions to the book
and their sort of technical ability,
so how well they understand the build process and things,
isn't really a good measure at all of the value of their contributions.
So we focus quite a lot on how to enable people to contribute to the book.
So here's our approach at the moment, things we do.
Probably not surprising, but everything is version-controlled
in Git and the projects on GitHub.
But I think there is an interesting question of why do we do that
and why don't we just have a wiki if it's mostly text.
I think the simple answer is the advantages of version control are just too strong.
You can go back in time.
Handling multiple contributors is really easy
even when they're working asynchronously on different branches
and you have to fix conflicts and things.
And because it's a guide about open and reproducible data science,
there's elements of do what we say,
we've got to demonstrate the sort of culture we're trying to create.
And so that means doing everything in the open,
doing everything as reproducibly as possible.
There is a community handbook,
and I always love how sort of meta this is.
It's like a book within a book,
and it's a book which tells you how to contribute to the showing ways.
There's a contribution guide, there's the code of conduct,
style rules and things like that.
So yes, I love that the book tells you how to write the book
and contribute to the book.
And because it's part of the book, it's completely open,
and if you think those rules should be changed
or adjusted or can be clarified, you can also contribute to that.
Recognising contributors is really important,
and we try to recognise all types of contributions,
so not just text and not just code.
And one of the ways to do that is to use tools from the All Contributors project,
where you can tag people for the types of contributions they've made,
and you get this nice table of people and their contributions,
and that is also displayed in the book.
And on a Git repository, people are encouraged that if they feel
they've done something, they've put in some effort,
they should suggest that they be added for a certain contribution type on this.
More recently, we started using a GitHub action
which ties into the crowd-in API.
So crowd is the platform that's used for making translations
to help to better recognise the translation efforts that go on in the during way.
There's a lot of support.
As I said, a lot of people are not super technical,
and so we might need to work quite closely with them.
We like to think of pull requests as a chance to work with people
and collaborate with people and make connections
and not just a barrier to stop things you don't want to be merged in.
And that support goes even further.
There are different types of events and co-working sessions
to help people get contributions in.
So there's regular co-working.
There are sprint-style events called book dashes.
And so there's a lot of stuff which adds a bit of social element,
but it's also about helping people work together collaboratively
to get things into the book.
And we lean on, see on automation a fair amount,
and the focus there is remove burden from the users
so we don't expect people to build the book or run tests themselves.
Everything is done in CI for you,
so you don't really need to know about how it gets built.
You can just focus on writing the muck down.
So here are my sort of unoriginal lessons for how to search contributions.
Building a community takes effort.
If you write some code, you put it on GitHub,
it doesn't necessarily mean people will engage with you.
You need to be quite proactive in reaching out to your community
and assisting them.
And that means you need to know who your contributors are
so if you can identify that and figure out what would help them,
I think the thing to think about is what thing can you do
which would most enable them to contribute.
Leaning on CI is great.
You can sort of say what CI says goes.
It's a fair way to sort of compare people's work,
all the tests are done in one consistent place.
Everyone's being marked to the same standard
and avoid sort of arguments about, well, it works on my machine.
I think this sort of goes without saying version control, not optional.
It's brilliant, do everything in version control.
And if that means you need to do some support to help onboard people
and how to use that, which we definitely do,
it's definitely worth the effort, it's worth the pain of doing that.
You should be flexible.
So I think something to keep in mind is it's better to bend the rules a little bit
to better contribution in and you shouldn't let the perfect be the enemy of the good.
However, you do need to know when to be strict
and here's some suggestions of what maybe your red line should be,
things that sort of aren't acceptable to merge in.
However, even when you're doing that, you've just got to keep in mind
be kind and respectful and actually problems are an opportunity
to get to know someone and help someone and teach someone.
So thanks very much for listening.
I'd just like to thank a few people.
I'd like to thank all the infrastructure working group on the sharing way.
That's Brigitta, Danny, me and Sarah.
I'd like to thank Ale and Anne who's here with the project and community managers
and provide a huge amount of support in getting the working group started.
Skrobiria who worked to make all the brilliant illustrations that you've seen.
So without them, you would have been looking at a lot of bullet points
which wouldn't have been as fun and absolutely everyone that's contributed to the sharing way.
If this has sounded interesting to you or the book,
A Guide to Open Refugees, Refugeeful Data Science,
you can read the book.
Here's some ways to join the community, the sort of social aspects.
And we've got more definitive, clear ways to get involved.
So you can read the community handbook.
We've got good first issues and there are events you can join to start making contributions.
Thanks very much.
So we have one minute so you can take one question as you please.
Why we welcome the next speakers if they are here.
Yes.
So you mentioned Ale have seen how you're recognizing contribution
and you can have people nominate.
I'm curious if you have sort of a list of what those categories of contribution are
because I assume that many products struggle to recognize non-striped contribution.
I'd like to see that you have a record but I was curious how do you,
I don't know what those times are, do you have a list of how you can recognize these other titles of contribution?
Yeah, I'm going to read the chef.
Yes, so the question is we say we want to recognize all types of contributions
and earlier in the slides you could see a little emoji to say what those are
and so is there a specification for what those are?
So I can learn more about that.
So the All Contributors Project has a list of contribution types and the emoji
and so they've, I would say it's sort of loose suggestions
that some of those are infrastructure, content thinking, event planning, things like that.
So we roughly follow what that says.
We're not sort of super strict on saying this emoji relates very specifically to this kind of work
and actually the approach I think it's probably written somewhere in the community handbook
is more like if you feel like what you've done, for example is event planning,
you should find the closest one to that and add yourself.
So we use it quite loose and take the attitude that even a contribution of any size,
if it's a measurable contribution it's worth adding an emoji.
But yes, the All Contributors Project has their table of what those mean
and some sort of suggestions.
But I think it's quite nice.
I think another project you can sort of maybe use them a bit as you want,
maybe some of them are more or less relevant depending on what your project does.
Thanks.