WEBVTT

00:00.000 --> 00:02.000
You

00:30.000 --> 00:32.000
You

01:00.000 --> 01:02.000
You

01:30.000 --> 01:32.000
You

02:30.000 --> 02:32.000
Thank you

02:32.000 --> 02:40.000
No worries. This is just to say that the advice I will give is informed from my experiences working with these organizations and

02:41.000 --> 02:52.000
Mostly within our team. So we are about eight nine people depending on how you count and we are dedicated to developing high quality robust easy to use maintainable open source software

02:52.000 --> 02:54.000
For neuroscience and machine learning and

02:55.000 --> 03:02.000
Collectively we build and maintain many projects. So we have about twenty five open source python packages. We mostly work with python

03:02.000 --> 03:08.000
And that includes probably the most famous one is brain globe, which is a suite of tools for computational near anatomy

03:08.000 --> 03:16.000
That has been cited hundreds of times. It has the millions of downloads 140 contribution GitHub and tens of packages that depend on it

03:16.000 --> 03:21.000
So it is successfully adopted within the community, which is anish community but quite large

03:21.000 --> 03:26.000
And we also have other projects. I will mention examples throughout the slides from brain globe

03:26.000 --> 03:32.000
And also from another project which is much younger. It's called movement and it's the one whose development I lead

03:33.000 --> 03:39.000
First of all, let me jump to the to the first of my three points, which is defining your mission and scope

03:39.000 --> 03:42.000
And the picture I want to

03:42.000 --> 03:48.000
You to imagine and that's why the animation is that open source software is a vast ecosystem

03:48.000 --> 03:54.000
It's an interdependent network. It's a web of dependencies and relationships and competitions and collaborations

03:54.000 --> 04:01.000
And when you start a new project your first job is pinpointing your location on this web

04:01.000 --> 04:08.000
So you have to really drill down on the site where am I in the second system where does my project 15 within this larger image

04:08.000 --> 04:15.000
And luckily as researchers you should be familiar with that because that's what we do when we start a new project

04:15.000 --> 04:21.000
A scientific project we need to literature we identify the gap then we decide how we want to address the gap

04:21.000 --> 04:26.000
And actually when you write the manuscript at the end of a project that's what you're asked to do right you write an abstract

04:26.000 --> 04:33.000
And in an abstract you say this is the background this is the context that's the gap that's where my new piece fits in

04:33.000 --> 04:41.000
And advice I really like in when doing science is that you should do an abstract not at the end but at the very beginning

04:41.000 --> 04:47.000
So if you start to write an abstract before even start researching that has a lot of benefits

04:47.000 --> 04:54.000
It's sharpens you're thinking about the project and then you're not really tied to it because it's not your destination

04:54.000 --> 05:00.000
It's more like a compass so if you have an abstract in mind if you imagine the project finished and you kind of rework it as you go

05:00.000 --> 05:05.000
It guides your decision making and it helps you not getting lost in this web of knowledge

05:05.000 --> 05:11.000
So I want to bring this idea of abstracts from the scientific world to the software world

05:11.000 --> 05:16.000
And in software we have no such thing as abstracts it's not formalized there is no structure

05:16.000 --> 05:24.000
But if you look into the websites of your favorite software projects and the readme files you will start seeing some patterns that look something like abstracts

05:24.000 --> 05:31.000
First of all you will often see a single high a single sentence high level description of the project which is kind of the mission statement

05:31.000 --> 05:42.000
It's often what follows under the title or it sometimes it's in its own page. We will see examples of that and that mission statement is often followed by one of three elements

05:42.000 --> 05:53.000
You often see specific aims listed under the mission you sometimes see the key features or the scope of the project and you also often see design principles or key architectural decisions

05:54.000 --> 06:03.000
This is the front page of Bangalore, so the sentence of the top is to facilitate the development of interoperable Python based tools for computational environment

06:03.000 --> 06:14.000
That's the mission statement and then you have a list of three aims which I will not read which are essentially you can think of it the same thing you would find in a scientific grant you high level mission and then key aims

