So, thank you very much for your patience.
We are going to start with the next talk with Lorna, and she's going to talk about what
was called craft, better and a bit of experience for pensar projects, so with yours, Lorna.
Thanks very much.
If you are hoping to see a different talk in this slot, I'm sorry, your original speaker
couldn't make it, and I was asked to fill in this slot.
That means I didn't have a lot of warning, but I hope I have some content that's going
to be useful to you, and we'll all get something from this experience.
So hi, I'm Lorna, I am a very long-standing open source user, contributor, and maintainer,
I've maintained projects that are just me, some that are much bigger, higher profile,
everything in between, and also maintained projects as part of my employment in a couple
of different roles.
I want to talk to you today about developer experience, and how we can improve the developer
experience throughout the different life cycle stages of open source.
And when I talk about the open source life cycle, I mean that journey that we take, our
own growth from first contributing to a project, and then perhaps becoming a maintainer,
but that journey begins as a user.
There's no project that we can ever become a contributor to, that we can't become a user
in the first place, by understanding what the project is and what it does.
The goal is to take people from using, to adopting, to championing the project, from getting
involved, maybe opening issues, to starting to patch things, or triaging issues, and contributing
in other ways, and perhaps one day, including them as part of your maintainer team.
So how does the story begin?
I love this to work.
Beautiful.
Let's talk about developer experience for users of your open source project, especially on
a single person project, we sometimes get very focused on just our own needs, but if
we want our projects to grow and to thrive, we need to welcome new people in and make that
easy.
The first thing you need to do is make sure that people can find your project when they
need it.
This is the Wireshark repo on GitHub.
The way that you use the tags on the source hosting platforms really helps people to find
your tool, even if they've never heard of it before.
So this is a really good place to start for your project.
The story project needs that little blurb, again, it comes up in search results when
people are scanning the list, and you need to introduce what your project is, what it does,
who it's for, if it's only for a particular text act, that would be useful for me to know
as well.
So work on those first impressions, the short window of your project, to help people to
discover the project that they will then grow into.
A read me is an art form, and there are lots of templates to help you do it well.
I think one of the hard things about a read me is when your project begins, it needs
like two paragraphs or something small, and by the time it is very popular in well-known,
it needs something completely different, and it can be hard to return to focus on the
read me throughout your project maturity journey.
Sometimes if you are more code specialist, writing a read me can seem like a really, really
hard problem.
You may tell me, I'm not a writer, I don't know English well, I can't do it, it will
be bad, it will be hard, I don't want to, and understand, right?
But I can't support you in not doing a great job here.
First of all, there are lots of resources, and your best effort is good enough.
So when it comes to writing the read me and maybe some other documentation, find a template,
set aside some time, show up, and try, and that is everything that I need, your projects
will be better for that.
The structure of the information that you share is important, a very, very long read
me is almost as much of a problem as a very, very short one.
In both cases the information I need, either isn't there, I can't find it.
This is about technical communication, thinking about who you are writing for, who will
be reading this, tell me what your project is, what it does, it is incredible how many open
source projects I visit, but I can read the whole read me and still not know what this
is.
I'm looking for something in particular, but I don't know if I found it.
Do some installation instructions.
If they're massive, either it's very complicated or you support a lot of platforms and
it's different for each one, consider moving those to a separate file.
You can give the one line of dependency manager install, but if it's more complicated than
that install thing, you might want to put that in a separate document.
Please show me how to use it as well, because that's a very early hurdle to fall at.
When you install something, if you can't use it, you are probably you are trying to
a three project, it's likely that I'll use a different one if I can't understand how
to succeed with yours.
This is the beginning of our developer experience story, developer experience is about
making developers confident and successful and efficient in what they do, and a good
read me can really help.
If you look at my GitHub history, you'll see that I have committed to a bunch of different
projects or contributed to a bunch of different projects, but if you look more closely, nearly
all of them are read me or docs fixes.
This is important if you think that somebody else's project instructions could be improved
You're bringing that new user perspective, I consider it your responsibility to open a
pull request that improves those install instructions or that getting started usage instructions.
With the further resources, you can link through to whatever you have, maybe other people
have written about your project, maybe there's a documentation site published somewhere,
please include some contact information, or at least the direction do you love people to open
discussions on GitHub or GitHub to ask questions, or is there a better community for them
to join for that?
Just help your new users to connect with your project.
Things that are too big for the read me, and sometimes that will mean you kept on expanding
the read me on one day you realize this should not all be in one file, we're going to
do refactoring.
Now, if you're a developer, you already know how to do refactoring when you do it with
words, it's exactly the same.
You break it out into a separate function or a document, and you refer to it from the original
context.
In our code projects, documentation doesn't really really doesn't need to be complicated.
Use a docs' code approach, so choose a text-based market format, mark down is very common,
I'm a big fan of Restructured Text, which you'll commonly find in the Python community,
getting a little round of applause.
Thank you.
It is the best format, and you will not change my mind.
I've used them all, and just put files in a folder called Docs that are valid market,
all of the software, the source control hosting sites will render it.
This is all that users need.
Put it in the repository, update it when your code updates.
We're good.
This doesn't need to be over-engineered.
You don't need a website.
This screenshot is a rendering of Restructured Text from Codeberg.
It just doesn't need to be overly full.
You can build your documentation by taking answers to issues or to emails and pasting them
into mark down files in your Docs folder.
Seriously, this will get you started.
Publishing is optional.
You might want to create a website from your Docs folder, and for that it's especially
you have complex usage.
You need to write some stuff down.
That can be quite nice to give it the navigation as well.
But typically, if it's a technical project, people will find their way.
I know I already said this about writing.
You maybe don't feel like an expert.
But all open source projects are globally distributed, remote, asynchronous,
right?
We have to be writing things down.
And even though this is a skill that you might use less than some of your other skills
or a language that you don't use every day,
still need you to write things down and trying,
even though it's hard or even though you don't feel successful,
is still the right thing to do for your project.
And it massively multiplies developer experience.
The other secret is that if you have documentation, people will update it.
Right?
If there's nothing there, you look like a project that doesn't care.
But if there's something there, somebody allowed another file in the directory,
or another section to the Markdown file,
and we start to grow this thing together.
So even small patchy documentation that you are not proud of,
improves the developer experience on your open source project.
I feel like I talked a lot about a lot of things that are not code.
But I think the code and the user experience,
the developer experience,
isn't really important part of onboarding new users
as part of our project.
Follow conventions from your text stack,
but don't depend on them.
It's open source.
But if I think in pilot on my machine,
then I can use it, except I might not be super up to speed
with the latest dependency management in Vala or whatever it is you're using.
So like try and make it so,
you don't need to tell me how to install node,
but if you could try and use words that I could then Google
or link to a, if you don't have NPM click here, that's enough.
Remember that some of your users might be coming
from another text stack and in open source,
that's cool, actually.
That's right, I don't want you to have
the thing about rebuilding every tool in JavaScript
because you don't know how to use another text stack.
We change the world when we make our projects more accessible
to people from different technical stacks or different levels of knowledge.
But that you want to package your tool
in as many ways as you can that makes sense for you
and that is sustainable to maintain.
And those two things can be a bit of a struggle.
Find your sweet spot and graciously allow the community
to help you.
Like if somebody's asking for a package format,
ask them if they would like to contribute that
or help to maintain that.
Because if they care about it, you can join forces.
And especially when you are currently a soul maintainer,
it can be difficult to let that next person in.
If your project has or could have extensions or plugins,
those kinds of things, just make a space on the read me
to link to where other people are publishing their things.
Link to where someone gave a talk about your tool
or you showed some examples about it.
Link to some blog posts if you know about them.
Again, once there's a section for this stuff,
people will show up and add things
because you show that you want it.
When we rolled the first release of the new Open API overlays,
specification, I was a bit frustrated that I didn't.
I only knew a couple of tools that were using it.
So I put a section in the read me, listing both tools
and sure enough, three others showed up almost immediately.
So asking people, hey, tell me about a thing.
Didn't go very well.
But you know, the list is over there.
People came and put themselves on the list.
So that was cool.
Try to make this approachable,
especially at the user stage.
People might not already be insiders
to the project that text, or whatever.
But we want people to join our Open Source family
to choose Open Source solutions over proprietary solutions
and to be able to succeed.
I recently tried to patch the help file for it.
I'm not going to name the tool because it isn't there.
For a CLI project.
So there, dash dash help output.
I didn't find it very helpful.
And I sent them a patch.
And they linked me to the last time someone
tried to patch their help output.
And the response was basically,
anyone who doesn't know how to use a man page
shouldn't be using the CLI.
A lot of modern CLI tools don't have a man page.
I guess that's why I didn't look for it.
So that's a terrible developer experience.
I'm not aware of any competing tools sadly.
So I am stuck with it.
But that's the opposite of what I want from you.
It would be so easy to add a little extra explanation
into the help output.
And allow anyone who has installed this either
from the Open Source project, or it's actually
packaged by a bunch of the distros.
So they haven't come through the GitHub repository
with the rape me to know how to succeed with the project.
All right, that was users.
Let's talk about contributors.
Contributors are a people who come and help our project.
And they stay until the wind changes.
That says it should be.
No, it's not a commitment for life.
They're not making us any promises.
But anyone who comes and makes your project
a little bit better is like some kind of gift.
The first thing you really need is a code of conduct.
I know this has been controversial in the past.
And maybe you don't care about the code of conduct.
That's all right.
Not telling you you should care.
But if you would like contributors,
some of those contributors will care.
And if you are the kind of person who runs your project
along lines where other people can safely get involved,
then let's write that down.
And let's help those people feel confident
that they can safely get involved.
The code of conduct is also there as a what if.
We've all heard horror stories of things that happen.
What if you have a bad actor in your project?
What if someone's behavior is so bad
that you need a procedure to remove them from the project?
The code of conduct sets the tone.
It is the, we don't do that here.
In written format.
And I think it can back you up as a maintainer,
as much as make you welcome as a contributor.
If you are a company maintaining open source,
this becomes even more important
because not all publicity is good publicity.
You, and this can be a bit weird for companies
who are new to open source.
They made a thing, they published it once.
They think it's nice.
They're going to get a big community
that are then going to buy the commercial product, whatever.
So, explaining this like hacker meritocracy
and the code of conduct to organizations.
I've done it multiple times in my career.
It's always an adventure.
But it's very important.
And for that, I always have an internal
to the company document that says,
who is responsible for noticing this problem?
And what is the procedure?
And it can be as simple as, you know,
all three members of this sub team
will be subscribed to all notifications
on the repository at all times.
And if there's a problem,
you will, from the wider Ospo DevRel team,
who ever you trust to know this community
and work on it, three of you will sit down in a meeting
and take minutes and agree what to do
and someone will do it.
So, it's time zone safe.
You don't need to wake me to wake up and bless your activities.
If there's a problem going off,
bit you follow this, you write it down and you do it.
It's such a short document.
I have never needed it yet.
I'm going to touch the wood.
I don't want to jinx myself,
but it has to be there
and especially if you're an organization.
I think a code of conduct is not hard.
You probably already run your project
in a perfectly code of conduct acceptable way.
Pick one, write it down.
There's a bunch of really good resources.
GitHub will prompt you.
The to-do group who are,
they do a bunch of Ospo type things.
The Open Source Program offices also have a lot of resources.
Every project is different.
The right code of conduct might be different for you,
but go there and that will help you.
Okay.
Let's talk about the contributing file.
The contributing file isn't interesting one.
It's where we write down how we run our project.
This is really important.
Even if you are a soul maintainer,
unless you never think about anything else
and you never forget anything.
Neither of those things is true.
So you need a contributing file.
And this should be everything a new user needs to contribute.
A new user is also anyone who has slept
since they lasted this.
Especially if you work on a lot of different projects
and different things.
So the way that I typically think about the contributing file
is a bunch of high-level categories
of the kinds of things you need to cover.
The philosophy, do you actually want contributions?
People should read the contributing file
before they contribute.
Everybody knows that the web interfaces prompt you to read it.
If you don't want contributions, just say so.
The mechanics of how does that work
at a branch's issues requirements or what?
A bit of a code base overview
where to find things in the project,
how it interconnects if your project is made of multiple repose.
That kind of thing architecture diagrams go a massively long way.
I would like to see more of those in public projects.
We do it for our company.
Stuff, I don't so often see it in the external ones.
Any information about the quality checks
and then how to actually deliver a finished pull request.
So if we look at some of those a little bit more closely.
You know, we say patch is welcome,
meaning stop complaining to me,
not meaning patches welcome at all.
Your contributing file should make it clear
if patches are actually welcome.
There are loads of reasons why patches aren't welcome.
It's completely fine that patches are not welcome.
And maybe it's, you're just publishing something,
but this isn't the place that it gets changed.
You can't accept patches.
I used to work for a company that had its product
was a bunch of APIs,
and we published all of the open API descriptions
in a public repository.
You can't add end points to our API document
documentation in this setting.
There's an API change process of which these are the output.
So we're closed to patches
because that's not how the change process works.
I'm publishing this as a resource for users.
Corporate projects that really actually
don't want changes from anyone else.
However you feel about this,
it would be better if they were upfront about it.
It wasn't until elastic changed their license
and I became part of the open search fork
that I realized
elastic has an accepted patches from anyone else in years.
They're actually not open to contribution.
And that's fine, as your project, you say what you want,
but let's make that clearer in the contributing files.
Sometimes it's a community driven project,
and you're very open to patches, right?
Patches, please, your contributing files
should make that clearer as well.
Remember also that people might fork your project
they still need to be able to run it, build it,
understand how the moving parts work.
You might not want their changes contributed upstream,
or they might not want to.
They use case might be so specific
that it makes no sense to be in the main project.
And that's okay.
So they still need the instructions
of how to operate and maintain and build
and contribute to the project,
even if that code never lands in the original project.
I used to run a fork of the reduckly serialized,
a linting tool.
It's a linter, it has lots of different output formats.
All of them look terrible with a huge font size,
and I do a lot of talks and demos.
So I had my own fork of the project,
which had a different output formatter.
We don't want this in the main project,
makes no sense, but I need it
when I'm taking screenshots and showing things to people,
just because of the way the white space works.
Being upfront about the mechanics,
moving parts of contribution,
helps insiders on the project,
as much as it helps outside us.
I'm a maintainer on OpenAPI.
We have eight official committers,
three or four other people who have some level
of access to other parts of the project,
and a very big audience of contributors.
Getting everybody to precisely do the correct thing
with the branching and releasing and everything,
would be impossible if we didn't write this down.
I work on this project all the time.
I refer to the contributing died all the time.
So it helps you as much as anybody.
So write down the branching strategy.
Do you require an issue to be created for a pull request
before a pull request?
One of the requirements for a pull request,
I will normally reject anything that doesn't have a description
on the basis that if you can't write a description,
what else did you not bother to do?
It always says that in the contributing guide.
I'm not sure it's popular, but it works really well.
Are there naming conventions that would cause branch naming,
folder naming, I don't know, plug in naming,
that would cause your pull request to be rejected?
Write them down.
Let me know before I build it.
I'll open the pull request, it needs to be in the contributing file.
If there are tests to run quality checks, that kind of thing,
there's need to be there as well.
I think the biggest thing with the mechanics
on an open source project is having a well-maintained issue
backlog.
If someone opens an issue and you don't want that
in your project, close it.
Don't let me spend the whole weekend building it
and then tell me you don't want it, close the issue.
If there's something you'd really like help with,
tag it, the help wanted tag is very common across GitHub.
If people are asking questions, or suggesting things
and you have an opinion, you need to respond
because without your input, those things can't move forward.
Obviously, you should do, as I say, and not as I do,
please don't go and stalk all of my GitHub projects.
They're not all beautiful.
And I'm really good at closing issues.
That's my super power.
OK.
When we work on software projects inside an organization,
we talk about a definition of done.
Done isn't it works on my computer in my branch.
Done is it's actually shipped to a production
or it's in a release or whatever.
What does that look like for your open-source project?
Let's write that down in the contributing file.
Do you require a documentation patch?
And if you're going to reject a poll request that doesn't have one,
then you require it and it needs to be in the contributing guide.
So people know that that's expected of them.
Do you require additional tests?
Or the tests to pass, I guess, probably?
I'm going to write that down.
Is it expected that every change will come with a change-log entry?
What's the format of that?
Do you use a specific tool?
Does it need to go in a specific location?
Right, it's in the contributing file.
It's not good enough to allow new contributors
to open poll requests, and then ask them to do eight more things
in one at a time.
That is not a good developer experience.
If that happened to you at work, you would quit.
So let's not do it in our open-source projects.
Every project is different.
There's probably something else that is needed in your project.
Could you please think what that is and write that down to?
Because I didn't get it to put it on my slide.
Speaking of things that would make you quit your job,
if they happened at work, let's not do them in open-source,
local development setups.
There must be a way for a new person to run this stuff,
themselves, so they can work on contributions.
You know how to run your code locally.
Help someone else to do the same.
Because without this, they can't make changes.
You should never be in the situation
where you have to push code to somewhere
to see if it was any good or not.
This is not a good feedback loop.
This is not an efficient and respectful use of your time.
Let's not do that.
Let's make it easy.
Make sure you have documentation on how to set things up locally.
And if you don't know how to set it up for Windows,
the documentation can say that,
probably someone will explain to you how to do it.
I can't believe you didn't know that.
It doesn't matter what your attitude is,
I've got the instructions in my project now.
Thanks.
Encourage people to contribute.
Remember that the gaps in the documentation are as useful
or much better than there being no documentation,
because people will come and fill us in a little bit, usually.
Reviewing podcasts in open source is a transferable skill
from other projects, and I work on code,
but also on pros, different types of assets.
It's a very, very, very transferable skill.
It's one that I don't feel that we necessarily teach
or study deeply through the course of our careers.
And this might be controversial.
Maybe controversial.
This might be controversial, but I think GitHub
and all the equivalent platforms encourage
very poor reviewing practice.
Because I'm not just throwing mud,
because the hard part of really good pull request reviewing
is thinking about the big picture,
thinking about how things fit together,
and thinking about what isn't here.
What do we forget?
Because that's what will really hurt you
is pull requests that change one thing, but not another.
Opening the diff is 100% the wrong way
to review a pull request.
Just eyeballing a diff and deciding is not how you review
a pull request.
Big picture, do we want this feature?
Does this pull request make things better?
For the project, for some audience of the project,
for some part of it, is this a win?
Do you want this feature in your project?
Because if you accept it,
you will support it until the end of time.
You have to really want it.
Don't let people scope create this thing out,
because what they're actually doing
is scoping your maintenance burden.
If it's good, it's good.
But you don't need to have a yes to everything.
If you are a company who owns an open source repository,
you need to make absolutely sure that somebody
or ideally multiple people are getting those notifications
and that they have some time assigned
or they can get some time to work on them.
Otherwise, that is not open source.
You've just thrown the code over the hedge.
That's source available.
Here's the code that's nobody here,
not a healthy project.
Just like reviewing pull requests in every other context,
be clear, be constructive.
I always tell people, you need to say,
if there are about all of the showstopper things,
the things that are so serious
that this pull request cannot be merged,
all of those need to be mentioned
in your first response to the pull request.
However, you, if there are other things that you would've done
differently, you're going to maximum of three,
and after that, you're just nitpicking.
If you would not stop the pull request from being merged
and you do not need to mention it,
we just need to move on forward
or you need better automation, better contributing guides
and so on.
Try to apply the same feedback to everybody,
insiders, familiars, outsiders, newbies, unknowns,
people with identifiably female handles and avatars
try to be consistent because I think you are working
in the open and it's very visible
if that's not what's happening.
The automation is really important for contributors.
It's so frustrating to open a pull request
and then find out there are eight other things
that no one told you about.
So try to set up your project to give immediate feedback
on the things that you care about
and this could be quality standards coding formatting,
spell checks, all that stuff.
Anything you can automate, automate.
This reduces the work for you.
It reduces the number of round trips for a contributor.
It just makes the situation much, much clearer.
And I really think that this improves.
I've got it in the section about developer experience
for contributors, but sometimes you are that contributor.
You probably patch your own project
and all this stuff makes it easier.
I also said the thing about being prepared
and one more commit, especially for open source,
where a bunch of the contributions are drive by.
This person came in, saw a thing, fix a thing.
You're never gonna see them again.
You probably, you won't always get a response.
If you respond and say,
ah, you also need to update this other thing.
You may not get a response.
So be prepared to just say thank you.
Add the extra commit yourself.
Maybe they forgot to add a new docs page,
link into the Nav bar.
One of them, add one more commit.
And as you review and merge it at the same time.
Be prepared to do that last piece,
rather than constantly pushing it back,
which you might do in an internal project.
Although if you're my co-maintener,
then I'm gonna push it back to you.
Developer experience for maintainers.
My goal is not to make work for maintainers.
It's not to raise expectations for maintainers.
I am a maintainer and I became passionate
about all of this stuff because I see how important it is
that we make excellent use of not just the time,
but also the expertise of the people
who are maintaining voluntarily or as part of their job,
either way, there's pressure on them,
maintaining the projects upon which we depend.
Developer experience means
helping developers to be competent and efficient
and successful.
And I want that for maintainers as well.
One of the big things that I do is I have,
whether I have a checklist for poor request reviews.
Now, this is really important
because it means that you can just look at the list.
You don't need to think about
what are the things I check for poor requests on this project?
Especially if you don't work on it every day,
but here's a quick checklist of things,
you know, do you need a change alarm put it in the list?
It is also a brilliant way.
It reduces your mental load.
It lets contributors know what they need to do
because they can look at the list
because it's gonna be Dox's code.
It's gonna be public in your repository.
It helps to onboard new maintainers.
And sometimes projects get abandoned or assigned.
Bad things happen, you might not be here to hand it over.
You might just, somebody might offer to help
at a time when you're in the sandwich pressure,
you can't onboard them.
To this helps.
It also helps with the thing about making consistent reviews.
Everyone knows what's expected.
I am a person who,
I'm considered myself a bystander
on all open source projects.
I go, will happily comment on a poll request
on a project like, don't have commit access to.
If it's clear to me that I've got feedback that can be helpful.
Like it's not, we don't gatekeep contributions.
They're in the open for a reason.
And having the review checklist can allow you to enable
your sort of triage level project members
to be part of the review process.
And that's something that we do at OpenAPI
and I found it very helpful.
Simon Wilson, who you might know from the sort of Python space
he's been writing about AI a lot this year,
he has an absolutely unimaginable number of projects
on his GitHub and I have always wondered how that works.
He wrote a really great blog post earlier in the year
about how he does that with the constant context switch
for all these little projects.
They all have automated tests
and they all have some documentation.
And it means that he can always switch in, pick it up,
read his own instructions to himself and move forward.
And we can also use those resources
if we get involved in those projects.
Again, do as I say, not as I do.
But I found that very inspiring
and it's changed my perspective a bit
on how I do this stuff as a maintainer.
We talked about the contributing file.
I'd like to introduce you to the maintaining file.
This is where we write down all the things we do
as maintainers.
This is the process.
But the contributors, we often think of them
as being outsiders, right?
So we're onboarding them to contribute for the first time.
As maintainers in theory,
we have been hanging around in the project a lot.
I don't know about your projects,
but mine, we don't roll a formal release that often.
There are some other one-off things
that we don't do every day
and I can't always remember how that works.
So the release process, the docs build process.
The other things that you do as a maintainer
when you get this notification from the distros,
do this number, you need to change it in this file
and then in that file.
I'll just write it down.
Again, it enables the next generation of maintainers.
But it also enables you to stop holding that information
in your head.
It puts it somewhere, like it stores it alongside the project,
rather than in your obsidian vault
or however you store your notes.
Those are secrets.
Please take them out of there
and put them with the repository they belong to.
We can just put market files in our repository
to be part of the repository.
It's a good thing.
This wild, globally distributed, time-distributed,
language-distributed, asynchronous work
that we do together in open-source, massively benefits
from all the things that you write down.
Let's talk about automation.
I'm very wary of putting more things on a maintainer to do list,
but these are time-investments and
they're the easiest thing to get help with.
Because even someone who doesn't know your project well
can look at a thing that you're doing manually
and maybe they already have knowledge of the CI system
that you're using or a particular tool for checking.
And they can help fit that to the specific scenario
that is your project.
As a maintainer, your time matters,
your expertise needs to be used to good advantage.
And so these things help you be more efficient
because we're offloading the boring things.
So if you have coding standards,
any of those kind of, if you do builds,
if you can build tests, if you run end-to-end tests
or integration tests, have that all automatic.
We talked a bit about the local development.
These should be runable locally as much as is realistic.
This isn't going to work for a front-body.
But you should be able to run as many of those locally
as it makes any sense, as well as automatically on a pull request.
There will be no for-getting to update something,
for-getting to run the tests.
Just do it.
Adding spell checking and proslinting and coding standards
and checking for file names or directory names.
If you have, in the contributing file,
if you documented requirements for your pull request,
must link to an issue, must use a certain format.
Any of those things?
Automate them.
A lot of those things you can automate,
some of it you can't, so if you can.
It's one of the easiest things to get help with.
We talked about the well-organized, well-acolic garden,
well-looked after issues list.
What do you want?
Open an issue.
Be specific.
Tag it.
Help wanted.
Be what comes.
Mentoring it to people.
Tell your local user group, right?
There's a lot of things here that we can do
to make better use of your time.
Where's your hand if you get too many notifications
from source control systems?
Yeah, I mean to.
And the temptation is to be like,
ah, no, this is terrible.
And you put them all in a folder,
and you never look at them again?
Please don't do that.
Use the settings available on the platform
that you're using.
Route the notifications to your personal email address.
You're a working email address.
I have some other project email address.
Whatever makes sense for you,
take the time to configure the routing.
Let the watch levels appropriately.
I have different projects I have.
I get every notification
because I don't want to miss anything
on this tiny project.
I won't be visiting.
And I have others where you have to save a name
three times before I do anything.
Use the code owners features, right?
This means that you can, in a bigger project,
if there's a change to a docs, a docs directory,
and you have writers as part of your maintaining team,
they can get the review request
and get a notification for it that way.
Use some email rules.
So I have a set of labels which show me,
I'm even getting the notification.
It adds extra, I use in Gmail.
Gmail labels for,
this is a review request or you were mentioned.
And if it's neither of those,
I can immediately tell that from the list in the inbox.
And that's helped me to prioritize on busy days.
And then I can kind of triage the rest
when I can when I have time.
Running out of time, but that I want to just wrap up
with one more thing.
And that's about outreach.
Your project is more than the code.
It's not quite enough to build it
and hope that they will come.
You also need to enable the ecosystem,
your community, your users,
or encourage other people to do that.
Actually, supporting a project with these activities
is a great way to participate in something
if you aren't going to be coding for it,
if you want to support and champion it.
So maintainers, please support these activities,
but for everyone else,
you don't even commit rights to do this stuff.
You write about the project, right about how you use it,
why you like it, share your tool setup,
your configuration.
That massively helps every project
to have a more healthy ecosystem.
Have a list of projects that use the tool.
Again, start the section on the read me.
People will add themselves.
I don't know if we still use suck overflow.
I think we do.
Check for questions there.
If there's a tag or if you can follow what's going on there,
look what people are asking.
Answer if you can, but also it will inform you
what people are struggling with and what they need help.
Tell your local groups about your project.
I think we all want to support each other,
and it's a great way to learn about a project.
You'd be really interested if someone from your user group
told you about their own resource project, right?
So return the favor.
Improving developer experience in open source,
we are back to this being confident,
being successful.
Encourage your collaborators,
especially with people who have a different skill set
from you.
You've space for people to come in to just improvements.
You can suggest improvements to the projects
that you use and like.
Now that you've seen this talk, keep your issues list,
well maintained, close the stuff you don't want before anyone
builds it.
So be kind, write something, but close it.
This is kind, close it.
There's a good first issue label, which
is a great place to have people contribute for the first time.
Your project should always have two or three
in its issue backlog.
And I mentioned some of the automation stuff
as a great place to start, because you don't need
a lot of project-specific knowledge.
My final thought on this is the magic multiplier
that opensource, something that helps users,
participants, contributors, and maintainers.
They thank you.
When people engage with your project,
even if they're reporting an issue in a field's
point negative, they're offering a change,
and you don't want it, still say thank you.
We're building this incredible open source world
that gives people freedom and choice,
and it doesn't cost anything to be
for light about it along the way.
That's it from me.
I am out of time.
I know I am.
If you want to get in touch, I would
be delighted to hear from you.
There are all of the social networks
looking the footer.
I'm also looking for work.
So if you need any help with any of your projects,
or anything like that, please let me know.
Thanks for your time.
Thank you.