06:14.000 --> 06:25.000
Another project Python project I really like and userly often is Napaari which is a fantastic image here and this mission is a fast interactive year for multi-dimensional images in Python

06:25.000 --> 06:34.000
And then you have four bullet points and those are the key features the key tasks that someone would use Napaari for and this kind of nicely defined the main scope of the project

06:35.000 --> 06:42.000
When I started and my collaborators starting working movement we took this idea very seriously, so we did a lot of research

06:42.000 --> 06:49.000
Literature research market research looking out what other tools are out there we talked to researchers who worked in the field

06:49.000 --> 06:59.000
The relevant field field here is animal behavior actually and we kind of mapped out the tasks decided which tasks are difficult which tasks are already covered by existing tools and so on

06:59.000 --> 07:02.000
And we came up with an abstract which you can read on our website

07:02.000 --> 07:07.000
But then because I'm a visual thinker I thought okay, let's do it to one step further and let's make a graphical abstract

07:07.000 --> 07:13.000
So this is our current graphical abstract which has also evolved over time as the project evolves

07:13.000 --> 07:20.000
And here basically in this schematic you can see a summary of all the other projects that we interact with that are critical for us

07:20.000 --> 07:27.000
For example the libraries we used to load the data from the library we used to represent the data and the one we used to visualize the data

07:28.000 --> 07:36.000
And on the top you also see the key tasks or the scope of the project basically is for filtering visualizing and analyzing animal motion tracking data

07:36.000 --> 07:43.000
So if you have the skills or if you have no someone who has the skills to do that I highly recommend a part from writing indexed your mission scope

07:43.000 --> 07:50.000
Also making a schematic like that because it communicates kind of your your project's position in the web at the glance

07:50.000 --> 07:55.000
And even people who are too bored to read the text can grasp the essence of the project

07:55.000 --> 08:01.000
Making the abstract upfront has had many benefits for us and we do this now across our projects

08:01.000 --> 08:06.000
One example I will bring up is that in the very early days of this project

08:06.000 --> 08:10.000
Someone I didn't know, Mikael contacted us

08:10.000 --> 08:16.000
And he wrote a message and he said basically hi, I follow the project from slides from the sidelines

08:16.000 --> 08:21.000
I'm developing a similar packaging R, the functionality seems to overlap

08:21.000 --> 08:26.000
Would be great to have someone to work together maybe we can have two packages one in our one python

08:26.000 --> 08:32.000
And he nowadays is our most valued collaborator and we do actually what he suggested we are developing in parallel

08:32.000 --> 08:38.000
We are coordinating and we are trying to serve both the art and the python ecosystem ecosystem for this task

08:38.000 --> 08:45.000
But this would not have happened if we hadn't publicly and very early on stated what is our vision where we are going because

08:45.000 --> 08:50.000
Doing that early allows you to invite scrutiny and collaboration early on

08:50.000 --> 08:58.000
So basically if you do this at the beginning both the collaborators and the critics come early and that's good in both cases

08:58.000 --> 09:02.000
The other thing I mentioned is that you sharpen your vision

09:02.000 --> 09:06.000
So if you are forced to write down what your what your goal is in writing

09:06.000 --> 09:12.000
One of two things happens either you realize the idea is done and you shouldn't do it because either it's already exists

09:12.000 --> 09:19.000
It's served by another project or maybe you're not the right person to do it or two you really realize that the need is real

09:19.000 --> 09:24.000
And you become capable of articulating the task

09:24.000 --> 09:29.000
This allows you to convince your managers, your funders, your collaborators to advocate for the project

09:29.000 --> 09:32.000
Because you've already sharpened your thinking about it

09:32.000 --> 09:38.000
And the third benefit of having an abstract early is that in disagreements you have something to point

09:38.000 --> 09:45.000
For example if you disagree with a collaborator on a technical decision for architecture or if you disagree on whether a feature is in scope or not

09:45.000 --> 09:52.000
You can refer back to your written abstract and use that as a guide book as a constitution to help you make the decision

09:52.000 --> 09:56.000
I will now move to the second part

09:56.000 --> 10:00.000
So let's imagine you have written the abstract you know your vision you know where you're going

10:00.000 --> 10:03.000
You're starting development and now you want to make your first release

10:04.000 --> 10:11.000
The advice we hear often is really early really often and that's actually comes from the famous essay

10:11.000 --> 10:14.000
The cathedral in the buzzer by Eric Raymond, which I highly recommend you read

10:15.000 --> 10:18.000
Just a very one sentence recap of that essay

10:19.000 --> 10:25.000
Raymond says that there are two models for software development that traditional model he calls the cathedral

10:26.000 --> 10:33.000
Where you have a select group of craftsmen laboring hard for many many years to make this perfect artifact

10:33.000 --> 10:37.000
This polish cathedral has no flaws and then reveal it to the world

10:37.000 --> 10:40.000
The second model is the buzzer

10:40.000 --> 10:46.000
The buzzer means embracing the colorful diversity and chaos of a buzzer

10:46.000 --> 10:50.000
And in software terms it means that you welcome contributions from anyone in the world

10:50.000 --> 10:55.000
It also means that you really believe that with enough eyeballs all bugs are shallow

10:55.000 --> 11:00.000
And this is relevant to release is you release early and you release often

11:00.000 --> 11:03.000
And that last advice is really the key one

11:03.000 --> 11:10.000
In our team we have a particular recipe for what constitutes a good minimal viable product for a software

11:10.000 --> 11:14.000
And that is a checklist of three points one

11:14.000 --> 11:16.000
The software contains at least one useful feature

11:16.000 --> 11:21.000
Basically it accomplishes one task its timelines exactly one task

11:21.000 --> 11:26.000
Ideally exactly one that feature is well documented including user examples

11:26.000 --> 11:32.000
And three the software install seamlessly on platforms that our target users may use

11:32.000 --> 11:34.000
And I will unpack each of these briefly

11:34.000 --> 11:37.000
One feature is really all you need

11:37.000 --> 11:41.000
I really believe that because it keeps you focused on a concrete milestone

11:41.000 --> 11:44.000
It protects you from scope creep

11:44.000 --> 11:49.000
You might be afraid that people will perceive this as trivial if you come out and say

11:49.000 --> 11:51.000
I can load CSV files

11:51.000 --> 11:56.000
Big deal right that's not a danger because you have already articulated their mission in scope

11:56.000 --> 12:01.000
So people can see the vision and can see how the first step fits into the larger vision

12:01.000 --> 12:06.000
And the goal here is not to capture every possible potential user

12:06.000 --> 12:09.000
But to capture at least a few early adopters

12:09.000 --> 12:16.000
Because if you capture them early they can give you feedback at the most critical point where you can still easily steer the project

12:16.000 --> 12:20.000
I really want to emphasize the point of seamless installation

12:20.000 --> 12:25.000
And that's because I want to ask you how many times have you seen a software project online

12:25.000 --> 12:29.000
Looks very cool you install it or you try to install it and you fail

12:29.000 --> 12:33.000
How many times do you come back later and try again?

12:33.000 --> 12:35.000
I suspect very very rarely

12:35.000 --> 12:38.000
And that's because you don't get a second chance of making a first impression

12:38.000 --> 12:41.000
So even if you're with your MVP with your first release which has only one feature

12:41.000 --> 12:44.000
You have to try very very hard to make it easy to install

12:44.000 --> 12:46.000
And I know it's hard and takes a lot of time

12:46.000 --> 12:49.000
Because dependency hell is called that for a reason

12:49.000 --> 12:52.000
But don't underestimate that amount of time that will take

12:52.000 --> 12:54.000
Sometimes it takes more time than developing the feature

12:54.000 --> 12:57.000
But it's important work if you want to come into adoption

12:57.000 --> 13:00.000
And manage expectations upfront

13:00.000 --> 13:02.000
So if you know your software does not run on macOS

13:02.000 --> 13:04.000
Say it upfront on the homepage

13:04.000 --> 13:06.000
So you don't disappoint people

13:06.000 --> 13:09.000
For subsequent releases

13:09.000 --> 13:12.000
It's basically the same as for the first release

13:12.000 --> 13:13.000
You rinse and repeat

13:13.000 --> 13:16.000
A few features at a time, ideally only one at a time

13:16.000 --> 13:18.000
Avoid releasing undocumented features

13:18.000 --> 13:22.000
And make sure you don't unknowingly break existing functionality

13:22.000 --> 13:26.000
And small incremental releases are really powerful

13:26.000 --> 13:30.000
And they rock basically and they benefit everyone involved

13:30.000 --> 13:34.000
Because for your team it's easier to do cost correction

13:34.000 --> 13:37.000
And you have a series of small wins that keeps them all high

13:37.000 --> 13:41.000
For the users they can adapt their workflows gradually

13:41.000 --> 13:43.000
And they want to be left high and dry when you decide to

13:43.000 --> 13:46.000
One day write your entire API without warning them

13:46.000 --> 13:50.000
And for the ecosystem especially this is really key

13:50.000 --> 13:52.000
I mean you've all seen this graphic I'm sure

13:52.000 --> 13:54.000
But the point of that is that

13:54.000 --> 13:57.000
The ecosystem is a very complex independent structure

13:58.000 --> 14:01.000
Your software is one piece I hope hopefully not this one

14:01.000 --> 14:03.000
But maybe someone somewhere here

14:03.000 --> 14:06.000
But if you move that piece very abruptly and very suddenly

14:06.000 --> 14:09.000
Without warning the local structural collapse

14:09.000 --> 14:11.000
If you do this often

14:11.000 --> 14:13.000
People who start noticing and they will cut you out

14:13.000 --> 14:15.000
Silently they will stop depending on you

14:15.000 --> 14:16.000
They will stop using you

14:16.000 --> 14:18.000
And then suddenly you will find yourself isolated

14:18.000 --> 14:20.000
So be a good neighbor and be predictable

14:22.000 --> 14:24.000
This brings me to my final point

14:24.000 --> 14:26.000
Radically open communication

14:26.000 --> 14:30.000
So both points I made so far the mission point and the releases

14:30.000 --> 14:35.000
Our examples of one way communication from you and your team to the community

14:35.000 --> 14:38.000
Now I want to talk about the communication

14:38.000 --> 14:40.000
This more granular and multi way interaction

14:40.000 --> 14:44.000
Basically I want to talk about where the day-to-day work happens

14:44.000 --> 14:48.000
And how you align the interactions not only from you to the community

14:48.000 --> 14:51.000
But also between the members of the community

14:51.000 --> 14:54.000
So I will talk about in our team

14:54.000 --> 14:59.000
How we handle how we approach issues, how we approach public requests

14:59.000 --> 15:02.000
And other communication channels

15:02.000 --> 15:04.000
First of all issues

15:04.000 --> 15:06.000
We use them as a scratchpad

15:06.000 --> 15:09.000
In our case it's GitHub issues but it doesn't matter

15:09.000 --> 15:12.000
It can be GitHub, it can be any product management system

15:12.000 --> 15:15.000
What I mean by scratchpad is that

15:15.000 --> 15:19.000
If you get a new idea, write it down as an issue

15:19.000 --> 15:23.000
If you get new information and existing idea, comment under the issue

15:23.000 --> 15:27.000
If an idea grows and bursts its banks, breaking into smaller issues

15:27.000 --> 15:30.000
If two ideas are related, cross-linked issues

15:30.000 --> 15:33.000
And if the idea is no longer relevant, close-ish

15:33.000 --> 15:35.000
That's the recipe

15:35.000 --> 15:38.000
And it's all you need to do

15:38.000 --> 15:40.000
But I really want to emphasize

15:40.000 --> 15:43.000
You have to minimize the time between conceptualizing something

15:43.000 --> 15:44.000
Addwriting it down

15:44.000 --> 15:47.000
And my tip is if you can formulate as a sentence, it's right to be written down

15:47.000 --> 15:50.000
Why do I keep insisting on this point as much as possible?

15:50.000 --> 15:53.000
It's because it protects you from all kinds of harm

15:53.000 --> 15:54.000
And it has many benefits

15:54.000 --> 15:57.000
So writing things down keeps you from getting them

15:57.000 --> 15:59.000
And I cannot tell you how many times I read an issue

15:59.000 --> 16:02.000
I wrote a year ago, I had no memory of it

16:02.000 --> 16:04.000
And I was very grateful that I had written it down

16:04.000 --> 16:06.000
And I'm sure you had that experience as well

16:06.000 --> 16:08.000
To you never run out of things to do

16:08.000 --> 16:10.000
You have a very populated issue

16:10.000 --> 16:12.000
So if you have some extra time on the weekend

16:12.000 --> 16:14.000
And you look at this issue tracker

16:14.000 --> 16:17.000
You have many tasks that are right to be picked up

16:17.000 --> 16:22.000
And three, as I mentioned already, writing sharpens your thinking

16:22.000 --> 16:25.000
But maybe you think, why do I have to do it publicly?

16:25.000 --> 16:28.000
I can do this in a diary or in a logbook

16:28.000 --> 16:30.000
I can really write it in a notebook

16:30.000 --> 16:32.000
Why do I need to make this public?

16:32.000 --> 16:35.000
I think the public is really key

16:35.000 --> 16:37.000
Let's do another experiment

16:37.000 --> 16:40.000
Let's see, you are using one of these two projects

16:40.000 --> 16:42.000
And you find the back

16:42.000 --> 16:44.000
And you go to the repository of the first one

16:44.000 --> 16:46.000
Left and you see no issues, no pull requests

16:46.000 --> 16:48.000
The other one you see

16:48.000 --> 16:51.000
100 issues, 30 pull requests

16:51.000 --> 16:54.000
Where would you post the bug report?

16:54.000 --> 16:56.000
I think on the right

16:56.000 --> 16:57.000
Why?

16:57.000 --> 17:00.000
Because the live release tracker is a signal activity

17:00.000 --> 17:02.000
It's also built trust

17:02.000 --> 17:04.000
Because you can go read the existing issues

17:04.000 --> 17:06.000
You can see how the maintenance is found

17:06.000 --> 17:09.000
You can see the communication norms they follow

17:09.000 --> 17:11.000
How they interact, how they react to bug reports

17:11.000 --> 17:14.000
And that makes you much more likely to go and report something

17:14.000 --> 17:16.000
Because you understand the social context

17:16.000 --> 17:19.000
Without a population record, there is no social context

17:19.000 --> 17:22.000
You are afraid, you don't know what to expect

17:22.000 --> 17:25.000
Of course, the other benefit of a public scratchpad

17:25.000 --> 17:26.000
Is that other people solve your problems

17:26.000 --> 17:28.000
And this happens in real life

17:28.000 --> 17:30.000
And it's fantastic when it happens

17:30.000 --> 17:34.000
About pull requests, all I want to say is that

17:34.000 --> 17:36.000
Please use them

17:36.000 --> 17:38.000
So don't just push the main, even if you are the only developer

17:38.000 --> 17:41.000
So if you are the only person working on the project

17:41.000 --> 17:43.000
Still go through pull requests

17:43.000 --> 17:45.000
Even though it may seem tedious

17:45.000 --> 17:47.000
Again, there are many reasons for that

17:47.000 --> 17:48.000
It leads by example

17:48.000 --> 17:51.000
So if one day you say, I welcome contributions to pull requests

17:51.000 --> 17:53.000
If there is a track record of your pull requests

17:53.000 --> 17:56.000
You establish an example of how you expect this to be done

17:56.000 --> 17:59.000
It creates a documented track record

17:59.000 --> 18:02.000
So if someone one day you or someone else is debugging a project

18:02.000 --> 18:05.000
Having that stream of well-described pull requests

18:05.000 --> 18:07.000
It's really key to that debugging process

18:07.000 --> 18:09.000
It facilitates review

18:09.000 --> 18:12.000
And if you have at least one more person working with you on the project

18:12.000 --> 18:14.000
We are blessed and please review each other's code

18:14.000 --> 18:19.000
And remember that every code review is also an opportunity to enforce your norms

18:19.000 --> 18:23.000
Because if you want to create a certain culture within the project

18:23.000 --> 18:25.000
peer review is at least in their own days

18:25.000 --> 18:27.000
Where that culture is born

18:27.000 --> 18:29.000
Because how you review code, how you

18:29.000 --> 18:32.000
The advice you give is really how you create the culture

18:32.000 --> 18:35.000
So use it wisely

18:35.000 --> 18:38.000
When your project grows, beyond the certain size

18:38.000 --> 18:41.000
Issues and pull requests are no longer enough

18:41.000 --> 18:44.000
That's because GitHub is mostly people like us and out there

18:44.000 --> 18:46.000
Normal people don't hang out there

18:46.000 --> 18:50.000
So you have to go where the community is

18:50.000 --> 18:53.000
And for example in movement we also use Zuli

18:53.000 --> 18:55.000
Passed chat platform as a forum

18:55.000 --> 18:57.000
There are other solutions

18:57.000 --> 18:59.000
But I recommend using something like that

18:59.000 --> 19:02.000
To seek users' support to chat with each other

19:02.000 --> 19:03.000
To connect with each other

19:03.000 --> 19:06.000
The thing I want to emphasize here is that

19:06.000 --> 19:08.000
Please minimize entry barriers

19:08.000 --> 19:11.000
So don't use something that requires someone to send them

19:11.000 --> 19:16.000
Email or get special access or permission from someone to be letting

19:16.000 --> 19:20.000
Make it easy for people to come to you essentially

19:20.000 --> 19:23.000
We also do community calls every two weeks

19:23.000 --> 19:24.000
Where everyone is welcome to join

19:24.000 --> 19:26.000
And we have social media channels

19:26.000 --> 19:30.000
The word of caution here is that past a certain size

19:30.000 --> 19:33.000
Managing all these channels requires significant effort

19:33.000 --> 19:37.000
If you produce growth you will need a code of conduct

19:37.000 --> 19:39.000
You probably need that from the very beginning

19:39.000 --> 19:41.000
You will need governance structures

19:41.000 --> 19:43.000
And one day you will also need the community manager

19:43.000 --> 19:45.000
But if you reach that point

19:45.000 --> 19:47.000
You have already succeeded at community adoption

19:47.000 --> 19:48.000
And you don't need my advice

19:48.000 --> 19:50.000
So congratulations

19:50.000 --> 19:54.000
So a recap of all the points I mentioned

19:55.000 --> 19:57.000
Three key takeaways

19:57.000 --> 19:59.000
Write a software abstract

19:59.000 --> 20:02.000
Because these curves out your place in the web consciously

20:02.000 --> 20:04.000
And openly and from the outset

20:04.000 --> 20:06.000
Relies are really often

20:06.000 --> 20:08.000
Because the trust you build through incremental releases

20:08.000 --> 20:09.000
Compounds over time

20:09.000 --> 20:12.000
And it's worth far more than the polish you sacrifice

20:12.000 --> 20:15.000
And the brace radical open communication

20:15.000 --> 20:17.000
Basically write everything down

20:17.000 --> 20:19.000
Maybe public by default

20:19.000 --> 20:21.000
And let the magic happen

20:21.000 --> 20:23.000
If you like this idea

20:24.000 --> 20:27.000
I'm also writing them in a longer form than this talk

20:27.000 --> 20:29.000
So I'm writing a block series

20:29.000 --> 20:32.000
The first part which is about the software abstract idea

20:32.000 --> 20:33.000
Is already out

20:33.000 --> 20:35.000
And I will release the part two and part three in the next week

20:35.000 --> 20:37.000
So check it out

20:37.000 --> 20:39.000
Thanks a lot for your attention

20:39.000 --> 20:41.000
And I'm very happy to take your questions

20:41.000 --> 20:43.000
Thank you

21:03.000 --> 21:04.000
Yeah, that's it

21:04.000 --> 21:08.000
The question was how do we track the size of our user community

21:08.000 --> 21:10.000
And how do we approach that?

21:10.000 --> 21:11.000
That's a hard problem

21:11.000 --> 21:13.000
It's a hard problem because we don't want to be invasive

21:13.000 --> 21:16.000
We don't want to embed tracking and other stuff in our software

21:16.000 --> 21:19.000
So it's hard

21:19.000 --> 21:21.000
Long term you get a lot of

21:21.000 --> 21:22.000
Because we write research software

21:22.000 --> 21:23.000
Good signal with citations

21:23.000 --> 21:25.000
Because people when they've cited

21:25.000 --> 21:26.000
We know they use it

21:26.000 --> 21:28.000
But this is this severely underestimated

21:28.000 --> 21:30.000
The user community

21:30.000 --> 21:32.000
Because most people don't

21:32.000 --> 21:33.000
Don't cite it when they use it

21:33.000 --> 21:34.000
And that's fine

21:36.000 --> 21:38.000
This is a problem we encounter often when we have to write grants

21:38.000 --> 21:40.000
And report to funders to advocate for more funding

21:40.000 --> 21:42.000
And then we have to say how large is your community

21:42.000 --> 21:46.000
The things I end up reporting is the size of the community

21:46.000 --> 21:48.000
So on GitHub and on Zulip

21:48.000 --> 21:50.000
Like how many people comment on issues and pull requests

21:50.000 --> 21:52.000
How many people contribute?

21:52.000 --> 21:56.000
Because for every person who opens a bug report on GitHub

21:56.000 --> 21:58.000
There are probably hundreds more behind that person

21:58.000 --> 22:00.000
Who have used it and have not opened an issue

22:00.000 --> 22:02.000
And a thousand more maybe

22:02.000 --> 22:05.000
So I know this also underestimates the size

22:05.000 --> 22:07.000
But I don't have a good answer

22:07.000 --> 22:08.000
Let me know

22:08.000 --> 22:09.000
Yeah

22:10.000 --> 22:11.000
Okay

22:11.000 --> 22:12.000
We need a little discussion

22:12.000 --> 22:13.000
Actually

22:13.000 --> 22:14.000
Stins

22:14.000 --> 22:15.000
Yes

22:15.000 --> 22:16.000
Excuse me

22:16.000 --> 22:17.000
Specific people in the book

22:17.000 --> 22:18.000
Research software

22:18.000 --> 22:20.000
How would you end up the scientific

22:20.000 --> 22:21.000
Communication

22:21.000 --> 22:22.000
Scientific science

22:22.000 --> 22:23.000
That's

22:23.000 --> 22:26.000
If you like with the amount of tuition papers

22:26.000 --> 22:27.000
Yeah

22:27.000 --> 22:29.000
So the question is

22:29.000 --> 22:32.000
How do we handle the scientific communication side of research software

22:32.000 --> 22:35.000
So do we publish papers to advertise our software or not

22:35.000 --> 22:36.000
Sometimes we do

22:37.000 --> 22:40.000
But our approach is we see scientific papers

22:40.000 --> 22:42.000
Just as another advertisement vehicle

22:42.000 --> 22:44.000
So basically

22:44.000 --> 22:46.000
If we think the community we want to reach

22:46.000 --> 22:48.000
We'll read paper more readily than they will read

22:48.000 --> 22:49.000
An announcement on GitHub

22:49.000 --> 22:50.000
We will write the paper

22:50.000 --> 22:52.000
But we don't see papers as first class citizens

22:52.000 --> 22:56.000
Luckily we are most of us are software engineers

22:56.000 --> 22:59.000
So our promotion and our jobs are mostly

22:59.000 --> 23:01.000
Just by software not by publication

23:01.000 --> 23:03.000
So we don't feel obliged to publish to keep our jobs

23:03.000 --> 23:04.000
Which is great

23:04.000 --> 23:09.000
But we often do because we think that the users of the software

23:09.000 --> 23:11.000
With the papers

23:11.000 --> 23:14.000
And it's another kind of way to increase our visibility

23:14.000 --> 23:16.000
But it's not a primary target

23:16.000 --> 23:17.000
Yeah

23:17.000 --> 23:18.000
My cell

23:18.000 --> 23:20.000
When I do it can be programmed

23:20.000 --> 23:22.000
Because I want to reproduce

23:22.000 --> 23:24.000
We set papers

23:24.000 --> 23:25.000
Yeah

23:25.000 --> 23:26.000
Yeah

23:26.000 --> 23:28.000
So sometimes the papers we read

23:28.000 --> 23:30.000
Could be either presenting the software itself

23:30.000 --> 23:32.000
As a tool as a method

23:32.000 --> 23:36.000
But sometimes it's in combination with like solving a scientific problem

23:36.000 --> 23:39.000
And then by the way we saw to solve this we created this tool

23:39.000 --> 23:41.000
And we have both types of papers

23:41.000 --> 23:43.000
And in my experience people cite the papers

23:43.000 --> 23:45.000
Scientists cite papers much rather than they cite

23:45.000 --> 23:48.000
The UI of the software because that's what they are used to

23:48.000 --> 23:52.000
So that's another way to kind of somehow track the usage

23:52.000 --> 23:54.000
If you write the paper it's more likely to be cited

23:54.000 --> 23:56.000
There are some solutions for that

23:56.000 --> 23:57.000
Like jobs is a great initiative

23:57.000 --> 23:58.000
The general of open software

23:58.000 --> 24:00.000
Because it kind of hacks the problem

24:00.000 --> 24:03.000
It allows you to have a sightable paper for a software artifact

24:03.000 --> 24:07.000
And to an extent we also publish papers at jobs

24:07.000 --> 24:10.000
Yeah

24:10.000 --> 24:27.000
The question was if we have experience with lowering barriers for contributors

24:27.000 --> 24:35.000
I mean a lot of the stuff I mentioned is going towards that direction

24:35.000 --> 24:37.000
Already one barrier is people reaching you

24:37.000 --> 24:40.000
And I showed like how you can lower that barrier of people reaching you

24:40.000 --> 24:41.000
Finding you

24:41.000 --> 24:45.000
The second is we run training workshops

24:45.000 --> 24:46.000
We run hackathons

24:46.000 --> 24:52.000
And last time we run a hackathon where we essentially combine workshops for users

24:52.000 --> 24:54.000
And try to make them into contributors

24:54.000 --> 24:56.000
So when we teach our workshop for users

24:56.000 --> 24:57.000
We follow up with the hackathons

24:57.000 --> 24:58.000
So that we take these users and

24:58.000 --> 25:01.000
Walk them through the process of a git workflow

25:01.000 --> 25:05.000
So it doesn't seem very very strange to them

25:05.000 --> 25:08.000
And we try to also teach to our business students

25:08.000 --> 25:10.000
Our postdocs teach the skills that they would need

25:10.000 --> 25:13.000
So teach how to use GitHub and so on

25:13.000 --> 25:15.000
But I don't have an amazing answer to that

25:15.000 --> 25:16.000
Yeah

25:16.000 --> 25:19.000
Thank you

25:19.000 --> 25:20.000
We should wrap up

25:20.000 --> 25:21.000
Okay, thank you very much

25:21.000 --> 25:23.000
Thank you